Even though interviewing for a software engineering job can be intimidating and frustrating (with whiteboard exercises, remote coding challenges, and even full days of onsite interviews), it’s a lot easier when you know what to expect and are well-prepared.
I’ve interviewed a few hundred software engineering candidates in the past 10+ years and designed hiring processes. My experience is limited to startups and mid-sized companies, so take everything you read here with that in mind. My advice may not get you into Facebook or Google but will definitely increase your chances at mid-sized companies with a good culture!
In the first part of this article, I’ll give some context, then give you an actionable list to improve your experience and chances in your next interview
If you’re only interested in the actionable list, feel free to skip ahead to it.
What you think about the technical interview might be incomplete
First and foremost, a technical interview is almost never only technical. Up to a certain (and honestly, very useful!) level growing as a ‘coder’ is not that complicated. Many candidates perform pretty well if we purely look at their coding skills.
The thing is, you’ll rarely work alone in isolation on your own codebase. You’ll have teammates, you’ll need to agree on things with them, you’ll build on others’ code and others will build on your code. You’ll need to build solutions with a certain level of quality, in a future-proof way, for extensibility, and with performance in mind. Depending on your role and level, you’ll need to architect systems. You’ll need to mentor other engineers. You’ll need to onboard new team members. You’ll need to proactively reach out to other teams in the company and understand their points of view and problems. You’ll talk to product managers, UX researchers, designers, even customers sometimes. You’ll need to manage projects, make tradeoffs and decisions, and align other engineers with that.
Read my article on the most common 11 technical interview myths
Types and stages of technical interviews
Most companies use a combination of these steps:
- Screening call with a recruiter – We’re interested in your basic motivations, we’d like to have a gut feeling about what you’re looking for and do some sanity check here. You might get asked about your salary requirements, support you need for visa or relocation, and timelines (when could you start, etc.). Some recruiters will also ask you whether you have applied elsewhere so they know how urgent this is for them and you.
- Screening call with the hiring manager – Expect some deeper dive into your experience on multiple fronts – tech and ‘soft skills’ alike. As a hiring manager, I’ll prepare by checking out your CV for talking points, maybe even your LinkedIn profile, and definitely GitHub. I’m not trying to judge you, I’m just looking for points of connection. I’ll answer any questions you have about the role, the company, the culture, potential teams you’d be joining, etc. etc. My ultimate goal with this is twofold: would we be a good match for your (and vice versa) and whether I think you’d be successful in the role.
- Remote technical screening – An alternative, or at some places precursor to the online coding exercise. This is with a human on the other end of the line – solving tech problems together, usually, you walk them through your solution.
- Online coding exercises (LeetCode, HackerRank, etc.) – I know you all hate this. We need such a step to filter out people who can’t even code at all early on. You’d be surprised about the number of such applicants. I avoid algorithm/data structure exercises here and try to come up with somewhat interesting ones. Some companies use a much heavier set of exercises and base their judgment of your technical skills solely on this. While I don’t agree with that strategy, you need to get prepared for this, too.
- Take-home assignment – this is one of the most polarizing interview steps for engineers. Some hate it, claiming it’s just free labor for the companies and it takes too much time, others love it because they feel they have the freedom of giving it much time, really showing off their skills in their own comfortable environment. Whichever camp you’re in, you can expect some companies requiring this. You usually get a somewhat specified problem to solve and you’re given different levels of freedom on how to solve it – some companies don’t mind you choosing whichever stack you like, others will even specify the framework.
- Onsite workshop / remote workshop – I think this is the most interesting of all steps (well, for me at least). It’s about solving problems together with people from the company in a simulated environment. You’ll need to show your communication, decision-making, and even prioritization skills here. Sure, people will look at the quality of your code, too, but ‘soft skills’ are just as important here. We’ll get strong signals about how it would be having you on the team.
Cracking the technical interview
Ask the recruiter or the hiring manager before the interview
Take the guesswork out of the equation. If you feel you don’t have enough information to prepare, just ask for more! We’re here to help you succeed. I really mean it. Sometimes we aren’t doing a great job with sharing enough information proactively about the interview steps but that’s not intentional! I’m always happy to help you prepare better – ask about anything, please. You’re doing both of us a favor with that. Ask during the previous interview step or just drop me an email at any time.
Show up on time
Make sure you’re there on time. If you can’t, for some reason, please let us know, we’ll happily organize for another time, no hard feelings. Showing up on time isn’t only about respecting each other’s schedule – interview time slots are usually 100% utilized and by arriving 10 minutes late you’re reducing your own chance to be successful. You’re also making it more stressful for yourself than necessary. If you need time for commute or for your Zoom/Google Meet setup, think ahead and give yourself a buffer before the start.
Don’t jump right into solution mode - read, distill, paraphrase
The biggest mistake you can do is thinking you understand the problem or what’s asked of you and jumping right into coding. Take your time, carefully read the problem statement, distill it, don’t think of solutions just yet. When you feel you understand what’s asked of you or when you thought about clarifying questions to ask, communicate. Paraphrase what you understood from the problem statement so you can verify it with your interviewers. Only when you’re on the same page can you shift into solution mode. Even if you come up with the best solution ultimately if you skip this step I’ll remember and have doubts about how it’d be to work with you. Thinking aloud is really useful here - it will help you and help me too to understand what’s on your mind.
Be articulate and communicate clearly
Even if you know your trade, if you fail to communicate clearly during your interview we’ll have no way of knowing. This takes practice for most people, so take your time and prepare! Use standard terms that other engineers can relate to, avoid passive voice, and be able to articulate what’s going on in your mind while you’re thinking. If you need some time to think quietly, say so, don’t just fall silent suddenly. We’re trying our best to communicate our expectations around this but it might be a bit late when you’re in the interview. Trust me on this one, practice here goes a long way.
Ask clarifying questions
While you’d think the interview is about you answering questions, expect that you will need to ask a lot of questions! When you are in the interview and something is not clear don’t default to thinking “Oh god, I should know this, I should understand” – sometimes we are interested in how you behave in such situations, and sometimes we’re just simply not good enough in giving enough context. If you’re stuck, a good technique is to ask for clarification! It’s also 100% OK to say things like “I didn’t quite get that. Could you rephrase please?” or “I’m not sure I understand what you’re asking”. These are good signals! I expect my team members to behave like this. These are not signals of you failing. I know it feels like that, but trust me, it’s just your brain playing tricks on you. I highlight this during the interview several times, to make sure the candidate feels safe asking such questions. Another technique I wholeheartedly welcome is paraphrasing – e.g. “What I understood from what you said is that I should implement this using co-monads” (said nobody ever).
Demonstrate your tech skills the right way
Make us see that you’re deeply proficient in at least one technology. This can be a programming language, for example. Also, demonstrate that you know the adjacent technologies – most companies are looking for so-called T-shape engineers. This means that mentioning other aspects of the problem and the solution goes a long way. For example, if you’re asked to implement a service in NodeJS, mention how you’d deploy, monitor, and scale it, even if that’s not explicitly asked. No need to go into too many details (unless people ask you). If you’re only focused on a single piece of the puzzle I’ll have a hard time seeing how you’d perform well in a changing environment (where you’ll need to make connections and work on multiple zoom levels and be ready). This is a very generic statement and might not be true in the case of highly specialized roles, of course. On the other hand, if you say your primary language is Python yet you can’t seem to show even a basic understanding of it, that’s a no-no. Work on the stem of that T, too. Hopefully, you’ve clarified what you’d be doing on the interview upfront (see advice #1) so you can think about adjacent technologies in advance.
Don’t get too focused or stuck on a solution
Sometimes a solution you came up with just won’t work. No biggie – happens to us all the time too! Just state it and move on. Unstuck yourself. We’re way more interested in how you think about problems and solutions than whether you can come up with the exact right thing on the first try. We prefer failing early. It’s also completely fine to ask early on what we think about a specific solution, you’ll probably get good hints that way.
Demonstrate some interest in the role
The easiest way is to simply ask some meaningful questions. I’m sure you want to know a ton of things about the job! From the tech stack to who you’d be working with, what culture we have, how are processes, what your role actually means in practice, where the company’s headed, are we financially stable, etc. etc. – use your interviews to ask these questions! By this, you’re not only gaining knowledge but you’re also communicating that it actually matters to you where and how you work. A few examples: “What’s the biggest technical challenge for the company at the moment?”, “How do engineers interact with product managers here?”, “What do you dislike the most in working here?”.
Don’t talk badly of a stack or language
Somehow talking badly of languages became a norm on the internet. It’s not only uncool but also demonstrates a lack of deeper understanding and professionalism. We all have our loved and hated technologies but ultimately it’s about different tradeoffs and different tools for different jobs. You can turn your dislike about that piece of technology into a positive thing by objectively arguing why your favorite thing is better suited for the job. The same goes for the way you talk about your previous or current companies – while it’s fine to describe what’s wrong there, please keep it objective and professional. It does help me understand what’s important for you and trust me it can be done in a respectful fashion.
Practice with a friend
This will help you feel so much more confident in an interview and confidence makes a world of a difference! Practice multiple things – from coding to talking about code, speaking what’s on your mind, phrasing things in different ways. Get a friend who can give you feedback. Practice will also give you a good sense of how much time things take – your interview will be time-boxed.
If you get stuck
Don’t panic 🙂 It happens to all of us. Take a moment to think. Catch your breath — clear your head. It’s completely OK to present a partial solution or a differently scoped one. Feel free to ask for some help or pointers. Your interviewers are prepared for this and this doesn’t mean you’re failing. Just be honest that you’re a bit stuck, we’re there to help you! That’s what we’d do with a teammate too! Remember, we’d like to understand how it’d be to have you as a teammate. I’m sure you’d be fine asking for some help in a team, so just do it in your interview, too!
How to stand out in a technical interview and be a memorable candidate
In my experience the most memorable candidates are genuine. They are honest about what they are looking for, they are willing to talk honestly about their gaps, too. They demonstrate that they are not fixated on code only, they understand that solving problems is a complex endeavor on multiple levels. They understand how to work together with others, including other functions. They are life-long learners and can give examples of things they’ve recently learned and also reason about why they chose that specific topic.
Candidates really stand out when they can tell a story of their career – including where they want to be. Good candidates understand and can describe how the next role they want to land looks like. They demonstrate self-awareness. We humans can relate best to stories. Use that! Create a narrative.
Memorable candidates can tell stories about ownership. I don’t mean technical ownership only, but demonstrating end-to-end understanding and care. I know you aren’t a salesperson or a marketing specialist but you can still show that you understand how that last feature you’ve developed is important, how users/customers are using it.
Read my article on the most common 11 technical interview myths