[safety-third]

I can't find the article because its hidden behind Google's previously admitted coin flip, brain teasers.

An interview only has one question to answer: How long will it take this person to do what I need? Everything after that is you trying to sell the company to the candidate. After you do the interviews, you pick the person who needs the least ramp time.

Quietly staring at a person writing on a whiteboard while taking notes isn't communication. It isn't normal. It tests nothing except the candidate's whiteboard interview technique. You test their communication ability... by communicating with them. Have a conversation.

Testing someone's determination to do useless studying for your ridiculous company is pointless. I am not here to get you to join my cult. I am here to pay you to do things. That's it. Unless your job is to design and review algorithms, I don't care if you can draw depth first search on a whiteboard blindfolded.

There are a million ways to figure out how long it will take to get a person up to speed. I make a list of the skills needed for a position. I write down an approximate time to learn each one. In each interview, I figure out what skills the person has by discussing that skill. That's it.

[hvidgaard]

I simply have to disagree. The amount of unqualified candidates that have a decent CV and are reasonable to talk to, but completely unable to correctly write a while loop is too damn high. That is what my whiteboard questions filter out. They're super easy stuff such as "I give you as input a list of integers, return the index of the first consecutive pair of numbers that when added is 42 - you can use any language or pseudocode". If they write it correctly, but not handle the obvious edge case with the end of the list, no pair existing, you can ask them about this. This is basic code review and discussion of a solution with a fellow developer - both very important.

You'd be shocked how many people that write years of relevant programming experience and fail that. Do we get some false negatives, probably. But it's a reasonable price to pay compared to hiring someone unqualified.

I think a big reason for this, is that you can teach yourself to be a developer, and all the millions of articles and videos on the topic mean you can get something done without understanding the fundamentals. I think this, for some, create a false sense of competency.

It's easier with say, structural engineers - if they have an exam and or relevant work experience, there is a pretty high chance that they're up for the job. And you wouldn't hire a junior engineers without a senior person overseeing and checking their work for grave mistakes.

[safety-third]

I would not be shocked. I meant it when I said to weed out the charlatans. I certainly do some basic FizzBuzz. I do it over the phone and in-person because sometimes they get a friend to do the phone interview. There is a giant difference between this and the current whiteboard interview fad.

I don't think false negatives are good. How many positions go unfilled for months and years? A lot. At a larger company, it won't take long before they remove the position entirely. They might not be wrong to do so either. Eventually your bus factor goes to zero, and whole teams go away. I have never seen anything beyond FizzBuzz, experience, and conversations be predictive for actual work. Even these only weed out the most outrageous candidates.

I work in the chemical engineering industry. They sort resumes, ask questions, and call references. They don't ask them to do sophomore level process energy and mass balance with multiple components and vapor-liquid equilibria on a whiteboard. Most aren't Professional Engineers either. Junior engineers used to be a crap shoot. Now there are so many graduates compared to junior positions that most companies will only hire people that interned with them.

[hvidgaard]

> I don't think false negatives are good. How many positions go unfilled for months and years? A lot. At a larger company, it won't take long before they remove the position entirely. They might not be wrong to do so either. Eventually your bus factor goes to zero, and whole teams go away.

I'd rather that happen, than hire unqualified people. Hire and then fire someone is damn expensive - months of salary and a lot of hours wasted. If you don't get them out of the door fast enough, the damage they can do with incompetency is even greater.

[safety-third]

I have personally hired false positives. Like you say, they are expensive. I have never once hired someone who was literally incapable of doing the job. It's never because of work directly. A person who was incredibly professional in the interview turned into a massive asshole at the office. One fought good coding practices because he thought it was over-engineering. Another spent all day playing online poker on their phone. One spent their entire time at the office making Forth interpreters.

Doing 7 hours of whiteboarding interviews for every candidate won't flush out any of these. Not a single one. If you can tell me the magic 8 ball I need to shake to fix this, I am wide open to suggestions.

[celticmusic]

> One fought good coding practices because he thought it was over-engineering.

You would have considered me a false positive then, despite the success of my career.

[perl4ever]

Nobody is perfect for every job.

A phone app is one thing, ERP or accounting is another, avionics is another.

[mtberatwork]

> You'd be shocked how many people that write years of relevant programming experience and fail that.

That's not saying much. I'm in my 40s, been in the industry for a long time, studied CS, etc ... but put the proverbial gun to my head and ask me to perform with judgement like that, I'd probably forget how to spell my own name.

[AllegedAlec]

> The amount of unqualified candidates that have a decent CV and are reasonable to talk to, but completely unable to correctly write a while loop is too damn high.

There was some research into this, and IIRC, only half the programmers, both experienced and junior, got a while loop right (IE: no off by ones etc) the first time.

[indecisive_user]

I had to write a while loop in an interview recently, and I also made the off by one error on my first attempt. But after I ran through a couple test cases by hand, it was pretty easy to see the mistake and fix it.

I wouldn't say getting it right on the first try is the most important thing. Writing code, logically thinking it through, and running through test cases to fix mistakes is pretty similar to how coding on the job is, albeit with less contrived problems.

[perl4ever]

A long, long time ago, somebody wrote about how most supposedly competent programmers can't write a correct binary search under test conditions.

[hvidgaard]

Unless we simplify it significantly, it's surprisingly hard to do. And completely irrelevant anyway.

[perl4ever]

"You'd be shocked how many people that write years of relevant programming experience and fail that."

Do you find people who did well on a preliminary test where they wrote some code fail this? If not, then why do the whiteboard? If people do fail, do you assume it's because they cheated on the previous test?

I think your stated explanation is incoherent, because you are claiming that self-taught developers can "get something done" without being able to write your ultra-simple algorithm. How can that be? You're not saying that someone can't handle B-Trees and you therefore won't hire them, you're saying they can't do anything and yet somehow they were hired and do stuff at other places. If they can "get something done", why are they useless?

If your comments are based on a lot of genuine experience and sincere and heartfelt, had you considered that maybe what's going on is simply that a large percentage of the people in the industry do not and cannot do whiteboard programming, but only write code at a computer? I have literally never had to, to get a job, and I'm not sure I can remember doing it in undergraduate classes either.

Joel Spolsky (and no doubt others) wrote something about how you can't hire the best people by just advertising a job because mostly the same people apply to all the jobs and the really good ones aren't in your pool.

But a corollary to that, I think, is that when you do hire some decent people, and you go on doing it, because it worked adequately, you are likely to wrongly conclude that is what decent people look like. It's not just the rock stars that are missing from your pool, it's the people who are terrible at interviews and are much more loyal to a job than those who can handle whiteboards and small talk. You may be in a bubble where you, and the people you hire, are working much harder than people in another bubble, but it's just a different way of doing things, not the only way.

I think this idea of your hiring pool not being representative and getting wrong ideas of what good and bad people are like has implications for diversity of various types, but I'm not going to flesh that out here.

[hvidgaard]

> Do you find people who did well on a preliminary test where they wrote some code fail this? If not, then why do the whiteboard? If people do fail, do you assume it's because they cheated on the previous test?

My preliminary test is a phone call if there is more candidates I want to interview than I have time for. No coding.

> you're saying they can't do anything and yet somehow they were hired and do stuff at other places.

I have not stated that they've worked other places. I said that they claim to have worked at other places - that is a very important distinction.

> If they can "get something done", why are they useless?

I don't need people that can "get something done", I need people that can work in a team, do code review on both sides, do pair programming when the situation calls for it.

> It's not just the rock stars that are missing from your pool

I do NOT want a rockstar. They're expensive and not that much more productive. I want a great team and you build that carefully with hard working people that complement each other.

> it's the people who are terrible at interviews and are much more loyal to a job than those who can handle whiteboards and small talk.

We've had our share of people unable to perform a whiteboard "problem" as interns and for one-off things. Commonly for those that was unable to function in teamwork, was that they want a task and be left alone. That is not how you produce great software, and it certainly is not how we do it because of the software we write.

> I think this idea of your hiring pool not being representative and getting wrong ideas of what good and bad people are like has implications for diversity of various types, but I'm not going to flesh that out here.

Again, my goals are people that can work in a team. A whiteboard is representative for both communication and a basic level of competency.

[perl4ever]

"Again, my goals are people that can work in a team."

Ok, but what does that have to do with writing code on a whiteboard? I'm telling you a fact - there is a whole world out there that doesn't do it, before or after a hire, and yes, of course they work in teams. I'm not out for an argument on how people should do things, so don't make it into one.

[hvidgaard]

Because we actively put people in the spotlight when discussing solutions or issues. Sometimes it's a whiteboard, sometimes it's a shared coding session, or something else. We use whiteboards extensively, and there is a good reason people do this in teamwork from educations all the way to the very top of engineering teams.

I have had a team that wanted to just chat on Slack and approach the tasks in a divide'n'conquer fashion. It does not work, and introducing a "lead architect" to structure everything is like pulling the reins of a mule - it will move backwards. Everyone needs to participate and feel shared ownership.

So if people cannot code simple shit on a whiteboard, it's my experience that they are a poor fit for this way of working.

[ProZsolt]

Doing interviews (as an interviewer) greatly reduced my impostor syndrome as a junior software engineer. When a guy interviewed with 10+ years of "experience" couldn't write a for loop was eye opening.

I work really bad under pressure and don't like memorizing algorithms. I hate programming anything complex on a whiteboard or anyway on-site.

Simple stuff, like your example is fine. It's a good way to weed out charlatans. A few points what I consider a good test:

* No previous algorithm knowledge required.

* No ticks.

* An average candidate should finish it in 5 minutes. (So we gave them 10 mins)

* It can be written in 10-15 lines.

* Pseudocode is fine

[safety-third]

I dislike pseudocode. I make candidates use an actual language because it smoke checks the ones who put X years of Y language. I don't demand perfection, just that the general shape be there.

[perl4ever]

Unlike some people, I'd be happy to spend a few hours over a few days writing some code for free in peace and tranquility. If I didn't have a job already, I'd be happy to prove myself for six months as a temp. I have never been in either situation and not excelled.

Why should this be inadequate to demonstrate technical skills?

[celticmusic]

Which would punish people like me who will work across 3-4 languages daily and therefore often forget or confuse which library call does what in what language.

[ProZsolt]

Same here. Sometimes I forgot how to define a class method. Is it def? Is it func?

I can write Rubyish, Goish, Pythonish or PHPish pseudocode, but the syntax will be only 90% correct. I remember distinguishing features(like Ruby blocks), but features that all language has always a blur.