How to do better in a technical interview? Part 1: the project
Why should you even listen to me?
I have attended many interviews during my career, and I have conducted even more. I have made some stupid mistakes along the way, and I have seen many candidates doing the same. I’m hoping this post helps you perform better in an interview, better demonstrate your skills and experience, and basically not shoot yourself in the foot.
I work in a big company where we have a fairly formal hiring process, but here I’m going to only focus on what we called “technical interview”. You can see something very similart to this in other places with different names.
What is a technical interview?
Let me first clarify what I don’t mean by technical interview, so you don’t get disappointed. It is not the coding interview, where you are asked to roll your sleeves up and write a piece of code on a computer or fix a bug. It is not that “design Twitter in half an hour” kind of system design interview either. I’m talking about a reasonable process, where the interviewers are genuinely interested in the work you have done, and present you with problems you are likely to face in a day-to-day life, should you be hired.
When I first started conducting technical interviews, this was how the interview worked: We would start by asking the candidate to tell us about their current work and a project they had recently done. Then, based on what they had worked on, we would ask various questions in order to gauge the breadth and depth of their knowledge. Finally, we would ask them to implement a component based on a given contract (like a connection pool). We ended up retiring this interview style a while ago, more on this later.
The first part of this interview gave us a very good idea about the candidate’s role and contribution to the project and their skill level. Despite being a great way to know the candidate more, it didn’t give us a comparable signal about their proficiency level. A lot depended on the candidate’s presentation skills, the interpretation of the interviewers, where they decided to dive in, and how familiar they were with the subject. Imagine you are hearing about an Android app one day, an embedded system tomorrow, and a PC game the next day.
The 7 tips
This said, if you are going to an interview like this, keep these in mind to avoid mistakes that could cost you the job you are applying for:
- Don’t dive deep in the details without describing the problem you were solving. It’s worth giving a general context about the team, what the project was about, and what you shipped. After the brief introduction, focus most of your response on what you did. The interviewer is mostly interested in understanding your role in the project.
- If you get to pick your project, pick one that demonstrates the abilities that are important for the company you are interviewing with. Your interviewer are most likely interested to know how you work within a team, decide what to work on, test and release your changes, respond to feedback on your code, etc. If you chose a solo project, it’s only your fault if no-one can see what a great team player you are.
- Timing is very important. When they say “please give us a brief summary about the project”, don’t just go on and on and on. You probably have about half an hour or something to discuss the project, don’t just spend half of that time telling the history. They will appreciate that you respect the time constraints. If you are not sure, please ask how much they want to know and more importantly what they want to know more about. Pause and see if they are still following and if they have questions.
- The interviewers are looking for a lot more than your technical ability. They might ask why you made such decision, how you made the decision, or what you think about it now. They need to know whether you respect your team mates, support a team decision, understand the bigger picture, take responsibility, and more importantly whether you have learned anything to do better next time.
- It’s a very good sign if you know more outside the boundary that you have directly worked on, but it is perfectly fine if you don’t know the details of an external system or an internal dependency. It’s a lot better if you are honest and don’t try to bullshit your way out of it. We will simply focus on something else you might know better.
- The interviewer understands how projects are done in real world and how they are not perfect on day one. However, be careful about being content with a broken system and no desire to fix their problems. Expect to be asked about reliability issues, scaling pain, or performance bottlenecks. I’m not sure which one is worse: being ignorant about them, or not acting upon.
- Never ever ask how you did in the interview. Instead, try to understand more about the interviewers. Why they were interested in certain topics? What were the problems they were facing? Be curious, you might find something in common to talk about in the very last minutes.
Here is more
In part 2 I have explained the problem solving part of the process I just described, which you would come across more often.
