How to Stand Out During the Tech Interview

I was recently asked by Laurence over at Learn to Code with Me to offer some advice about an article they’re putting together on how to help candidates stand out during the technical interview. A lot of my answers made their way into the final article, but I thought I’d share my full answers here in case they’re useful to anyone else.

Q1: What are the specific ways a candidate can not just succeed, but *stand out* during the tech interview?

A1: Come to the interview with a project to talk about, but make sure it’s at the right level of complexity.

A lot of people will advise job hunters to build a project and showcase that during the interview. This is a great tactic because it allows the candidate to flip the conversation from being grilled to showcasing their ability. The conversation also moves from a potentially antagonistic back and forth to a more aligned brainstorming discussion, almost like colleagues working on a project together.

However, if you want to impress, the exact type of project will vary depending on the job role for which you’re applying. A good general rule would be to build projects that, at minimum, match the complexity of work for the job you’re applying. Prospective employers will then be able to see that you not only can but actually have done work at the level that they require.

Most people start the opposite way. They’ll follow some tutorials or build an idea that seems interesting, and then take what they produced to see if any employer will find that impressive. Usually, the projects won’t impress good employers and candidates have to ask prospective employers to imagine what they could do if only with some guidance or help.

Instead of asking employers to bridge the gap, smart candidates should target specific roles. Study the requirements of the role and the type of projects the role is expected to work on. Then map out a way to independently produce projects of approximately equal complexity. You’ll stand out if you bring that type of project to the interview.

A2: Understand fundamentals.

Good interviewers are trying to probe for the edges of a candidate’s ability. This means that most questions will not be based on gotcha-knowledge, such as specific syntax of a rarely used API. Instead, the interview conversation will be probing your ability to deconstruct complex concepts and seeing if you can peel back the layers. This requires understanding not only how to build a feature, but how to deconstruct the feature. For example, during the course of conversation, an interviewer may ask “If you had a page that’s experiencing performance issues, how would you go about figuring out the bottleneck?”. This open-ended question is simultaneously assessing a candidate’s knowledge of fundamentals, and at the same time allowing the candidate to show off their depth of understanding across a variety of domains. The answer here can range from front-end asset compilation, to web server caching techniques, to database performance optimization, etc. It’s these open-ended questions where interviewers can separate those who can build simple features from those who can work at a deeper engineering level. The only way to stand out is to understand the fundamental concepts that underpin the feature in question.

A3: Speak clearly and precisely.

Though it may not seem like it at first, vast majority of programming roles are, at the core, social roles. Since programmers work with abstract concepts, speaking clearly and precisely is paramount. Most good employers put an extremely high emphasis around hiring clear and precise speakers. Pay attention to vocabulary, even on seemingly simple concepts. Refer to a concept by its formal name and avoid ambiguity. For example, instead of saying “it calls that function and the result is 5”, say “the add_numbers function call returns 5, which is assigned to the variable sum”. Avoid pronouns and ambiguous words like “result” (usually, there is not a “result” but some output, side effect, or return value). The second example demonstrates clarity of thought and precision of language, leaving the reader with an unambiguous account of what the code is doing.

Q2: How should a candidate prepare for the tech interview? (Any specific websites or resources they should use to study?)

How the candidate should prepare depends on the type of interview. Some companies, especially ones modeled after the Google-style of interviewing, use algorithms and whiteboarding. Others, however, eschew whiteboarding for pairing or code challenges. Still others do neither and instead focus more on “fit”, as long as some baseline technical ability is met.

If it’s a whiteboard-oriented interview, make sure to use resources like Pramp and books like Cracking the Coding Interview. If it’s more pairing, then make sure you know what language they’re going to use and brush up on its syntax so you’re not stumbling around during the pairing session. If they follow specific development practices, like TDD or Github Flow, then refresh or study up on that. It’s usually ok and appropriate to ask what type of interview it will be and what languages will be used.

But in general, there are still a few things candidates can do no matter what type of company it is.

1. Practice. Interviewing is a skill and you’ll get better at it over time. Take the practice seriously. Ask friends to interview you, record yourself (and watch the recording), and practice, practice, practice. Your 20th interview will be dramatically different from your 1st, so try to get to the 20th in a practice setting and your first “real” interview will actually be your 21st.
2. Research the company and role and even the people interviewing you. Be excited about the company or project, and that positivity will come across in the interview.

Q3: What are some of the most common mistakes you see candidates make? How can those mistakes be avoided?

Most common mistakes are not following what I wrote earlier, like not understanding fundamentals or not speaking clearly. But I’ll try to mention a few other pointers here that might be helpful.

1. Don’t be arrogant or too opinionated. This sometimes happens when people learn a new process or technique, like TDD, and then become an evangelist for that technique without context. For junior developers or those with less years of experience, it’s more important to come across as being malleable and eager to learn, so the employer can envision you in a variety of projects and roles. Even seemingly innocent statements like “I never write code without tests” or “I love X and don’t like Y” may come across as too opinionated. Employers hear that as “I’m limited in my ability to work in a certain way, even if we really need to work in that way”, which is probably not the message the candidate is trying to convey. Instead, a candidate should be tempered in their preference; for example “I prefer to write tests with all my code” or “I’ve been enjoying X lately, but also have experience with Y”.
2. Don’t be too shy. I’ve seen employers make excuses for a candidate when they missed a question, and I’ve seen employers nitpick the smallest of mistakes in an otherwise flawless interview. What’s the difference? It’s the “feeling” a candidate gives the interviewers. An interview is not just about answering questions correctly, but also about a conversation. If your natural disposition is so introverted that you can only muster up enough words to answer the question and no more, practice making conversation. It’s important to keep the flow of the conversation going. Laugh and make jokes at appropriate junctures. Ask good questions. At the end of the interview, even if you missed a few questions, the overall “feeling” the interviewer had of you should be positive. If you know that you are not a great conversationist, make sure to focus on improving this.
3. Don’t give up on an open-ended question. A lot of candidates seem so overwhelmed by open-ended questions that they gave up before even starting. A good interview will have reached the boundary of your ability and pushed you just a tad beyond to figure out a problem. Therefore, in a good interview, you will always be made to feel uncomfortable and be given a problem that you can’t just solve right away. Make sure to have a process before the interview that you can rely on to deconstruct questions. If you don’t have a process, it’s not going to be possible to figure one out on the fly. Think about how to do this beforehand. For example, one that I recommend to people is PEDAC.

Q4: What are you specifically looking for during the whiteboard/coding challenge?

Whiteboarding interviews are unique in that it’s more about skill and less about knowledge (well, that’s the goal anyway). Therefore, there’s really no place to hide and it’s difficult to BS your way out of it. Employers are looking for a candidate’s ability to solve problems in a structured and systematic way. Along the way, they will also expect candidates to demonstrate knowledge of performance and optimization tradeoffs between space and time complexity. This will require applying algorithms and data structures to the current problem.

Another component of white boarding interviews is around designing a system, where candidates are asked to zoom out of application code to a larger system and think about how data may flow between systems and larger infrastructure impact. Questions can run the gamut here from web server proxy architecture to tradeoffs between different database sharding techniques. Questions are also very open-ended and can be as simple as “how would you design Youtube?”. The goal is not to see if the candidate knows a specific piece of knowledge, but if they understand how systems interact and consequences of infrastructure decisions. There are no right answers, but there are definitely wrong ones. Employers want to see if candidates understand the tradeoffs between the non-wrong choices.

As for the coding challenge, this is typically a lot less rigorous than the whiteboard and many companies give candidates a day or more to work on it. Employers are looking for coding fluency, commit hygiene, testing habits, and how the candidate thinks about a problem. It’s common for employers to ask about decisions made in the take-home code challenge during follow-up live interviews and probe the candidate to explain why certain choices were made. This is why it’s imperative that you don’t get help on the code challenge; if you do, you will be exposed during the follow-up conversation.

Q5: What should a candidate do if they don’t know the answer to a coding question?

Candidates should have a process to deconstruct questions that they don’t understand. First, ask questions around assumptions of the question, and try to reason about the question from a bottom-up perspective. This approach, of course, requires that you have fundamental knowledge. Then, make assumptions of your own by isolating parts of the question. For example, you can say “I don’t know the answer to this specific scenario, but if we remove the database, for example…” and then you can shave off a big piece of the question and zoom in on what you know. This won’t always work, but it gives you a chance to stabilize yourself in what can be a tense live interview setting. It also buys you some time to think through the question while also removing parts of the problem that’s confusing you.

Practice using a process well before any interviews (once again, see https://medium.com/launch-school/solving-coding-problems-with-pedac-29141331f93f)

In some cases, there are just “either you know it or you don’t” type of questions, and you can just say “I don’t know that”. Good employers will typically avoid these types of questions since it’s pretty easy to look up documentation, but it is a bad sign if that’s your answer even for the basic questions.

Q6: What is your #1 piece of advice for candidates going through the tech interview process (especially for the first time)?

Figure out what type of interview it is, and practice, practice, practice!

Q7: Any other tips/tricks you’d like to share?

• Iterate on various practice techniques, like speaking in front of friends or recording yourself.
• Keep emotional stability. Expect to get rejected a lot, and it’s important to not view it as personal judgement.
• Keep it positive, always. Never say anything bad about a previous employer, colleague, etc during the interview.
• Have fun. Remember you’re basically asking for money, so try to keep it light and fun and you’ll come across as a more pleasant person with whom others can envision working.