Coding tests are a fact of life when you interview for a developer job. They’ve been written about plenty, and the conventional wisdom is they’re very useful. For example, the venerable “Joel on Software” wrote about them in his “Guerrilla Guide to Interviewing,” and Jeff Atwood wrote about them in “Getting the Interview Phone Screen Right.”
Well, coding tests make sense for very junior job openings, where you’re looking for just a “coder”. Or, if the candidate has zero prior work experience. Otherwise, they’re worthless.
Here’s the typical coding test
The candidate…
- Visits the company for a day of interviewing, with each interview being 45–60 minutes. At least one of the interviews has a coding test.
- Is asked to code a simple problem. (E.g., “reverse a string”)
- Is asked to code on a whiteboard, without any assistance.
- Does the test while the interviewer remains in the room, watching.
- Has their answer reviewed/judged by the interviewer. Sometimes others are brought in to review the answer.
All firefighters must be able to roast a marshmallow
Does any of this remotely resemble how you develop code in your company? I’ll bet you don’t code standing up at a whiteboard with someone watching the clock, without any tools. So why do you think it’s a good predictor of anything?
Virtually everything about a coding test is wrong.
The social environment is all wrong
A normal job candidate is already stressed out. Coding tests ratchet up the stress by at least an order of magnitude.
The interview slot is, say, 45 minutes long, and he knows the clock is ticking. Most interviewers say something reassuring, like, “It’s not important to get the right answer. I’m more interested in how you approach the problem.” No candidate believes this. Nor should they, because a candidate with the “right” answer will be perceived as better than one without, all other things being equal.
The interviewer usually remains in the room, watching him as he draws chicken-scratch on the board, chases dead ends, etc. I know I do my best work when someone’s watching me, and waiting for me to finish. How about you?
It’s true that a standard interview’s social environment isn’t identical to a normal work environment. But the intersection between this and a normal work environment is ø.
The development environment is all wrong
When I design or code something, I’m at my computer.
With Python, it’s easy to dive into the interpreter and experiment. But no matter what your coding language is, I’m sure you also sometimes use small code experiments as part of your development process.
I can search technical sites, news groups, or forums if I need to. I can even e-mail or IM someone with a question. When I write code, I use a language-sensitive editor, which highlights syntax errors, displays library documentation, etc.
I have a copy of Python Essential Reference at my side. Maybe I also have CSS Pocket Reference or Python Cookbook. No matter what your language is, I’m sure you also rely on some texts when you code.
None of this exists in a coding test. The intersection between a coding test and a normal programming environment is ø.
You’re testing for the wrong thing
The tests must be simple because time is limited. Hence, the tests are “reverse a string,” “find the largest value in an array,” etc. This is simplicity to the point of triviality, and it’s not testing what you think it is.
The candidate is always obsessed with demonstrating that he knows the language’s syntax. (Most interviewers reassure candidates on this point, and no candidate believes them.) This means a large amount of candidate energy is going into syntax checking, instead of solution crafting.
There are aptitudes and skills that coding tests don’t even touch. You won’t see how the candidate documents their code. You won’t see how the candidate approaches unit tests. You won’t see how well the candidate follows check-in rules. Etc.
It can be insulting
There’s nothing like having a great work history, impeccable references, and a resume with tons of relevant experience — and then being asked to write a function that capitalizes the first letter of every word in a string.
Remember, I’m writing here about someone other than a totally green-behind-the-ears candidate.
It can be sadistic
See the “social environment” section.
A good coding test would take too long
In a good coding test, you’d give the candidate a table, a computer with Internet access, some reference texts, a pad of paper, and three or four hours to work on a problem. And then you’d spend at least 15 minutes to review their solution, given the likely complexity of a programming problem that needed three or four hours to solve.
This would allow for a far more realistic appraisal of the candidate’s skills. It wouldn’t be perfect, but it would have a few things in common with the real world, of which the standard coding tests do not.
The problem is that nobody has the time for this sort of test.
Back to the future
Most (nearly all?) other disciplines don’t do their equivalent of a coding test. If you were interviewing…
- A CFO, you wouldn’t ask her to do a math problem on the whiteboard
- A firefighter, you wouldn’t set the wastebasket on fire and ask her to pour water on it
- A hardware engineer, you wouldn’t ask her to solder a chip to a board
- An artist, you wouldn’t ask her to draw a picture on the whiteboard
They instead rely upon the applicant’s references, work history, and answers to questions.
You’re probably trying to discover this with a coding test:
- How the candidate thinks approaches problem-solving
- The accuracy of the candidate’s work history
- The accuracy of the candidate’s representations of language familiarity
- The candidate’s use of good development practices
In which case…
You can uncover all this by asking good interview questions, and doing good reference checks. Given how most companies do both of these, it’s really (unfortunately) a radical suggestion.
Good interview questions should be easy, but many interviewers ask terrible questions. I once interviewed for a VP Engineering position, and was asked if I knew Moore’s Law. I nearly fell off my chair.
Most companies don’t do good reference checks, and many don’t do them at all. A reference gives you a window into the applicant’s performance in a real-world situations, which is orders of magnitude better than a coding test. And you can do a reference check using your own contacts, as long as they’re not at the candidate’s current employer. I’ll take these over a coding test any day of the week.
Updated on 2013-06-01: I’ve never been happy with this ending. It’s lame. I was trying to argue for something, but it didn’t come out right and I didn’t write what I wanted to say. I’ll try again, someday.
Seek Nuance 
Now I’m curious. What inspired this post?
i completely agree with this post….i recently had to conduct two interviews while filling a coder position. i know the guys were software engineers, so asking them to code something would simply be stupid. i was mostly interested in finding out how easily and likely is it for these guys to figure stuff creatively. also to know if they are in the know of what’s going on in the interweb in terms of design, best practices, trends etc etc when it comes to programming. my system might be slightly flawed, but i need it’s turned out good so far.
any other things i could ask would be highly appreciated
Joe: The impetus was the “Coding Horror” post about interview phone screens. In it, Jeff Atwood lauds another blogger’s phone screen advice, which included giving a coding test over the phone. You read that right – a coding test over the phone.
I had an immediate visceral disagreement with this. I considered how my previous companies handled interview loops. The result being what you read here. 🙂
Jonathan: Thanks for writing. Just so I’m clear, I think coding tests make sense if you’re hiring someone with no prior work experience (e.g., someone fresh out of college, or who’s switching careers), or if you’re hiring into a very junior coding position. I.e., one which is literally only coding.
If they already have work experience, I’m with you: Do a proper background check and ask good interview questions. If you can’t figure them out in 45 minutes to an hour of probing questions plus good reference checking, don’t hire them.
This is perhaps a topic for another post, but I like to ask a mixture of practical and open-ended questions. I’m not a fan of the Microsoft-popularized “intelligence” questions, like, “If your car was full of gas and weighed 3000 lbs., and you drove onto a bridge with a weight limit of 3000 lbs. in its center, would it collapse?”
> Most interviewers say something reassuring, like, “It’s not important to get the right answer. I’m more interested in how you approach the problem.” No candidate believes this.
Well, that is what I am looking for when I ask coding questions in an interview.
> Nor should they, because a candidate with the “right” answer will be perceived as better than one without, all other things being equal.
If a candidate gets the right answer I would assume that s/he has encountered that question before, so I would ask another.
I do agree that asking a question on reversing a string is useless, but asking someone to write something that shows you know how to manipulate bits for a device driver writer position is reasonable. Also asking an interviewee to evaluate a recursive Fibonacci function is valid.
These are valid things to do on the job. They are pretty stupid in an interview. My guess is you’ve missed out on some seriously qualified and high quality candidates asking stupid questions like this.
@bryan
wouldn’t it just be easier for him/her to show you a project they’ve worked on?
I’ve heard that some companies do not allow interviewers to request code from interviees(for legal reasons), but for exacmple’s sake, lets say you can.
some might argue that they worked in a team an didn’t do all the coding….but then again you want them to work well in a team so it’s not that bad.
i just think that there should be a better way to figure out if the person is the right one for the job without having to code on a white board.
Bryan: We’ll have to agree to disagree. 🙂
As I argued in this post, I agree with a coding test if you’re interviewing a green, no-prior-work-experience individual for a device driver position. But it’s a waste of time if she has 10 years’ development experience writing device drivers for 3Com and Qualcomm. Asking her a couple of probing questions, and doing good reference checks, will tell you 1e+06 more than making her write bit-twiddling code in an artificial environment.
For senior folks, I think whiteboard tests are a good springboard to a broader discussion about design ideas. I.e. “Why did you do?” But to expect anyone fairly senior to write significant code on the board in 15 minutes is crazy.
Plus, Eclipse does 3/4 of my work anymore, and Firefox+AltaVista does the other 1/4.
I once had an interview where the guy had a printed program he had people analyze. Instead, he asked me to write it from scratch on the whiteboard. When I did just that, he said my answer was “prepared”. Huh whaaaaa? I smiled and asked him, “Come on, seriously, how many people get that one right?”
One more thought — about your “sadistic” comment.
One critical thing I look for as an interviewee is “Can I TALK to these people?”
If I put code on the whiteboard and they point out all the semi-colons I missed, or start laughing and tearing it down, I usually just coast through the rest of the interview, thankful that I am about to dodge yet another bullet.
Rob: I agree that you would have indeed dodged a bullet. You seem to have a good view of the work-life balance. 🙂 But would you agree that most individuals wouldn’t take it as well as you?
Perhaps such companies deserve the staff they hire. But I see the problem as so many companies using them that they’re impossible to avoid. And the companies shouldn’t use them in the first place.
Ya; I agree white board coding is a waste of interiew time. My only exception is that if it’s done very, very quickly, and used as a lead-in to a broader conversation.
But in general, I always assume that the people interviewing me are very good at programming, and very, very, very bad at interviewing.
The ubitquity of whiteboard coding is good evidence of that.
So I always try to move the interview along, by a) talking a lot about my strengths, b) just admitting “I don’t know” or “I haven’t done much of that” about my weaknesses and getting back to my strengths, c) throwing something on the table, like some diagrams or sample code, to distract them.
If it’s an argumentative crew, I challenge them on some subjective technical point & run the clock down. I know if I’ve won if they say, “Darn, we’re out of time, and I had a whiteboard problem I wanted you to do.”
😉
I noticed nobody mentioned that another big downside to a whiteboard test is that most of us with years and years of experience haven’t written anything by hand since we were in grade school. Having typed just about every word I’ve written in the past 20 years, my handwriting is barely legible and writing out .net code with the nice long framework call names on a whiteboard makes me feel like someone put me in slow motion. They may give you an hour to solve the problem but in reality one only gets about 10 minutes after you subtract the time it takes to physically chicken scratch it out and periodically erase scribbles only you can read.
@Jason: Yep, I agree. My handwriting is sometimes so bad that I have trouble reading it. The entire whiteboard coding test environment is a Fail in every respect.
I so agree with this post! One of my favorite interview questions, as an interviewer, is to share some stressful situation/issue, and see how this interviewee woudl help me with it. Then, we go to the whiteboard together and collaborate. Then, I see if they can contribute on a discussion level, on a problem-solving level, and if this kind of work is interesting to them. I shy from “getting work for free”- because when I’m on the other side, I feel sometimes that interviewers are getting work done for free- but I let the interviewee know that these are the kind of challenges we face in this environment. I also think that taking the spotlight off of them helps, and yet can illuminate areas of their experience for me to judge.
I’ve been in the industry for many years, moved up to system engineer and architect, and done almost no coding even though at my peak I produced over 1000 LOC per day doing (really) rocket science. I’ve since written compilers and debuggers, am great in system design, driver porting and debugging and code inspection. My skills writing on the board or problem solving away from a console, for want of a better word — suck. I have anxiety attacks in interviews requiring white board coding. Hence, I’ve never gotten a job where that was part of the interview, but been an MVP employee wherever it wasn’t and have an otherwise successful career. I don’t know how educators or psychologists view such screening, but wonder how often they throw out the wheat with the chaff? How is the quality of both the interviewer and the problems decided? Is this really a good way to bring in talent and does it really result in better products and fewer defects? Solid industry data or analysis may be necessary before HR guidelines might either discourage such tests or define ground-rules so they aren’t too subjective and are conducted with transparency and peer approval.
Nice post, it is not any different here in the eurozone. I’ve been on both sides, as interviewer and as candidate. As candidate I was asked to write some perl code. I did, and pointed out standard unix tools could do the same thing far more efficiently. This thinking out of the box was not appreciated. It was no surprise the company did not succeed in the next years.
As interviewer I like the candidate to bring in some project code, complete or not and let him explain why he/she has taken certain decisions. This, together with good non-standard questions gives some insight in coding practice. In the end, most of the coding tasks in my industry require flexibility, enthousiasm, OOTB thinking and as last programming skills.
Your standards sound completely reasonable. Good luck working in today’s software marketplace. 🙂
I face a whiteboard interview tomorrow.
Frankly, I can already feel my brain starting to lockup. I wonder how the interviewer would respond to my asking them to complete a whiteboard coding question so that I can evaluate whether they are worth working for? After all, I’ve been doing this now for over 25 years! I’ve probably forgotten more than some can ever hope to know (but I dare not tell the interviewer that!).
I had a whiteboard interview a few days ago that I totally blew. Really basic stuff – normalize a string. (remove extra whitespace, capitalize first letter, etc.) The code I wrote on the board was full of stupid mistakes which, of course, all jumped out at me the moment they left the room to get the next interviewer. I wrote a proper version in my iPad Notes app in 5 minutes while I was sitting there, but they were done with me.
I now have a large whiteboard in my bedroom which I use to practice all the most common whiteboard problems in each of the languages which I list on my resume. I’ll be a shoe-in for the next shop looking to hire a senior fizzbuzz engineer.
I don’t think these whiteboard interviews are helpful. For instance, if someone can write out strstr the optimal way, it just means they’ve seen the algorithm before and are writing it out. If they don’t know the optimal algorithm they’re not going to have figured out right there on the spot…especially under all that stress and pressure.
Besides, whether you like it or not very little program out there is anything like finding a string in a string or sorting an array. All that stuff has been done already.
Yeah, I think it’s a stupid way to figure out if someone can program and Joel has perpetuated the problem. I wish they’d stop, because I hate doing them.
I personally think it’s time that software engineers start refusing to jump through these hoops and I for one intend to do just that. It is not the buyers market that these whiteboarding idiots seem to think it is–there are companies out there which are more reasonable in nature. For the record, I do not mind writing code. In fact, I love it and have written thousands upon thousands of lines of it up to this point in my career (11 years worth) but whiteboarding is like asking a sniper to show what he can do with a bb gun.
Correction: it’s more like a slingshot or even just a stone! A bb gun would at least be analogous to an 80286-era PC! Also completely I agree with all of your other points — especially the ones regarding the lack of respect too often shown by interviewers not even bothering to read resumes or check references. It is rather insulting.
When I interview people I give them a coding problem. But they work on paper, not a whiteboard. A few of the candidates ask to type, instead. After all, the interview takes place right next to a computer. I allow this, also.
Usually the idea is to give a simple problem to see if they can program at all, in any language. About 10-20% of candidates can pass a phone screen, have a resume with all kinds of programming, and do fine on all the other interviews. But after I ask them to write a few lines of code, suddenly they confess that they cannot program at all, in any language. This has been most often true for candidates with experience. Most new grads remember something, at least.
I keep the copies of the code that they write. I’ve looked at it years later and have found it to be an accurate prediction of coding performance, at least in the people that were hired.
I also invite candidates to bring code samples.
The reality is that a real life taxing coding test is impossible.
The reasoning behind the whiteboard test is to have the candidate provide a simple solution to a simple problem but outside of their comfort zone.
The test should not ask something that requires a complex algorithm or one where the candidate even feels they need to come up with a complex algorithm.
The review of the test should not focus on syntax errors, although absolutly the candidate should feel the pressure of making something that would compile. After all, it is what they do.
A candidate that is comfortable with coding, can picture code in their head before putting fingers to keyboard. They will solve any whiteboard style question immediately and have absolutely no need for cut n paste or intelisense or any other “tool”.
The whiteboard test will indicate if a candidate is comfortable at coding.
Other tests, including more complex code on a PC as well as discussing coding techniques and design patterns will give you more information about the ingenuity of the candidate.
No one test should ever be deemed suitable alone in determining a candidates ability.
I have seen candidates that can talk the hind legs off a donkey about the theory of OO. Yet were almost completely computer illiterate!
You might be after a theorist and in that instance it would be the perfect candidate. You might be after an innovator, or a code monkey.
I totally agree with the OP on virtually all points as well. Whiteboard tests and various “coding” tests are a complete waste of time with the exception of a rare few. Probably the biggest problem to such tests are the stress factors (people watching, limited time, etc…) and the fact that any coding test will be a trivial problem which is not indicative of real world problem solving.
First and foremost, almost everyone in the world relies heavily on a multitude of various tools (whether Googling, reading reference texts/tablet books, social networking, trial and error tests, etc…) to solve real world problems. This goes not just for coding problems but almost any problem you can think of today. What coding tests are really trying to ask and get the answer to is, “Is this person a good thinker and problem solver?”. Unfortunately due to the pressures of interview environments, cocky di*khe*d interviewers, time constraints, etc… few good coding tests exist.
Personally what I have done in the past, and what I prefer, is to get a decent idea of the candidates background in technology with a techie discussion such that I know they are thinking for themselves and, possibly, if anything, some test or assignment to solve a problem but it doesn’t necessarily even need to be a coding problem. Anyone who knows anything about computer science knows that being a good coder or software engineer has absolutely zero to do with knowing lots of languages intimately (or even 1 for that matter) and a lot more to do with how well you solve problems and your resourcefulness and ability to research effectively.
To reiterate John’s question from earlier, why do we entertain this junk and/or how did it ever get this way?
-Are mechanics given automobile teardown/build tests? No
-Are nurses given hospital equipment and drug administration tests? No
-Are accountants given math tests? No
-Are chemists given lab tests? No
I don’t quite understand the fascination with giving out these tests and wasting such an insane amount of time with interview after interview after interview in the recruiting process. You can gauge someone’s skill without going through 5 rounds of interviews and a coding test fairly accurately with just a 45 minute “techie” style interview + reference checks. And, oh the horror, if for some reason one falls through the cracks and can’t code (or learn really damn quick)? Wow, you are out what… a whole 1 or 2 weeks tops? Well guess what? You just saved yourself 4-8 weeks in the first place. And someone falling through the cracks like that would be exceedingly rare if you interviewed correctly (quick phone interview/screen 15-20 minutes, 2 follow up interviews max 30-45 min each plus ref checks).
I watched a show on Discovery or TLC recently about the rigorous recruiting style of Google and how one candidate was interviewed or called back in a total of 13 times before his offer letter. OMG! I would have seriously been like, “you know what guys… you can keep it.”. I mean come on. This fascination with testing candidates just baffles me.
I am so happy I was able read this. I feel much better. I am a programmer with over 15 years experience, C++ and .NET technologies with variable years in various skills. I have been told (either write or wrong) by many recruiters and employers I have a very good resume.
I honestly don’t mind technical questions as long as they are standard and honest. If an interviewer asks a technical question that has nothing to do with the work, that is just stupid. I had this happen to me. I recently interviewed with a fairly large sized company where for almost 45 minutes I was interviewed by two people, one very advanced technical question after another. During this interview they asked a very advanced and somewhat weird WPF question on assigning a style to a view model and then what what happen in the view if the style property on the view model changed. After I answered the question the best I could I asked ‘wow, I never even thought to do this. Do you do that a lot here?” and he said ‘actually no, we have never done that’. Not sure if he was joking or not.
After that, my whiteboard problem was ‘Write a program which takes all words in the English language and find the top five most popular 3 letter combinations’. I drew a complete blank. I got about as far as filtering for words less than 3 letters. My mind was so numb after the technical interview part I just wanted to leave and told them I cant do this. I felt so ashamed, humiliated and worthless after this interview. I’m sure there is a simple way to do this and I have yet to figure it out but frankly I have never had to do anything like this over my entire career so I figured even if I did go back to figure it out it would simply be a waste of my time. Needless to say I didnt get the job.
I had another interview that same afternoon that I was so scared I would fail as well for similar reasons. The pleasant surprise was they simply asked me questions about my work directly off my resume and dint really even throw me any curve-balls at all. No whiteboard problem or any extremely advanced questions. It was the difference between night and day. I left thinking that I had a pretty good shot at this job and even if I don’t get it at least I didn’t leave feeling like a worthless software developer.
This technical question/whiteboard problem is basically a ‘hazing’ process most programming candidates have to go through. I understand the merits of some of it and the companies trying to filter out unsuitable candidates but I also agree that many companies do seem to take pleasure in feeling superior to the candidate they are interviewing. I know not all interviewers are like this but I know for a fact at some interviews I have sensed this and I don’t think I was imaging it.
As much as we would like it to, I don’t think hard advanced technical questions and whiteboard interviewing style will ever go away. What can we do about it?
Whilst they’re not nice and it does not represent how you normally code etc, I think the coding tests you describe can be a perfectly legitimate part of the mix if you are hiring someone to cut code.
As someone who regularly has to try and figure out on (usually) very minimal information whether to hire someone, then barring significant contributions to open source, there aren’t any better ways to determine whether someone can cut code; tests, CV’s, college background, talk etc, may indicate someone who can cut code; someone who can do it under the artificial pressure of an interview definitely can.
Like everything it’s a trade off; you may well end up missing out on some good candidates. The upside is you can see their natural ability to cut code without the props of Google, IDE etc and how they handle themselves under pressure, all of which cab be very useful when trying to hire the best coders.
No, Herr Hume, not everything is a trade off. That’s a cop out. Some things just hurt rather than help. So obviously if you are comfortable with such equivocations, bully to you. The gatekeeper’s always have the last say anyway – it’s not like you are being hazed under the withering eyes of strangers in order to determine whether you can prove your bullshit assumptions.
In 20 years I’ve never passed the whiteboard test. I also can’t think of a time when I wasn’t hired after writing a sample app. I am terrible at white board tests. I don’t know if that makes me a bad coder. I’m not a social person which is why i am in computers in the first place.
From what I’ve been able to determine, there are three reasons for these whiteboard coding tests.
First, the latest management fad is to only hire “rockstars”. You know them, those people who nobody can work with because its “my way or the highway” and they leave within 5 years if not promoted to VP of engineering! The only way managment seems to know how to find them is by using the survival of the fittest technique. Hence “think on your feet coding”. Its a dumb idea to only focus on “rockstars” but we can thank Jack Welch for that.
Second, many managers have a primordial fear of making a bad decision that has to be explained away….ie. hiring someone who does not perform up to expectations. They therefore try to show “due dilligence” by coding tests is a defense mechanism.
Third, I think many people LOVE the sense of power. Nothing feels better to a 25 year old than to make a candidate who considerably older do a dog and pony show on the whiteboard.
Wow…interesting and long-lived thread!
I have no objections to whiteboard coding tests per se. However, like Michael, in a 20+ year tech career I can only recall one instance where an interview dominated by whiteboard coding tests led to a job offer. The one time it happened it was with a very early stage startup, self-funded by its founders, which clearly was not as experienced in conducting such interviews than most. OTOH when I get a chance to discuss my background and how I can best contribute to the company, I can probably get an offer at least 50% of the time after an onsite interview.
When it comes to the whiteboard coding tests, what I object to more is the fact that there is no feedback. I always feel that I do well–even very, very well–on the whiteboard coding tests so clearly there is a pretty big gap between how I feel I’m doing on these tests versus how the interviewers are evaluating my skills. Clearly I’m doing something very wrong in this kind of interview but with little feedback over the years I honestly don’t know what.
I do think Randall is correct that there is a certain power play aspect to this. In requiring whiteboard coding tests of someone who is overqualified to be tested in that way, the interviewer is clearly asserting power for the sake of asserting power. If an interviewer has that mindset, perhaps it is not surprising that one rarely gets an offer.
I’m always open to hearing about new opportunities, but I have a good job already. I’ve found that I need to be very clear and firm with prospective new employers that if they want to put me through the whiteboard coding test process, the position is too junior for me to be interested. I would, for example, love to work at Google if it were the right job–but I had to recently refuse an opportunity to interview at Google when it became clear they just intended to put me through their usual software engineer testing process.
As a long-time developer (2nd and 3rd gen mainframe, vm, pc, web) suffering from social anxiety, I absolutely dread the interview process, particularly the whiteboard tests, but also all other forms of tests, I agree 200% with this article. I’ve been passed over for positions that were right up my alley in terms of challenges and capabilities simply because I do not perform well on these tests.
I believe I’m not an anomaly and that many competent developers have some form of social anxiety. Why on earth companies rely on techniques that effectively disqualify many applicants because of non-related factors is beyond me. It is equivalent to disqualifying applicants because they’re in a wheel chair…
Fantastic article!! Here’s my story:
I am in my last semester of college, to get my undergrad in computer science. After almost 2 years of software development internship experience at different companies, I now find myself bombing technical interviews for full-time entry-level positions.
Mind you, I have had many verbal technical interviews where I can explain things in detail very well, have personal projects, and have legitimate work experience and references. I have been told by senior developers that I have a bright future, and have consistently delivered successful code in the workplace.
As Terry says, all forms of tests under time constraints make me very nervous. I really suck at it. I’ve solved such problems many times over in school, have worked with certain technologies at one time or another, but I forget these things if they’re not fresh on my mind.
Why? Because I have to do all kinds of homework, study for tests, pay rent and bills, deal with crazy roommates, my car keeps breaking down, my clothes all shrunk and don’t fit me, I’m expected to know a vast multitude of things that aren’t taught in school, somehow I have to allocate time to work on personal projects, try to keep up with friends and family, etc.
I have just enough time to pretty much suck at all of these things, except for school — I have placed school above all else. I have an excellent GPA, have learned a lot, and am very proud of myself in who I’ve become.
I thought that was the right thing to do!!! Now I find that it’s not even close to good enough, neither is my internship experience. It all comes down to solving mathematical whiteboard oddities, and regurgitating every bit of code and framework inner workings that I’ve been briefly exposed to over the past few years. And then I get so nervous in such technical interviews that I can’t hack it with things that I actually know like the back of my hand.
The thing about school is that you know what you are studying for, and because it is fresh on your mind you are very good at it. Then you have to go study some other stuff for some other classes, and it goes to the back of your mind. This applies to previous work experience as well.
What I would really like is if a college student looking for an entry-level position would be told ahead of time what to study for the technical interview, as this is actually the situation that a college student is in and can’t remember EVERYTHING.
I have variously worked as a programmer and as a tech writer, As a tech writer candidate, I am invariably asked for writing samples, Before the interview, along with the resume, include writing samples, Every. Single. Time.
As a programmer candidate I was asked once, in many years and jobs, for code samples (and the interviewer leafed briefly through them, checked them off in his mind, and then ignored them.) Seriously??
Ask for code samples. As the candidate to walk you through them. Why did you write the function this way? Why did you use this language? This library? Where are your tests?
I have never understood why programmers are not required to bring/submit code samples!
Interview whiteboard coding tests in an interview are usually given by managers/directors who can’t code themselves. Or they ask their subordinates, developers or engineers, to do the deed. I for one can’t stand working for a boss that can’t code; if you want to talk the talk then you better be able to walk the walk.
Coding is done on ones laptop, tablet or phone with an editor/ide in one screen and google/bing/stackoverflow etc opened in another screen. And if an interviewer asks you to re-invent the wheel then you should ask them if re-inventing the wheel is going to be a requirement for this job.
Basically, employers these days don’t want or don’t have time to do the hard work of thoroughly examining candidates past work and checking references. Many managers/directors do not have the technical skills to go through a candidates past projects and code.
I would say about 75 percent of the people that interview me have little or no regard for what I did in the past. Do you really want to work for someone like that?
So there you have, we all, default to this really stupid exercise known as the whiteboard coding test.
Interview whiteboard coding tests are for managers who don’t know how to code themselves or who don’t know how to code that well, so they force one of their underlings to give these ridiculous tests that is completely devoid of how a candidate will perform on an actual project. Or the manager doesn’t have a sufficient amount of hard IT skill to engage a candidate in a meaningful discussion about their skill set with respect to the position at hand. Most great code these days is written with the help of google, bing, stackoverflow, etc along with online programming docs, that’s called RESEARCH girls and boys. And anyone who tries to re-invent the wheel should not be hired. There are many ways to test coding proficiency, provide a home work exercise and have them explain their answer during the interview, look at their github page (although a lot of code I write can not be placed publicly on git hub), references, references, references. Did I say check out their references? And put simply, a good interviewer who knows how to code and is knowledgeable about the full scope of current computing technologies can find out within a few minutes if the candidate knows what they are talking about by asking them the simple question, “So what have you been doing?”. Probably the most effect way to test a candidate knowledge is explain in detail the project you want them to work on right down the lines of python, SQL or C# code and watch for what questions you are asked. A successful candidate should be asking a lot of intelligent and relevant questions. If all else fails, hire the candidate for a probationary period of time and fire them if they can’t do their job.
So agree with this. Never did well on coding tests, yet somehow managed a 35 year career. Some coworkers insists this is needed to weed out inept, but I have doubts. The questions are usually what would be asked of a newbie or recent grad, stuff I haven’t coded in years, if not decades. As another blogger who worked at least 20 years for top shelf fortune 500 companies so elegantly put it, did she fake her way thru all this time? Do other professions have to put up with this crap?