Six months ago, I was on the other side of a technical interview for the first time. Today, I’m going to share what I’ve learned so far. Here are three quick ways to take luck out of the equation and signal your competencies to the interviewer.
I’ve conducted many technical interviews now—some more memorable than others—and I’ve lost track of the exact number. I’ll guesstimate somewhere around 36 interviews: approximately three interviews every two weeks. I’ve noticed three main mistakes that candidates make at the mid and senior level, especially if they don’t interview often. The good news? These mistakes are easily avoided.
Ask for the interview structure
The first thing you do when you’ve progressed to the technical is ask the recruiter for the interview structure. This gives you an idea of what to expect, and you can prepare accordingly. The conversation usually goes like this:
Candidate: What can you tell me about the interview structure?
Recruiter: We’ll ask you to deep dive on a project, then there’s a programming (leetcode) task, a system design task, and finally a chance for you to ask questions about our company.
In your mind, break it down into bullet points:
- project deep dive
- programming problem
- system design
- question time
Now you’ve got something to work with.
What if the recruiter doesn’t know, or won’t tell me?
Follow up via email and be persistent (but reasonable) until they tell you. Their job is to ask the team and relay the information to you.
If they don’t respond in a timely manner, or refuse to tell you, let that indicate the level of professionalism at that company. It may not be the fault of the particular recruiter, but it’s a signal of bad management. Remember that hiring goes both ways; you’re evaluating the company as much as they are evaluating you.
Prepare your answers in advance
Now that you know the interview structure, remember that failing to prepare is preparing to fail. Revising reduces nervousness and always improves the outcome. Create a document to keep track of your prepared answers. Here are some ideas to get you started.
Experience-based questions
Communicate your experience upfront–don’t bury your impact and force the interviewer to probe. These days, LLMs like Claude and ChatGPT can brainstorm questions for you which simulate what interviewers might ask, and you can practise by writing your own answers to those questions.
When I was interviewing, I had a “megadoc” containing sample questions, answers,
and even an application tracker.
Programming-based questions
Practise a systematic approach to solving programming problems (e.g. Leetcode). You must know basic DS&A and Big O notation—that’s not negotiable. Programming problems may sound contrived, but it’s an opportunity to demonstrate your problem solving and communication skills, not only your ability to reach a working answer.
The programming task proxies how you approach ambiguity in your work. Interviewers don’t just evaluate time complexity or time-to-implement, rather they are actually seeing whether you can communicate your thought process, think of edge cases, and brainstorm multiple approaches before committing. Practising your systematic approach makes solving the problems easier!
Your “practise” will involve consistently applying your systematic approach to Leetcode problems until it’s second nature. For example: determine constraints, identify edge cases, propose high-level solution, implement, and test. My favourite book on this topic is Programming Pearls by Jon Bentley, in which Bentley expresses the importance of exploring the problem first before jumping into code.
Systems-based questions
Practise your approach to solving system design problems—that means going beyond memorisation of an AWS product “shopping list”.
System design is the key differentiator between engineering seniority levels. It signals critical thinking, technical depth, structured problem solving, and your ability to elicit requirements from non-technical stakeholders. Fail to come up with important edge cases, or over-complicate the solution, and you’ll be viewed as junior.
I’m a fan of ByteByteGo system design examples, which will teach you a structured approach to gathering functional and non functional requirements. These examples also introduce you to new technologies, which helps to signal to companies that you have broad knowledge which goes beyond what you encountered in your past role. However, this is not the only resource—YouTube has countless example system design solutions.
Finally, don’t be intimidated by the complexity of some examples. In a real interview, you’ll ask clarifying questions to determine the actual complexity of the problem—it’s often simpler than one might think!
Leave your ego at home
If you’re spending two hours in a room with the people responsible for hiring you, being argumentative results in nothing good! Please, leave your ego at home and you’ll make a much better impression.
Interviewers deliberately ask questions to challenge your reasoning and force you to justify technical decisions. It’s a proxy for how you handle conflict in an engineering context. They’re not being disruptive. You need to defend your point of view in a professional manner.
Here are some quick ways to show that you don’t have an ego:
- Instead of assuming you fully understand what someone’s talking about, ask “What do you mean by that?”. It’s an open-ended question which gives the other person space to elaborate. They will feel like you’ve really considered their idea, and you may even learn something!
- Instead of saying “No, that won’t work.” ask “Okay, what about {edge case}?” because it points out the differences of opinion rather than rejecting their idea upfront. It shows you actually thought about what they said.
- Avoid certainties like “obviously”, “clearly”, and “everyone knows”, unless the topic is actually obvious, clear, or you can prove that everyone knows it! Otherwise, your ego is showing. Try saying “given what we know so far” and then make your conclusion.
Engineers face interpersonal conflict every day: code reviews, design discussions, and planning meetings. Interviewers want to see you balance strongly held opinions with the needs of the business, and this is communicated with nuance. It’s a signal of immaturity when you dismiss ideas you disagree with.
Don’t stress, remember the Pareto principle
This can seem like a lot to digest, but don’t stress. Improving the interview outcome takes less practice than one might think. If it feels like you’ve only covered 20% of the content, then I expect your outcome to improve by 80%. Quantifying that is up to you, but you’ll be lightyears ahead of the next candidate who prepared nothing at all.
Have questions about this article? Leave a comment below!