Not my experience. At least when hiring for programming positions, the typical fatal issue is that the candidate's coding is weak.
In my first role as a hiring manager, I didn't stress coding tests for candidates with long work history on their resume. Since then, I learned better.
I've seen candidates with anything between 1 and 15 years of full time coding work on their resumes fail to answer basic fizz-buzz level coding questions.
At least for the candidates I've seen, the biggest single reason why they get rejected is failure to perform the one main function their job requires: coding.
A single question is pulled from subjects vast enough to fill up years of college and there is no time to research, as one would in the real world. Binary pass/fail with your pride/livelyhood/family on the line.
Please state your last exam conducted under such conditions?
Oh and your questions probably stink. I've gotten plenty of them with recursion that might take ten minutes in seclusion but simply not possible under the gun.
There is a difference between me asking you how to optimize a graph algorithm (good luck--I probably couldn't do that on the fly with references in front of me) vs giving me a basic FizzBuzz.
If I let you pick your language for your FizzBuzz, you need to demonstrate at least some of the following things:
I/O of any flavor (I'll even accept Logging if you don't do standard I/O or console I/O)
String formatting
Modulus Operator
Nested-If statements (or equivalent--Matching, case/switch, etc.)
I'm not looking for production code. I'm looking for 10-20 lines of "A High School senior with a computer class could pass this."
This is not limited to programming, sadly.
I used to have to interview VLSI designers with "Draw me an inverter", and 70% of them couldn't pass.
Now I certainly could do it in the course of a job within a week, with a day or two of research. But not under the gun.
That is the tech interview failure in a nutshell.
> Please state your last exam conducted under such conditions?
University entrance exams.
University graduation exams.
Any other test that you do which you need to pass to enter or continue your career.
Perhaps you should start listening.
> This isn't some high-level algorithm analysis on a whiteboard with a panel of examiners grilling you.
Happened to me just three months ago. The req is still open, wonder why?
To reiterate:
- Exams have a topic known in advance.
- Exams never have a person sitting there waiting for the answer.
- Exams are never 1 or 2 questions binary pass/fail with incredibly high stakes in unfamiliar territory.
Which is the brake pedal? If only.
I haven’t seen this. I have, however, seen lots of junior interviewers ask idiotic questions and wash candidates out for bad reasons, and then turn around and claim the candidate ”failed at fizzbuzz”, just to cover their own ass (or because they think TopCoder medium questions are “fizzbuzz”. Equally stupid.)
Me personally? I’ve never interviewed a senior person who couldn’t code at all. Not after the phone screen, anyway.
Why are "juniors" interviewing candidates? Let alone juniors asking "idiotic questions", and having decision-making capacity?
> then turn around and claim the candidate ”failed at fizzbuzz”, just to cover their own ass
Coding questions are among the most quantifiable and objective questions there are. If you know of something even more objective, let me know because I'd love to try it.
They are repeatable and have well-defined success criteria. Ideally you have two interviewers in the same room, and it's very clear if the candidate did or did not solve the problem. You can't really fudge it, even as a single interviewer, unless you're willing to outright lie that the candidate didn't write a working solution when he did.
> I’ve never interviewed a senior person who couldn’t code at all. Not after the phone screen, anyway.
Yes, if you do a coding phone screen, then obviously you're screening out those who can't code. I'm sure you saw some impressive resumes fail that screen, though.
Furthermore coding questions stop being quantifiable and objective as soon as you add in, "What feedback do you give, when, and how?" Two interviewers asking the same question of equivalent candidates can get very different results based on how stressed they make the candidate, what hints they offer, what followup questions they ask, how well they telegraph whether the candidate is on the right path, and so on.
I don’t know if you’ve noticed this, but the average age of programmers these days is just slightly above “right out of undergrad”.
If you wait for the senior people to interview everyone, you’re going to be waiting a while.
”Coding questions are among the most quantifiable and objective questions there are.”
Bullshit. Coding questions feel objective, and programmers love to pretend they’re objective, but like any other human evaluation process, they’re subjective. It’s not like you automatically get the job if you get the answer right.
Unless you’re verifying that your team is generating consistent, reproducible outcomes, I can pretty much guarantee that they’re not.
Only in the most trivial cases (for statements, not necessarily solution). If you want to assess engineering ability, specific coding questions are a small, tiny sample of the space, and generally the more difficult the problem the less useful it is.
Not sure how common this is, but I've been one of those flame-outs. It was during a Google phone-screen.
I was given a very simple programming problem, and something in my brain just broke (figuratively).
In retrospect it was probably from being too tense because I was star-struck about the employer.
But on that one particular interview, I could barely have written printf("fizbuzz\n");
Fortunately I don't find myself in that style of interview anymore. The guy interviewing me already knows I can code, so all we are really trying to see if there is a culture fit. My preferred interview location is over beer.
For example, if I test-run a new question, and it takes my engineers 20 minutes to solve it, I will add 30-50% handicap for stress. I.E. if a candidate manages to solve it within 30 minutes, that's roughly equivalent.
Unfortunately, there's no way to account for someone having a complete blackout such as you describe.
My comment referred specifically to candidates with at least one year of full-time hands-on development experience under their belt. The typical candidate I interviewed had 3+ years of experience.
If you want to code, then you should have ample opportunity to do so during a year or more of full-time employment.
If you were working in a full-time programming position for over 3 years yet you can't write even a trivial amount of working code during the interview, then clearly you either lack the capacity or the will to develop your programming skills.
Programming nowadays is easy - everyone has a powerful laptop and internet access. It's not like you need privileged access to some $100k time sharing machine using punchcards, and learn machine-language from obscure mail-ordered manuals.
What excuse does anyone claiming to "want to code" have for not coding already?
I'd be quite suspicious of anyone waxing poetic about their genuine heartfelt love for coding who somehow couldn't demonstrate any coding ability.
Would you believe someone who swears they "love long-distance running", but collapses after 50 yards and says they just didn't have the opportunity to put this great love to practice?
Genuine question... What kind of question(s) would I ask to get someone to demonstrate they can code? If my questions are effective, I'm fine. But if my questions stink, it'd be easy to overlook that fact that many excellent people wouldn't be able to answer them well.
Like, how? I used to hire undergraduate student sysadmins / coders, and we had zero candidates fail fizz buzz. None! The worst we saw were people who maybe had an awkward solution to the problem, typically because of unfamiliarity with the modulus operator.
I should also stress (again) that back then I brought candidates directly to onsites when their recruiters sent an impressive resume with 3+ years of "full time programming experience".
I learned the hard way that most people who unknown recruiters are eager to push through your hiring funnel are unemployed for a reason.
