Click here to Skip to main content
15,848,157 members

Why I Despise the Interview Coding Test

Rate me:
Please Sign up or sign in to vote.
4.70/5 (8 votes)
11 Feb 2013CPOL5 min read 28K   5   6
I truly believe programing tests during an interview are pointless.

I admit, that this is traditionally a security blog, however I am going to digress for a post. I truly hate the concept of a coding test during an interview. I hate them as both an interviewer and an interviewee. Joel Spolsky & Jeff Atwood would probably disagree with me, however I truly believe programing tests during an interview are pointless. I have come to this conclusion after 8 years in the software industry both, taking tests as well as giving them. The reasons that I believe these tests are pointless are: The tests don’t really prove anything; coding tests don’t simulate a real work environment; they’re a waste of time.

1. Prove Nothing

I’ve often heard the arguments that you wouldn’t hire a contractor, any other contractor without previously seeing their work. Or you need to see and evaluate one’s style to see if the candidate is a good fit, you want to ensure that the candidate can actually code.

The test during an actual interview does nothing to really prove or establish any of these three points. Often times, during the interview, the candidate gets X amount of time to accomplish a specific task. Software today has become so diverse with so many different industries writing many types of software across many different technologies that the candidate may not be versed in all the specific technologies required to accomplish their task in the given time frame.

Does that mean that they’re a bad programmer? Of course not. Does it mean they’re incapable of working for your company? Of course not.

When you truly consider the role of a developer or engineer within your organization, writing the code is actually the easy part and the end solution to the problem. This raises the question are you hiring an engineer to solve problems or are you hiring an engineer to crank out code. The obvious answer should be the former. Therefore the way an engineer actually writes code is less relevant then how they solve the problem especially in today’s industry where every company has its own standards, practices and format.

If the candidate has been employed for longer than an year, at a previous software/technology company and provided that they’re not a fresh graduate, it stands to reason that they can actually write code. So too, isn’t this why you check their references and follow up with their past.

2. Doesn’t Model Your Environment

In what organization does a member of your development team actually only have X amount of time to solve a problem and write some actual code. So why are you asking a candidate to perform under pressure, already being stressed out from the interview, to write code and be evaluated in a short amount of time? Do you really think that you’re getting the best possible result from that candidate, now if one doesn’t handle interview situations well, you might pass them over because they didn’t perform on their test well enough yet, you might hire a weaker engineer, because they are capable of performing in that 1 situation better.

In the environment, the engineer has a chance to think through the problem, clearly design an excellent solution and lastly write the code which will illustrate the situation as needed. So why not design a test and circumstances that mirror an actual environment and allow the candidate to actual produce in the best situation.

3. Waste of Time

Often, the candidate is going to write bad code. Often time, the developer who shows up isn’t mentally prepared to write the code. Now you as an interviewing team have to evaluate bad code that may or may not actually solve the problem that your test was designed to evaluate.

Often time, these tests are designed to be so short, such that the candidate can complete it within the given time frame. The test is pointless, without meaning, often times, it doesn’t expose the candidate to real problems & technologies that your organization actually works with. Nor does it actually allow the organization a chance to evaluate a candidate’s architectural abilities.

A Solution

Rather than springing a coding test on the candidate during the interview, why not e-mail the candidate the test a few days before as part of the screening process or the night before. This approach will give the candidate the time required to think about the problem, plan out a solution, and actually implement the feature. They may or may not actually finish it early and therefore have time to refine and refactor it into an even better solution on your behalf.

Once the candidate has sent the test back, the interviewing team can perform a code review analyze the test and prepare a standard set of questions to ask the candidate for the in person interview. Or the team can perform the code review during the interview itself. It will quickly become obvious through a discussion whether the candidate implemented the test themselves or if they hired someone else to implement the test for them. This approach would actually allow the time for a more detailed test which would test architecture abilities as well as, coding abilities, giving a much more complete and reliable solution.

Given the onset of DevExpress for Visual Studio, or other free IDEs these days, there’s really no excuse why a potential candidate could not grab an IDE, if they don’t already have one installed, which is telling in and of itself. There’s really no reason why a candidate cannot pick up an IDE and actually write some code at home in the evening before the test.

What am I advocating for? Scrapping the test during the interview and allowing for a more detailed thorough take home test that models your work environment and exposes the candidate to the technologies that your organization actually uses.


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Written By
Canada Canada
I am a Sr Engineer for a major security firm; I have been developing software professionally for 8 years now; I've worked for start ups, small companies, large companies, myself, education. Currently the company I work for has 7,000+ employees worldwide. I am responsible for our platform security, I write code, implement features, educate other engineers about security, I perform security reviews, threat modeling, continue to educate myself on the latest software. By night, I actively work to educate other developers about security and security issues. I also founded a local chapter of OWASP which I organize and run.

I cut my teeth developing in C++ and it's still where my heart is with development, lately I've been writing a lot of C# code & some java, but I do have a project or two coming out in C++ /DiectX 11 whenever I get the time.

When I am not developing code I am spending my time with my wife and daughter or I am lost deep in the woods some where on a camping trip with friends. If you can't find me with a GPS and a SPOT device then chances are I am on the Rugby pitch playing Rugby and having a great time doing so.

You can find more about me and My thoughts on security

Comments and Discussions

Questioninteresting post Pin
Ted Chippington10-Sep-16 13:17
Ted Chippington10-Sep-16 13:17 
SuggestionGreat idea, but needs to account for "cheaters" Pin
emartinho11-Feb-13 8:14
emartinho11-Feb-13 8:14 
GeneralRe: Great idea, but needs to account for "cheaters" Pin
CdnSecurityEngineer11-Feb-13 8:49
professionalCdnSecurityEngineer11-Feb-13 8:49 
GeneralRe: Great idea, but needs to account for "cheaters" Pin
emartinho12-Feb-13 8:06
emartinho12-Feb-13 8:06 
GeneralRe: Great idea, but needs to account for "cheaters" Pin
Chad3F20-Feb-13 18:12
Chad3F20-Feb-13 18:12 
GeneralRe: Great idea, but needs to account for "cheaters" Pin
mariozivic3-Oct-14 1:47
mariozivic3-Oct-14 1:47 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.