This document assembles a general overview of technical interview questions. Obviously, this is neither canonical nor verbatim to what you'll get in an actual interview. However, interview questions do tend to be thematic: if you can recognize the underlying theme of a question, that can help you formulate a successful answer. As for the coding questions… well, sometimes there are no alternatives but to think on your feet!
The primary goal of a technical interview is to assess you, the candidate, as an intelligent and capable problem solver. Your existing knowledge is generally NOT the deciding factor. That said, a simple "I don't know (…yet!)" is almost always the correct answer for your areas of inexperience. Interviewers respect this self-recognition of what you don't know, and where you'd like to improve.
The worst thing you can do is try to fake an answer. Providing one bad answer opens the door for a series of related questions that probably won't go in your favor.
Interviewing is a lot like dating… this is the old, "do you actually find me attractive, or are you just looking for a hookup?" question. Be ready to explain WHY you identify with a prospective employer, and why you'd be interested (or excited!) to work with them.
Technology moves quickly, so they want to know how you keep pace. Be ready to list off the sites you read, the newsletters you subscribe to, and the communities you follow and/or participate in. Balance name-dropping with WHY you choose to follow these sources.
This question assesses you as an inspired, motivated, and hungry individual. They're looking for your personal drive and inherent curiosity. They want to know that you WANT to be great, versus just being good enough to do the job.
They're asking about your personal values, as in: what makes you tick? Are you looking for challenge, recognition, do-gooding, compensation… what? They generally want to assess your priorities for two reasons: 1. Do your values align with theirs? You should also assess this of them. 2. Given multiple offers, what would sway you into their camp?
This is generally the final question asked by an interview panel, and is your opportunity to turn the table and interview them. TAKE IT. Remember that interviews are two-sided assessments. Be ready with your own arsenal of questions that will inform you about how they work, and how they would fit into your own goals.
HOWEVER – remember that they're listening to your questions, and they're taking notes on what you're asking. Be prepared with poignant questions. The worst thing you can do here is have NO questions, or invent some lame fillers on the spot. The second worst thing you can do is focus on compensation and benefits… save that for an HR discussion after the technical interview.
This is the "team player" question. We all butt heads at times, so this is about seeing where and why you came to odds, and how you resolved the situation.
Hitting some dead-ends is inevitable, so they want to know where you've hit a wall in the past and how you handled the situation. Did you think on your feet and pivot your approach, or stagnate and give up?
This stale old Microsoft question embodies the theme behind problem solving questions: they want to understand your general approach to critical thinking and logical reasoning.
These are the old classic "run with it" questions. There ARE NO CORRECT ANSWERS. As an intelligent software engineer, it's your job to just run with directions that quantify the problem:
"Hmmm… Let's average the number of breeders per state & province, then multiply that by an estimated number of pup-bearing bitches per breeder, multiplied by the average litter size, and then the inception interval. Then we'll need to assume an average lifespan of 15 years per poodle, removing the deceased from the birthrate until we reach a rough population size. However, we should also anticipate the establishment of new breeders over time, thus adding a population growth rate…"
…infinite scrolling with a browser-based scrollbar? You'll commonly be presented with a technical problem that the interviewers have already encountered and solved within their own domain. Now they want to hear how you'd approach the problem. This is a fantastic question, because it's an opportunity for two-sided assessment: they learn about your thought process, and you learn about both their work and their thinking. You should be as (silently) critical of their solution to the problem as they are towards yours.
…a vending machine; a robot that waits tables; an elevator. Take a whiteboard marker and start drawing. These are deliberately large application concepts with many moving pieces. The interview panel isn't really looking for a working solution, but for your thought process while breaking down the problem. Vocalize everything that's going through your head, and try to capture as much as possible on the whiteboard.
…the Shazam music service. This has similar intent to the software application question, but is BIGGER. This is a full-stack question that requires thinking about the problem across multiple clients, servers, databases, networks, and third-party APIs all at once.
...a jQuery Deferred (Promise) object. This is testing the candidate's conceptual understanding of how a common library tool works under the hood (by breaking the tool down into plain code). Advice: ask if you can reference the tool's documentation, rather than going by memory on how the tool works.
When asked to complete this on a whiteboard, the interview panel is reviewing the candidate's attention to syntax outside of a text editor. These two factors together are HARD.
...if a string contains words from a list of dirty words. This is a very common style of coding question: the question can be applied to any programming language (Ruby, JavaScript, etc.), and is pretty straight forward for a candidate of any skill level to complete a basic implementation of. However, this question can also scale up to probe the candidate's knowledge of time complexity and Big-O, and challenge the candidate to solve the problem with faster and more efficient solutions, or with additional requirements.
...an implementation of the Underscore "debounce" method. This question assesses the candidate's code competency while also reviewing their comfort within a test suite. This is a very fair way of presenting code challenges, given that the candidate has a defined set of requirements and a clear measure of completion when all tests pass.
This is open forum for the candidate to select a project on their GitHub account, and to talk about what's in it. This is a GREAT question, and puts the candidate in the pilot's seat to either fly high or crash hard. The thing to know:
Even the best code makes ABSOLUTELY NO SENSE to a fresh pair of eyes at a quick glance (which is all you have time for).
Given that universal truth, an excellent strategy here is to –ironically– spend as little time looking at code as possible. Use your people skills; they're a lot more engaging. Lead a discussion that:
- Identifies a technical problem that you needed to solve.
- Presents your considerations for approaching the problem.
- Describes your solution for solving the problem.
After leading this discussion, quickly show some code that supports your discussion points. The unfamiliar code still won't mean much to the interview panel, so you'll mostly just be showing them your syntax and commenting styles. If those look good, then you've probably passed with flying colors.
…simple statistics service. This offers a superb one-on-one assessment opportunity for both interview parties. The interviewer gets to watch the interviewee work first hand, while the interviewee gets a tangible feel for the team they're applying to work with. Team personality fits tend to be obviated, and the interviewee tends to feel more collaborative than "on the spot" during the interview.
...a simple document layout based on a wireframe. Front-end candidates will frequently need to demonstrate some HTML/CSS layout skills. However, content formatting and layout strategies are incredibly subjective (ie: choice of tags, content order, positioning methods, etc.), therefore replication of the wireframe alone is not very meaningful. Be prepared to DEFEND your choices, as in… "these tags have better browser support," or "this positioning method lends itself to responsive flow," etc.
Interview questions are generally designed to span between two major "water marks" that will measure the depth and range of a candidate's knowledge:
- Low-water mark: establishes "Okay, this guy knows at least THIS much."
- High-water mark: establishes "Holy crap, this guy knows THAT much?!"
Rails is constantly evolving. This question provides a low-water mark for assessing a candidate's basic grasp on the current landscape.
This is a clever two-part question: first rate yourself, then identify what differentiates your skill level from the level below you. This gives the interview panel your own self-perception, as well as a benchmark to compare your scale against theirs.
This question probes a candidate's exposure within the Ruby universe, and asks how they sift through the noise of mediocre software that's available.
Application security measures are a virtually limitless topic, therefore this question allows candidates to set their own high-water mark based on their experience level.
This is another high-water mark question where candidates may discern the complexities of data storage. Experience will quickly speak for itself.
Given that jQuery has a robust DSL (domain-specific language), it's remarkable how often a candidate "knows jQuery," yet doesn't really know anything about plain JavaScript. This is a low-water mark for screening jQuery-only experience.
This is another low-water mark for testing a candidate's exposure to basic JavaScript concepts. Other variations tend to ask what scope and/or closure is.
These questions are painfully silly, yet painfully common. You're given a jumbled mess of contrived JavaScript and asked to follow its flow to the outcome. For example:
/* What gets printed into the console? */
var x = 6;
var y = 4;
function a(b) { return y + b; }
x = 2;
y = 5;
var fn = a(x);
function a(b) {
return function(c) {
return y + b + c;
};
}
x = y = 3;
console.log(fn(5));
This is an advanced scoping question that does an all-around better job of probing a candidate's understanding of how scope, closure, and encapsulated data works than silly flow problems.
The underlying question here assesses the candidate's awareness and understanding of how a garbage collector (GC) works. In this case, the candidate is tasked with identifying bad code patterns that thwart the GC. This is a high-water mark question where experience will quickly speak for itself.
This is another high-water mark question where candidates may discern the complexities of asynchronous behavior. Experience will quickly speak for itself.
Everyone wants it, and apparently there are not enough engineers who really understand responsive layout to go around. This is definitely a current vogue low-water mark.
This question probes a candidate for knowledge of how front-end layout works under the hood. This is an intermediate question, but would still generally be considered a low-water mark.
This is an advanced DOM efficiency and rendering performance question. This level of knowledge is particularly important to bigger shops who are building mature software products with large audiences.
…grid columns; clearfix; vertical alignment; dynamic content order. These are generally perceived as CSS high-water mark questions: impress us with how much of the spec you've read and how many tricks you know. However, tricks and specs don't always equate to mature development experience (it's easy to make stuff work in just Webkit!).
…cross-browser compatibility; accessibility; mobile performance; SEO; analytics. These are the true high-water marks for front-end engineers: tell us what you know, and how many audiences you have experience with making it work for.
While interviewers occupy the perceived seat of power during an interview, this does not necessarily mean they're an infallible tower of knowledge. Poorly conceived and/or surprisingly inept interview questions are actually fairly common, and should serve as a red flag to YOU, the interviewee.
The most useless question I've ever been asked during a technical interview involved fitting a variable-sized image into a variable-sized content frame (basically, the CSS "background-size:cover" implementation):
"Write a function that accepts a frame width, frame height, and image aspect ratio; and then returns a rectangle for the image that is scaled and centered to fit within the frame."
This question was useless for several reasons: first, it was primarily a math problem. I Googled the complete formula in 30 seconds after the interview, which pretty much invalidated the 30 minutes of engineering time spent during the interview. Second, the problem was given without a test suite to validate expectations against. While my implementation worked correctly for landscape and square aspect ratios, it proved faulty for portrait ratios. I hadn't hand-tested enough aspect ratios during the 30 minute session to detect this error. The exercise was received as a failure, although the question had explored very little real technical prowess.
Afterward, I withdrew from their interview process.
Remember that ALL interviews are two-way assessments. Make sure the interviewers impress YOU as well. You can afford to be selective.