Nope, I think lots of people perform 'low skill' in a whiteboard scenario that are not. And the arrogance of their interviewers gets them on HN making very bold claims about other people's skill levels without consideration for the scenarios involved.
Don't get me wrong-- I've worked with very incompetent people. Many of them would have passed a coding interview though.
My whiteboard coding interviews now mostly consist of asking someone to write a for loop with one state variable. That's my bar for low skill. If you can't write 6 lines of code in 45 minutes with one loop and one variable, then you and I are going to have problems working on logic problems on a whiteboard on the actual job.
I've interviewed enough people who don't even know the syntax of a for loop for the language that they chose to use.
As a general matter for how the industry as a whole interviews, I agree though; I am no longer a fan of tricky algorithmic or esoteric data structure questions in whiteboard interviews. The problem I find with other people's interviewing questions is that most people are still asking things that are way too difficult, and they don't end up judging anything other than "Did this person just cram hundreds of hours of algorithms questions?" or "Did this person get lucky and happen to know this type of problem ahead of time?".
For better or for worse, my company schedules me for like >90% system design questions now, which I prefer anyways. Start with a very simple problem and system, and then just throw wrenches.
I'm only 90% sure I know the syntax of a for loop in my chosen language, C#. The reason for the missing 10% is that I never write this syntax.
Most loops are covered by a foreach or by LINQ (think: map and reduce, buy nicer).
The few times I actually need a for loop I type: "for" <press enter> <type the limit for i> <press enter> and then I focus on the loop body. If my needs are more complicated, I _modify_ the for loop my IDE gives me.
I felt this way too until I was made to start giving interviews. However low a bar you're imagining, I assure you I've seen "strong on paper" candidates who failed to meet a lower one. I don't know if people are lying, or people cheated through school, or talked other people into doing their work at the jobs they claim to have had, but it's really astonishing how unable to write code they can be.
However, the particularly insidious candidates are the ones who have developed a skill for talking about software/programming but can't actually write code no matter how much help or prodding they are given. As soon as you accidentally hire one of those, the case for technical interviews becomes a lot stronger.
I was going to write a similar comment when I saw yours. We've recently hired someone who was great on paper, was adept at talking about software/programming and was able to present some code he allegedly wrote and explain it. He seemed like a great fit based on the discussions but we hadn't actually given him a whiteboard interview.
Once he joined the company he proceeded to actually be completely unable to write a single working piece of code. Everything he wrote needed to be reviewed and had major glaring issues. When confronted about it, he would say that he couldn't figure it out so decided to just commit his unfinished code.
That guy was senior, had worked for 20 years and is really good at talking but when it comes to actually developing software, he is completely utterly incompetent.
I am constantly surprised at how many Brillant Paula Bean [1] developers are out there successfully interviewing, getting hired and BS-ing their way through jobs. I've always wondered if this is as prevalent in other industries outside of software.
I don't know how many people saying otherwise would constitute sufficient evidence in your mind, but add me to the list of people that disagree with this sentiment. I've had candidates who couldn't code a loop. Not "did something suboptimal", I mean literally couldn't write a single line of code.
I've had candidates who seemed incredibly accomplished when talking them, who showed amazing looking demos and could talk at length about them. But when given a task to do on the computer, given 2 hours alone to sit and code, couldn't do even the first part of the exercise - despite it being something you could literally copy and paste from the documentation that we gave them a link to!
I've frozen in interviews and been unable to think on simple problems just due to anxiety (which I've never experienced at work; if I can't think, I just say, "let me think about it" and I get back to the person in a bit). Other interviews I've completely demolished - solving problems that were supposed to take 30 minutes in 2 minutes, for example.
I think the type of problem and structure we use for interviews is bad. Let the candidate code alone without you watching. Give them internet access. Come back in an hour or two, or let them do it remotely or as a take home. This is more like our real jobs; and gets rid of cutesy "do you know this algorithm?" questions, which many whiteboarding problems are. Instead of going for pure data structure / dp / search / sort algorithms, have them implement things like business rules.
I'm 100% sure I've come off in a couple interviews like one of those "phew we dodged a bullet there, guy can't code at all" stories. Meanwhile actually I can and many employers have been very happy with my ability to do so, and I've had a long and reasonably successful career.
The problem's not even that I'm bad under pressure, and in fact I've repeatedly been told the exact opposite by people who've worked with me. The problem is specifically about doing a programming performance in front of an audience, in an interview rather than co-worker context. I'm god-awful at that unless I'm heavily prepped for exactly what's going on. No tools? I'll forget basic syntax, yes even in "a language I chose". Let me use tools? I'll forget how to use them, or get self-conscious and avoid things I'm not entirely sure will work, overriding my own muscle memory. It's a very specific problem but I doubt I'm the only one who absolutely can do the job just fine, but is also entirely capable of coming off like a complete "faker" in an interview.
[EDIT] to make matters worse I can talk about programming just fine in that setting, which probably adds to the "he's some kind of social engineering genius who learned to sound exactly like a competent programmer while somehow also not learning a single thing about programming" impression. It's not usually an issue, but I'm quite sure I've reinforced some interviewers' notion that it's a good thing they do whiteboard screening because they're overwhelmed with lying applicants, and that I was one of them.
Exactly. Yet if you listen to HN you get the impression 80% of the industry can't even do their job. Yet, if that were the case how the hell are they hiding that from their current employer??????
I've met one developer who couldn't do their job, and he moved into a pre-sales role shortly thereafter.
Everyone else was fine and did a good job but send them unprepared to a random interview on any given day of the week and I'm sure it'd be another one of those "well we dodged a bullet there".
> The problem's not even that I'm bad under pressure, and in fact I've repeatedly been told the exact opposite by people who've worked with me. The problem is specifically about doing a programming performance in front of an audience
Sure a "whiteboard interview" basically optimizes for people who can actually pass whiteboard interviews rather than people who can do the job.
But to claim that there is a NON-NEGLIGIBLE number of people who basically become 100% ignorant when under the stress of a whiteboard interview BUT are excellent employees in any other stressful situation is, to say it in nice words, [requires citation].
And if one really has this apparent rather unique type of handicap, then better mention on CV to try to get some empathy from the hirer, or just _train_ to avoid it. Yes, most people do _train_ for the express purpose of passing interviews.
I suspect some significant percentage of applicants may not have a disability, exactly, or always totally flub an interview in this way, but may do so often enough that it looks like the level of competence in the industry is much lower than it actually is, if one is taking one's personal experience with interviewees as an accurate measure of that. Add to this that assuredly some of the people confidently complaining about how 90% of their applicants can't write a for loop overlap with the ones generating complaints from applicants that some interviewers are themselves incompetent and asking broken questions (I guarantee you the people doing this think they're great interviewers and getting nothing but signal from their process, and they're probably also likely to exaggerate stories when relating them), then factor in a real tendency to take a 90% OK-to-good signal in interviews and practically forget it happened, taking the 10% bad as more accurate, and I think it's highly plausible the state of things isn't nearly as bad as some believe it is.
Tech interviews are remarkably scattershot in the form they take (outside well-known big companies), and are unusually anxiety-generating, even in the notoriously anxiety-filled field of interviews. Describe what one might (emphasis on might, part of the problem is that it's so often a surprise) expect in a tech interview process to some people outside the industry, and gauge their reactions. I definitely think it's likely they have even worse signal-to-noise ratio than is commonly thought.
[EDIT] Certainly I find it far less plausible that there's an absolute army of people out there, dwarfing the count of actually capable programmers, who are brilliant con-persons but too dumb to figure out that that skill itself is more valuable than programming, outside the top couple percent of programming jobs by comp, and apply it more directly to business roles that actively want it.
I don't think it's 90%. I'm saying there is a very, very low bar, but I would say it's hit by 20%-30% of candidates that reached me, not that many. Obviously this depends on much you offer, whether HR prefilters, and the like. But this is not 90% of candidates, I think.
And I'm quite confident it's not the interviewer. Usually the panel is quite anonymous when it comes to calling a "bullshit" candidate. We ask panel persons individually to avoid the "no one wants to contradict someone calling X bullshit'" effect.
I don't think tech interviews are _any_ worse than the ones outside. If anything, we have less standardization than other industries. I work for a engineering company first (software second) and the engineer interviews are basically _manufactured by HR_ (not engineers).
I wholeheartedly agree. Note that my second example was exactly that type of interview - we leave the candidate to code alone, technically sometimes in the same room as us but sometimes in a separate room, but either way with only a few "check ins" every 15-45 minutes depending on how things go. They have internet access, a base file and console session open that can run the file, and an editor already set up (not necessarily their editor of choice, though we've had people install an editor at the start of this process).
In this scenario, having someone literally be unable, in 2 hours, to replicate the first example code of some library, when they have access to almost identical code in the docs, is a pretty good filter.
Everyone experiences stress on an interview, and thus may not be able to solve "do you know it" problems that he would have been perfectly solved after a better night's sleep. That is not the problem (we call them "happy idea" problems around here). I really dislike being asked this type of problems and I also dislike asking them for these reasons. Despite the fact the positions I've interviewed for you end implementing "pure data structures" much more than you end up implementing business rules (we build software for engineering: simulation, optimization, etc.). So imagine how low I set the bar between my colleagues.
The problem is when you apparently _forget_ the syntax for a function declaration in a programming language you claim N years of experience in your CURRENT position. This is just absurd. Our you suddenly get completely stuck with counting odd numbers on a sequence or the like. And this happens surprisingly frequently. I just cannot believe you can have this type of anxiety (I am extremely shy myself) outside your first or maybe second interview.
I think my daily driver language (Ruby) has become so ingrained in my mind that it's written out of muscle memory in Vim, and translating that direct connection from thought to Vim into a whiteboard might actually be challenging. You almost never write for loops in idiomatic Ruby anyway, you use an iterator chain.
Languages like C that have a single official for loop syntax are a bit easier to remember, in part because it's a syntax I have previously used on a whiteboard rather than exclusively in actual code.
So if a candidate can't write a loop on a whiteboard, maybe let them try in a non-IDE text editor, or have them glance at a formal grammar for the language as a refresher that won't give away the game to someone who can't actually code.
Even if your IDE would type your entire programs for you, you would still know the syntax of the language just because I am 100% sure you have actually read more code than you ever wrote. And do note that even in C there is not a single official loop syntax -- a while (get_next())-like thing is a perfectly valid loop in C. All of them valid answers -- I used the word "sequence" and not "C array" for a reason.
And if I start showing them an EBNF grammar for the language, now that's TWO languages that you will show you don't remember rather than one. I find this even more absurd; you don't remember anything of the syntax of the language you used at work for years, but you think you can rediscover it from the FORMAL language specification in a whiteboard?
> Nope, I think lots of people perform 'low skill' in a whiteboard scenario that are not. And the arrogance of their interviewers gets them on HN making very bold claims about other people's skill levels without consideration for the scenarios involved.
This is it, in a nutshell.
In all my years of interviewing candidates, I've never run into the mythical experienced developer who doesn't know anything about programming. Yet according to HN lore, there are hordes of them out there.
My theory is that the only thing there are indeed hordes of, is experienced developers who can be made to look dumb by subjecting them to whiteboard puzzles, algorithm trivia and other such questions which are completely unrelated to the job performance.
> We can't understand why so many people "fail" the Fizz-Buzz test unless we understand why it is "hard" (for them).
But the article doesn't even talk about the environment, which is what it's all about.
It's hard "for them" because they're being asked to write the code on a whiteboard, with a job/income on the line, with stress and anxiety dialed up to 11, with someone breathing down their neck watching, while expected to simultaneously provide cheerful ongoing commentary to "show how they think".
Under those conditions, I totally believe close to 100% perfectly competent developers will fail at it. But of course it has nothing to do with the programming part.
Most of us have heard of FizzBuzz while chillin at home reading articles and immediately thought "that can't be hard" and tried it and indeed it is laughably easy. So we can't understand how "they" could fail at it because we didn't experience it under interview hazing conditions.
In my case I failed at fizzbuzz because I was interviewing after spending a full day merging 2 versions of dbdumps into one, while getting rid of duplicate entries/foreign keys, etc. I could still do a pseudo code version of it, but I couldn't remember modulo function. At all.
Sometimes it's easy. We had a candidate who looked good on paper and sounded good in person. When it was time to start the screening test he asked to go to the bathroom. And never came back. We took that as a red flag.
You're right to question it, but this is also why testing is so prevalent apart from the deluge of unqualified/barely qualified applicants. It's possible for a single person to spend an hour (perhaps over lunch) with prospective candidates and better evaluate them, with a corresponding better evaluation of the company by the candidate, without needing to do the multi-stage multi-test multi-people rigamarole big companies are addicted to. Similarly such people can usually detect resume BS better and whittle a list of 50 down to a shortlist of a few to spend that hour on each and come away with more than one good fit. But the skills needed to do that aren't widespread or taught or in many cases even acknowledged as existing. Hence tests, where when followed as a script can be given and scored by even the most disinterested programmer who'd rather be programming instead of doing their manager's job. Now you don't even need someone ok at resume BS detection to narrow the list, you can parallelize that 50 hours.
Of course the tests are proxies and often aren't even scored objectively. And most tests aren't very good at proxying anything general (hence companies' tendencies to have several). There's a lot of problems that remain, our industry doesn't take hiring seriously. But testing and trying to test as early as possible have come to dominate for not totally unreasonable reasons, and persist at the large companies despite the well-known negative trade-offs. It's a startup's/small company's advantage to not copy bigco's interview processes.
