This article first appeared on the Triplebyte blog and was written by Joseph Pacheco. Joseph is a software engineer who has conducted over 1,400 technical interviews for everything from back-end, to mobile, to low-level systems, and beyond. He’s seen every quirk, hiccup, and one-of-a-kind strength you can think of and wants to share what he’s learned to help engineers grow.
Technical interviews are not just about your knowledge and experience. They're about demonstrating specific pieces of your skillset in really suboptimal circumstances.
Related: The best, worst, and most interesting moments from my marathon month of technical interviews
That is, technical interviewing itself involves a whole set of skills needed to pass. Candidates often focus heavily on specific knowledge gaps when preparing, while some don't prepare at all if they feel confident in their knowledge. What they don't realize is candidates fail just as often for lack of practice as they do for actually lacking the engineering skills required. Here are six features of technical interviews that are addressed mostly, if not entirely, by practice – experience and knowledge aside.
1. Artificial time pressure
The flavor of time pressure you experience in interviews is very different from the kind you experience on the job. Sure, you may be used to tight deadlines or putting out multiple fires over the course of a day. But rarely (if ever) is there a circumstance where you are asked to solve a problem over the course of exactly thirty or forty-five minutes. That is, the problem starts at a planned time, before which you know little or nothing about the details. Then a timer begins and you're given a document to read describing this brand new problem. From that point, you're expected to rapidly digest all the implications and solve it before an abrupt stop when the time runs out. That's not like anything I've ever done in the real world, and I suspect that's the same for most of us.
If you dive-in to this kind of situation with no prior experience, you're probably going to choke. The process is going to feel jarring and disorienting, even if the problem itself is well within your wheelhouse. But if you expose yourself to situations like this repeatedly, certain key habits start to sink-in. Eventually you'll find yourself snapping into action as soon as the timer begins, taking advantage of strategies that allow for the efficient digestion of the problem, and taking handy shortcuts that adapt to the limited timeframe. These are not things you want to work through for the first time during the interview, and being ready is simply a function of repeated exposure.
2. Contrived problems
Relatedly, the kinds of problems you're asked to solve in technical interviews are often very different from those you tackle on the job. That's because these problems are invented for the sole purpose of testing some set of skills some company happens to value for some reason at some point in time. As a result, the premise of the problem often smacks as contrived, the requirements can seem arbitrary, and the scope tends to be awkward in order to fit within the artificial time constraints.
For example, imagine being asked to create a word processor in a terminal with so few features that the end result would be completely useless to anyone who attempted to use it. Likewise, imagine implementing an oversimplified game nobody would ever want to play. Just the sheer pointlessness of problems like this can sometimes throw us for a loop in a way that a real-world problem with real meaning just wouldn’t.
Similarly, you’re often given problems that are so academic and abstract they can feel contrived even though they technically have real-world application. Here's an example from one of the most popular technical interview prep resources out there, Cracking the Coding Interview, by Gayle Laakmann McDowell:
Implement an algorithm to determine if a string has all unique characters. What if you can not use additional data structures?
Now, this might be a thing someone would want to do in some real-world context. The problem is that nobody mentioned that context when they presented the problem, so you have to just snap into the abstraction and move on. That can take some getting used to.
See, in the real world, problems have meaning. They are tackled in order to address actual business concerns and happen in the context of real world users with real world needs. And their scope is meaningfully nested within a coherent big picture of value creation. All of these things give them life that interview problems often just lack.
You may be a wizard at solving real problems, but totally flail on interview-style problems. I remember my first time in an interview. My mind protested for several minutes before I was even able to make sense of why the hell anyone would ask me to solve such a problem. But by that time, my chances of finishing the problem plummeted. The only way to avoid this is to expose yourself to a sufficient number of these problems so they become second-nature. They have a very specific style and structure that once you understand, will serve as the basis for quickly working through what is being asked in what is usually a contrived context.
3. Awkward coding environments
Have you ever started an email on a mobile device only to give up in frustration and pick back up on your laptop? Theoretically, as a writer of English, you should be able to express yourself equally well so long as you can type words, right? Wrong. If you're accustomed to doing all of your long-form communicating on a full-size keyboard, you have a whole career of habituated muscle-memory that allows thoughts to flow without friction.
The same principle, obviously, applies to code. If you're accustomed to a specific environment, it's going to be hard to code in another one. Yet some interviews not only require different devices and IDEs, they make you write your code in a way that basically zero engineers every write code: with a marker on a whiteboard. Again, you may have mastery over the content of what you're coding, but you are definitely going to run into friction if you've never felt through a new environment, and it could throw you entirely off your game. You need to get to know new environments before taking the interview – which, again, is simply a matter of practice.
4. Thinking in a new language
The programming language you use most often will not necessarily be the one you get to use in interviews. Some interviews give a finite set of options for candidates to choose from, or no choice at all. I've even seen interviews where the company required candidates to use a language other than the ones they'd frequently use on the job to confirm they are polyglots. And even if you can choose any language, a lot of engineers who frequently code in C++ for example will interview exclusively in a more flexible and expressive language like Python.
public void load_data() throws IOException {
let url = URL(string: "...");
File file = new File("...")
std::*cout* << "This code is an abomination." << std::endl'
...
}
If there is any chance you will need to use a language other than the one you currently use every day, you need to practice heavily in that language before the interview. It doesn't matter if it's your favorite language that you used to use all the time. I've seen engineers who last used Python only a few months prior confuse it with their current language and forget how to do very basic things. If you don't get yourself in the mindset of the language you will use before the interview through significant practice, you're may to run into some serious hiccups.
5. Verbalizing technical concepts
Applying technical knowledge in code is not the same as being able to articulate it. Even though we use language to learn new technical concepts, they have all sorts of ways they finally sink-in to make up a working understanding to the point of being useful. As such, candidates who are legit experts in some topic or another find themselves tongue-tied in interviews (entirely aside from being nervous). It's because they've never had to find the words to comprehensively explain one topic or another (or at least it's been a very long time since they last did so). So, with limited time and judging eyes, they compulsively misuse technical vocabulary, present concepts in a disorganized manner, and appear way less knowledgeable than they may actually be.
The solution is to find another engineer you can practice speaking with. Attempt to explain technical concepts with complete, coherent narratives. Then give them permission to give feedback on whether it made sense and whether you covered all your bases.
6. Performing for an audience
Perhaps the single most trippy feature of technical interviews is trying to think, write code, and answer questions with one or more others scrutinizing your every move. At best, this can be distracting, and at worst it can be intensely anxiety provoking. Candidates who have little practice interviewing often cite this as one of the biggest factors that throw them off their game. Now while it may be hard to ever fully move past the awkwardness, practice does lessen the impact, at least subtly. You may feel anxious, but at least you're used to it somewhat. You may be a little distracted, but at least you're not also feeling that particular kind of distraction for the very first time. The more we do anything, the more it becomes expected and normal, even if it's unpleasant. So trying to do this as often as you can — either by recreating the interview environment with colleagues or taking real interviews when you don't necessarily need to — will slowly chip away at the adverse effects this factor has on your results.
Triplebyte helps engineers assess and showcase their technical skills and connects them with great opportunities. You can get started here.
Top comments (0)