The Tech Interview Behind the Scenes: Darina Georgieva

My career in tech actually started with a ban.

Back in high school, my mother forbade me from becoming a software engineer. As you can probably tell, that didn’t work out exactly as planned.

I went on to study Computer Science in the UK, graduating among the top three students in my class and being recognised as one of the top 3 Computer Science students in the UK.

Since then, I’ve spent more than 10 years in the technology industry, working across backend, frontend, DevOps, data engineering, machine learning and pretty much everything in between.

My career has taken me from early-stage startups and SMEs to some of the largest organisations in the world, across industries ranging from robotics and fintech to finance and Big Tech.

Along the way, I’ve had the opportunity to work with companies such as Jane Street, Barclays and Amazon.

I started my career primarily as a software engineer, but over the years, my focus has increasingly shifted towards technical leadership, software architecture, mentoring and helping other engineers reach their potential.

One belief has stayed with me throughout - technical excellence is non-negotiable. It’s the foundation of great engineering, but building an exceptional career also requires ownership, sound judgement, communication and the ability to create impact beyond your own work.

Today, as co-founder of TopCoding, I get to bring all of those experiences together.

Having experienced the industry from both sides of the table, as an engineer and as a technical leader, I’ve seen how much of career growth comes down to things that aren’t necessarily taught at university or learned on the job.

That’s exactly what we’re building at TopCoding - helping engineers achieve technical excellence and turn it into exceptional careers.

One of the strangest technical interviews I’ve had was with Palantir.

I was given an algorithmic problem where the optimal solution involved Union-Find. I explained my approach, but there was one unexpected problem - the interviewer wasn’t familiar with Union-Find.

They expected a DFS-based solution and kept steering me in that direction. Eventually, I implemented the DFS solution they wanted. I did receive an offer, but the experience stayed with me.

It reinforced an important lesson - if you’re assessing candidates on a technical problem, you need to understand it beyond the solution in your interview guide.

Strong candidates may approach problems differently and sometimes their solutions will be better than the expected ones. A good interviewer should recognise that.

I’ve also been fortunate to interview with many excellent companies and experience a huge variety of interviewing styles. The interviewers who impressed me most were rarely the ones following a script perfectly. They were the ones who knew how to make the candidate comfortable enough to perform at their best.

They became genuinely engaged in the problem-solving process, challenged ideas, asked thoughtful follow-up questions and turned the interview into a technical discussion rather than an interrogation. Those are still the interviews I admire the most today.

Technical ability is non-negotiable. For an engineering role, the technical bar has to be there.

Beyond that, there are three qualities I look for very closely - ownership, bias for action and customer obsession.

Ownership means taking responsibility for outcomes rather than simply completing assigned tasks. Strong engineers don’t constantly need someone telling them what to do next - they identify problems, communicate them and help move things forward.

Bias for action is important because engineering environments are full of ambiguity. You rarely have perfect information. Strong engineers know when to investigate further and when to make a sensible decision and move.

Customer obsession is equally important. Engineers who genuinely care about the people using the product tend to make better decisions. They question poor experiences, think beyond the ticket in front of them and often come up with ideas that make the entire product better.

Candidates stand out when they are authentic, genuinely interested in their work, curious and responsive to feedback.

I like technical problems that have more than one valid solution.

Those problems create much better interviews because they naturally open conversations about trade-offs. Instead of simply asking, “Can you solve this?”, you can explore why someone chose a particular approach, what alternatives they considered and how their solution would behave under different constraints.

That gives the candidate more opportunities to demonstrate the breadth and depth of their engineering knowledge.

I also like practical problems inspired by real production systems. They tend to reveal much more about how someone thinks as an engineer than highly artificial questions.

Another thing I strongly believe in is using the same core problem when evaluating multiple candidates for the same position. It makes comparison significantly more meaningful.

It is fascinating to see how five different engineers can approach exactly the same problem in five completely different ways. Their questions, assumptions, trade-offs, implementation choices and communication style often tell you far more than whether they simply reached the correct answer.

Good communication skills are an absolute must.

The more senior you become, the more your impact depends on your ability to communicate.

Engineering is not just about writing good code. You need to explain ideas, defend technical decisions, challenge assumptions, communicate risks, collaborate with other teams and sometimes explain very complex concepts to non-technical people.

You can have an excellent idea, but if you cannot communicate it clearly enough for other people to understand and act on it, its impact becomes limited.

The same applies during an interview. The interviewer cannot evaluate thoughts that remain inside your head. Communication is therefore not just something being assessed alongside your technical ability - it is the mechanism through which your technical ability becomes visible.

Culture fit is very important, although I prefer to think about it as team compatibility rather than simply “culture fit.”

Software engineering is highly collaborative. Even an excellent individual engineer can negatively affect a team if they cannot collaborate, communicate respectfully, give and receive feedback, or take responsibility.

A poor hiring decision can affect much more than one person’s productivity. It can influence team dynamics, project delivery, morale and even retention. I have seen this happen in real teams many times. Of course, assessing this within a relatively short interview process is difficult. What you can do is identify the behaviours that matter most for your particular team and organisation and deliberately collect signals around them.

I usually look for things such as collaboration, respect for other people’s ideas, openness to feedback, willingness to take responsibility, curiosity and genuine interest in the product or domain.

Different teams will value different things, so the goal should not be to hire people who all behave or think the same way. It should be to hire people who can work effectively together.

The most common mistake I see is under-communication.

Candidates often have much more going on in their heads than the interviewer can see.

They may be considering edge cases, evaluating different algorithms, thinking about scalability, or questioning an assumption but if none of that is communicated, the interviewer cannot give them credit for it.

Learning to think out loud is genuinely a skill.

It feels awkward at first. When you practise at home, the people you live with may even start wondering why you are walking around explaining stuff to yourself (speaking from experience!).

But it is one of the highest-leverage interview skills you can develop.

Explain your assumptions. Talk through the alternatives you are considering. Discuss trade-offs. Say what you are unsure about. Let the interviewer understand how you think.

Of course, what you are communicating still matters.

So prepare properly, build strong technical fundamentals, practise explaining your reasoning and then show up as yourself rather than trying to perform some artificial version of the “perfect candidate.”

There is no shortcut to improve technical skills and unfortunately the answer is not particularly exciting.

Create a roadmap, sit down and do the work consistently.

Then do it again tomorrow.

And the day after that.

Doing this for a long enough period of time will take you surprisingly far. The important part is choosing carefully what you spend that time learning. Time is probably the most valuable resource we have and spending 6+ months getting very good at something that does not move you toward your goal can be much more expensive than the cost of any course or book.

Start with your target. Understand what skills that target requires. Identify your gaps. Build a structured learning plan around those gaps.

Then be disciplined. Do not rely too heavily on motivation because motivation changes from day to day. Systems, habits and consistency are much more dependable.

Keep learning, keep building and keep putting yourself into situations where you have to solve problems slightly beyond your current ability.

I’ve conducted some exceptional interviews and some very difficult ones.

The best interviews usually happen when the candidate is well prepared, technically strong and communicates naturally. The conversation starts flowing. You ask a question, they explore it, you challenge an assumption, they adapt and eventually it stops feeling like a formal interview and starts feeling like 2 engineers solving a problem together. By the end, both sides usually have a fairly good sense of how the interview went.

The hardest interviews are actually not necessarily the ones with weak candidates.

For me, the hardest are when you can clearly see that someone has a huge amount of potential, but they simply have not prepared.

You try to help them move forward, give hints, change the question slightly, or create opportunities for them to demonstrate what they know, but sometimes you cannot get enough evidence within the interview to justify moving them forward.

Those interviews are difficult because you can see what the person might be capable of, while still having to evaluate what they demonstrated on that particular day.

Arrive on time! Be prepared to find yourself in a situation where you will need to demonstrate quick thinking, the right attitude, and professional behavior.

One candidate joined an interview wearing one of those novelty drinking hats with straws running down to the person’s mouth. That alone was memorable.

But instead of the tiny cans you would normally expect, he had what looked like enormous bottles of Fanta attached on both sides.

He explained very seriously that he “thinks better when he drinks Fanta”.

Over the course of the one-hour interview, he somehow managed to drink around 5.5 litres of it and only left for the bathroom once.

The funniest part? Apparently, the Fanta worked. He absolutely smashed the interview and passed with flying colours.

To this day, I’m still not recommending 5.5 litres of Fanta as an interview-preparation strategy but I can confirm that for at least one candidate, the data point exists.