The Secrets No One Told You About Technical Interviews

Tribal Knowledge from my Tribe to Yours

Have stock photo models become self-aware or is this woman completely unsure of how to mimic human emotions?

Interviews are weird. How can we learn everything about who a person is as a colleague in 30 minutes to an hour? Technical interviews are even weirder… because they’re secretly standardized.

Yeah. Did you know that? Technical interviews follow an incredibly predictable pattern, across not only companies but roles. If you are interviewing for a job where you will be writing and reading code, you’re essentially going to be given a standardized test. It fits with the tech industry’s obsession with meritocracy. A standardized interview is fair because then everyone has an equal chance to do well, right? Yeah if they know that’s the game that’s being played… and if we’ve all agreed on the game.

That’s the issue with the theoretical meritocracy of technical interviews. Industry-wide there is a pretty predictable set of “rules”, but no one’s bothered to commit to an official rulebook. Not even within a single company will you find truly consistent rules applied. Now that I work at Karat, we’re committed to creating an interview experience built off of these accepted industry-wide rules, but one that is truly consistent, rigorous, and most importantly human. However, as we work to make the rulebook truly transparent, it is painfully clear how very dark a lot of these rules still are to most candidates.

There is a TON already written on the topic of “how to prep for a technical interview”. Seriously, go Google something. But too often I find students get tripped up on the unspoken aspects of the interview. For now, I wanted to round up what I consider to be the “secret” requirements to acing the technical interview. These “secrets” are very well known in communities that are over-represented in tech… and are almost completely unknown in communities that are underrepresented *COUGH* not a coincidence *COUGH*. So from my tech tribe out to you, my hustle tribe, here are the
“secrets” you’re expected to already know about technical interviews.

full of secrets and dry shampoo

Interview Basics

Technical interviews, whether 30 minutes or 60, for entry-level or senior, in person or over the phone, on a whiteboard or on a computer, tend to follow this pattern:

1. Introductions — 30 seconds to 2 minutes of your elevator pitch on why you are interviewing for this job.
2. Project Discussion —discuss the details of something on your resume, impress me with how you actually get stuff done.
3. Coding Problem — write code, right here, right now. It’s like an exam, but you have to talk out loud and be charming at the same time.
4. Time for Your Questions — oh you thought you were done? JK! You better show me you’re smart and in it for the right reasons.

Below I will discuss each of these segments in more detail.

0. Before the Interview

Treat a technical interview like a standardized test. It’s not about how good a coder you are (sorry) it’s about how good you are at this test. Sure! If you’re great at math maybe you don’t need to study for the SAT… but would you take that chance? The biggest reason I see qualified candidates get rejected is that they didn’t even know they were supposed to study for the interview.

Secrets you should know:

• Pick an OOP language, get goddamn good at it. It really doesn’t matter what you pick… just please dear God don’t pick Javascript. Or C, please don’t do trees in C. (those are just my opinions, don’t @ me)
• Have you read “Cracking the Coding Interview”? Because your interviewer and every other applicant probably has.
• Practice writing code without an IDE/Compiler/Computer. Now practice doing it while you talk out loud. It’s fucking hard to do.

1. The Intro

Often kicked off with “tell me a little about yourself” this is your opportunity to set the tone and explain to the interviewer why you’re a fit for this role.

Secrets you should know:

• It is very likely your interviewer has not already seen your resume and is reading it for the first time as you talk. Structuring your intro to match the flow of your resume will give you control over the conversation.
• This is your chance to hint at the part of your resume you actually want to talk about, don’t miss your chance.
• YOU BETTER KNOW WHAT THE COMPANY DOES. Dear lord please at least have read their company webpage. STORY TIME- once I googled a company as I was sitting outside the door waiting for my interview. All I read was the tagline at the top. First thing I said was “hey super curious about your new line of X products”. Later my manager told me that was the actual reason I got the job because “it was so refreshing to have someone so interested in what we do”. 100% true.

2. The Project Discussion

This is the part of the interview that is going to vary the most. If you are more senior, you better have a badass project to talk about. If you’re still a student, it’s ok if your project is a class one, but make sure you have something to talk about. Sometimes the interviewer will pick, sometimes they’ll ask you to pick. They will likely want a software project, but some companies are just looking for examples of how you work with others and get things done.

Secrets you should know:

• Avoid “we”. Interviewers are trained to go deeper when we hear a candidate use “we” a lot, it usually indicates someone talking about a project that was much bigger than their own contribution.
• Tell us what impact did you make? We’re engineers, we love numbers. Can you measure what you did in employee hours saved, clients acquired, bugs avoided, dollars saved, users impacted blah blah? Because that shit STANDS OUT. It also helps contextualize the importance of your project,
• Be prepared for detailed questions like: “why did you use that particular technology?” “what was the biggest challenge in implementing this?” “what would you do differently if you were asked to do this project today?” There will be follow up questions, so have planned answers to the above.

3. The Coding Question

Often the part of the interview alotted the most time. There are a lot of resources out there for you to get experience with what types of questions will be asked: www.leetcode.com, www.codestepbystep.com www.hackerrank.com and soooooo many more. Cracking the Coding interview is essentially just a textbook full of sample interview problems. For this part there aren’t many shortcuts, you just have to study your little butt off.

Secrets you should know:

• Some interviewers will intentionally give you vague questions to see how you “scope” a problem or how you “deal with ambiguity”. Yeah, literally you understanding the question is part of the test. After they give you the question, ask them questions. Ask for sample input, ask for assumptions you can make, ask for requirements and limitations etc…
• Syntax doesn’t technically matter. Mostly because it’s likely that you’ll be doing your interview in a language the interviewer is not familiar with. This means you can’t ask them for syntax help, so if you forget an API you could be screwed… or you can just put something mostly correct and they won’t even notice. STORY TIME — once in a panic I 100% forgot Strings are immutable in Java and used the swap from the outside in method to reverse a String. Interviewer said nothing, they didn’t know Java, got the job.

EXCEPTION: some interviews now use actual coding environments instead of whiteboards, but these often lack intellisense, so you just have to actually remember syntax. Be prepared!

• TEST. YOUR. GODDAMN. CODE. I can’t tell you how many times I’ve watched someone get to the end of their first implementation then say “ok I’m done”. I then ask “are you sure? anything you want to test?” (you know, because I’m nice and I’m giving you a hint) and they say “Nope!”. Sorry, unless your code is perfect, you just failed the interview. At the verrrrrrry least list out a set of test cases, you would try out and talk through whether your code works or not for them. Even if in this process you find a case you missed, tell the interviewer. Often you’ll still get full credit just for identifying the bug.
• You’re going to be asked for the runtime complexity and memory usage of your solution, often using “Big O” terminology. This is the ideal time to suggest optimizations to your code. Like finding a bug during your testing, if you identify an optimization after the fact, calling it out can sometimes give you equivalent credit for an optimal solution.

Academic sidebar — people in industry incorrectly use the term “big o” in place of what they often mean which is “big theta”. If you say “big theta” or “big omega” in an interview they will have no idea wtf you’re talking about.

• The code you leave on the board or in the environment is your lasting mark. Lots of companies actually save it, either by taking a photo or as a file. It’s totally ok for it to be messy, but if you identified optimizations or bugs, maybe note them so that lives on in your file. Also, try not to use crappy single letter variable names, the more readable your code the easier it will be for your interviewer to fill out your feedback later.

4. Time for your questions

Almost always foreshadowed by “and I’ll leave time at the end for you to ask me questions”. This section is often treated as an afterthought, often to the candidate’s misfortune.

Secrets you should know:

• DO NOT USE THIS TIME TO ASK ME IF YOU PASSED THE INTERVIEW. Sorry, but it’s awkward and most interviewers will feel awkward being asked. Then you leave the room and that’s the last impression you made before the interviewer starts writing your feedback. I get it- you’re dying to know! Just wait and ask your recruiter for any feedback later. Often they literally legally cannot give you any, but that’s better than the above.
• Try to avoid awkward or aggressive questions. There is absolutely a time for you to ask about compensation, company missteps, culture concerns… after you get that offer. This is the time to show you’re interested and thoughtful. Please don’t ask me how much money I make (yes, has happened, multiple times).
• You must ask a question. Some interviewers don’t feel as strongly about this as I do, but if you have literally no questions for me as an engineer working in the position you are hoping to be in- clearly you are not that interested. Or you’re not thoughtful. Can’t think of something? Ask them what their favorite part of the job is, or what their favorite project has been. Those are questions you can ask lots of different people and still learn something each time (and people love to talk about themselves so they’ll be in a good mood when you leave the room and they start writing your feedback).

EXCEPTION: Some companies are moving to models where another party that specializes in interviews conducts the first round (https://karat.io/) So asking these engineers questions means nothing.

There is a TON more I can say about interviews, I am sure I will write plenty more on the subject in the future so stay tuned. In the meantime, if you have any other “secret” rules I forgot to call out- leave them in the comments below!