Column

Running a Technical Interview as a Developer

Illustrated by Shiho Pate

You’re working as a developer for a small-to-medium company, and it’s time to expand the team. Your boss says they want you to attend the interview to assess the technical abilities of the candidates.

The instinct is to whip up a difficult quiz to really grill their technical knowledge, full of minutia and “gotcha” questions. Or to emulate Big Tech like Google or Apple, and present an esoteric puzzle to psychologically judge the candidate.

Those instincts are wrong, and you should not follow them.

A tech interview’s primary purpose is to ensure that the candidate can actually do the things they put on their resume. More so, it is to give you confidence that they can use the tools of the trade, whatever flavor that may be for your company. Can they navigate Visual Studio? Do they know how to edit in VIM? What do they do when you ask them to write and execute a SQL query?

This is asking a carpenter to nail two pieces of wood together. Can they pick a hammer out of the toolbox? Do they know the difference between a screw and a nail? Do they make sure the boards are square and steady before hammering, or do they just lean it against their knee and whack?

An effective technical test should put the candidate in a situation as close to your company’s working environment as possible. There should be as little cruft as possible, to keep any technical hurdles from becoming confounding variables.

From experience: take a .Net shop that makes ecommerce products. There’s the standard .Net stack of Visual Studio, SQL Management Studio, IIS, and whatever modern browser is on hand. To see a candidate work with that “toolbox”, there is a bespoke, single webpage project. This page contains the skeleton of the task to be tested. It is pre-loaded with functions to do common tasks that don’t expect someone to create from scratch, such as connecting to the database to run a stored procedure. The interview laptop had Visual Studio open to that page, an instance of SQL Management with the stored procedures already open, and a clean copy of Chrome with a tab open to the localhost. It’s everything a developer would need to sit down and start the task, just as they would if they were working.

The test is as simple as possible. This isn’t a “Advanced AI Algorithms 401” exam. Back to the carpenter example: they aren’t building a house; just demonstrating that they can use a hammer. This sounds like a very low bar, but a shockingly large number of candidates will stumble.

The test is as simple as “get some input, process it, show some output”. The exact details will vary depending on the development work being done, be that an HTML form, a desktop app, microcircuit logic. It should be something that you, as the test creator, could complete in 5 minutes, and something any of your co-workers could do in under 15 minutes.

Again, a personal example: there is a .Net web page. On it is a Repeater. There is a function that calls a stored procedure to get “All Things”, bind it to the repeater as a navigation menu. The text of each navigation item is hard-coded to “Thing”. There is also a function that takes a Thing ID as input, runs a stored procedure, and gets a detailed record of a single “Thing”. Clicking any of the navigation buttons does a POST with the appropriate Thing ID and runs the “Get Thing” function. Everything is in place, but there is no input mechanism, or output UI yet.

The candidate is given the details of the task. First make the navigation menu say the actual name of the Things (which are in the dataset that makes the menu). Based on the user’s requested quantity, display if a specific Thing is in stock or not. Once a Thing is selected in the navigation menu, display that Thing’s details. Get a numeric “quantity” value from the user. One of the provided function takes Thing ID and quantity, and returns a database record that says if the requested quantity is Available, Unavailable or Will Be Available On {0:yyyy-mm-dd}. Display the correct information from that record.

A bonus task: do validation on the textbox to only allow positive integers. As an extra bonus, there is a small bug in the stock calculation, but we don’t know what it is. Just one of our clients said “sometimes it doesn’t work”. (There is a small off-by-one error intentionally put in the code; where “next available date” uses > which should be >= ).

All the instructions/specs are given orally, and also on a single-sided piece of paper for reference. The candidate is allowed to use any Internet resource they need, just like one would in real life. They may ask any questions, just like they could ask a co-worker in real life. Although there’s no hard time-limit, you will know in less than half-an-hour if they pass or not. There is no expectation for them to 100% complete the task; this is a demonstration of skill, not a job.

With that, sit back and observe. It’s ok to pay half attention to Twitter, and half attention to the candidate and their screen (at my company, the screen duplicated via projector). They don’t need someone staring over their shoulder at every moment.

A well designed test like this will almost instantly let you know if the candidate will fail, or if there's hope for them passing. What do they do first? Do they review the existing code to familiarize & orientate themselves? Do they go to the database to get the column names they’ll need to access? Can they easily navigate through the IDE?

The first impression should be based on “What would you expect a junior developer to do if this was a real-world task assigned to them”? You are getting a glimpse of the candidate’s thought process and problem solving skills. If they are struggling to even understand or start the task, or how to even pick up the tools, there's little chance that they will be successful in anything beyond that.

Beyond what they do, observe how they do it. Example: are they familiar with keyboard shortcuts? A canary-in-the-coalmine is how they do copy/paste. Do they quickly CTRL-C, CTRL-V (in Windows, natch), or slowly click Edit menu to select copy, then again to paste? It can demonstrate a lack of second-nature muscle memory, which can highlight an inconsistence between experience claimed on a resume, and actual ability. To be cliché: are they working hard, or are they working smart?

What happens when they run into something they don’t know? Everyone has those “wait,what’s the syntax for a Do...Until loop again” type moments. What kind of internet search do they perform? Does it seem that they at least know what they don’t know? When they arrive at a webpage with a solution (hello StackOverflow), are they able to quickly parse out the answer and apply it?

Most importantly, at any point do they ask you questions? They’re working in an unfamiliar environment, doing a task that was relayed to them in one dump. There will almost certainly be some point that needs clarifying. Or they may ask questions to confirm they are on the right path to a solution (ie: “for the navigation menu, then name is in the column THING_NAME, right?”). A candidate who DOESN’T ask any questions is a red flag. If they aren’t willing or able to ask for help from knowledgeable co-workers, how will they ever integrate into the team? If they never check-in or talk through solutions, how often and for how long will they go off-track on an actual task? If they get stuck on something, are they the type who will spend hours wheel-spinning, rather than two minutes asking a simple question?

Most importantly, once they have an answer, do they apply it, and retain that knowledge? I don’t mind being asked any question, as long as the person learns from the answer.

By the time the candidate first starts writing code, you can be almost confident of your “hire or pass” opinion. Someone’s resume may claim 5+ years in .Net, but they’re struggling with variable declaration and don’t know the syntax of an If…Else statement. Or they don’t know how to create basic UI elements, like an input textbox. It’s much better to discover this now, rather than after they’ve been hired.

After fifteen or twenty minute, you should be 100% certain if they have “passed” the technical test or not. Pre-arrange with the lead interviewer to pop in around this time, ask how it’s going, and to pull you out of the room for a moment. Relay your thoughts and feelings about the candidate’s skills. Would you peg them as absolute beginner? Junior? Intermediate? Senior? Is their resume’s claims an accurate demonstration of their actual skills? Can you see them being successful in the sort of tasks your company expects to be done? How much of a learning curve do you think they’ll have to get up to speed with all the internal technology you use? The people who make hiring decisions will now have something to compare and contrast against impressions they got from the talking/personality portions of the interview. It will also let them know if the candidate’s skill level is in line with the sort of position and salary the company is offering.

Or is this candidate a hard “no” from you? Are they absolutely hopeless? Will they struggle with every task given to them? Are they unable to problem-solve? Are they unable to do basic things that they claim to be experts in on their resume? If the technical interview gave that impression, then at least it was a successful test.

Once that’s done, unless you need a bit more observation time, it’s safe to wrap up the test. Let the lead interviewer take over. Be courteous and thank the candidate for their time. Even if the candidate did great at the tech test, avoid phrases like “I look forward to working with you” or similar. The test’s findings are extremely valuable, but still a piece of the company’s overall decision-making process. You don’t want to set hiring expectations on behalf of your company.

That’s it. That’s the test. You have now eliminated a good 80% of candidates who would range from “not a good fit here” to “absolute disaster”. Or you’ve found someone you would be comfortable being your co-worker. Reset the test environment back to default so it is ready for the next time.

So if you’re tapped to assist in the hiring process in a technical capacity, you are now well prepared. You can provide accurate and useful information to the hiring process; something that can only be a benefit to the people making hiring decisions, and to everyone who would have to work with the candidate for months or years to come. You know how to provide a simple yet insightful test that allows a candidate to reveal their real-world working habits and technical skill, without relying on overly-complex or misleading puzzles and quizzes.

May your future co-workers be someone you don’t want to throw out a window.

Lorne Kates

author

Lorne Kates has been a full-time developer for over 10 years, with a focus on e-commerce websites. His experience with (ex) co-workers lead him to insisting on technical tests for future interviews. His writing also appears on TheDailyWTF.com.

Shiho Pate

illustrator

California based Illustrator Shiho Pate has been in the games industry for 10+ years. Now she is shifting her focus on editorial and children's book Illustrations. For more information please visit www.shihopate.com and follow her on twitter and instagram @shihopate