I've given coding interviews for 20 years, and I'd estimate 9/10 candidates have been competent whiteboard coders. I don't have any explanation for the extreme discrepancy between my experience, and the "hardly anyone can fizzbuzz" folks. Of course this colors how I treat people. I'm much more inclined to interview seniors conversationally and judge competence by the way they talk about work they have done. I have a hard time imagining people investing the time to become conversationally fluent in a domain, as some kind of long con.

Beyond fizzbuzz, whiteboard coding is rough. Better to put someone in front of an actual computer. Space is constrained, hard to make corrections, some people (such as myself) have crappy handwriting...

It's such a weird hiring market. 1. There are a lot of imposters out there applying for programming jobs who can't program, and 2. There are a lot of very talented programmers out there who are being rejected by overly picky companies. Both can be true, and I'd argue that both are true. I don't know what the solution is. Current interviewing methods don't seem to be solving the problem.

I'd suggest a widely-accepted professional certification could help a lot, like doctors and lawyers have with the medical board exam or the bar exam. Easier said than done, but what we have today, where the candidate pool is overflowing with impostors with great resumes is not working.

That might solve half of the problem. But then we need certifications for employers - something that says, "Yes, I have a real job opening; I'm not just wasting your time." It needs to have real penalties if an employer violates it, too.

I'm not sure this is working, since employers not only search for general software developers but maybe also developers with domain-specific knowledge. It would be very time consuming develop a certification for every domain.

Hey, I said it was needed. I never said it would work, or that it was workable. But if you're going to certify workers, so that they don't waste the employer's time with interviews that are going nowhere, well, we need something to do the same in the other direction...

> I'd suggest a widely-accepted professional certification could help a lot, like doctors and lawyers have with the medical board exam or the bar exam.

"i passed the bar exam!" and nothing else doesn't get you a legal job you want.

and your medical boards, if i recall correctly, just mean you're qualified to go be a slave, er, uh, resident, some place for a few years.

On the other hand, passing actuarial exams does get you in on the ground floor of that career.

certifications are plentiful in the infosec sector. They absolutely do not solve the hiring problem.

Maybe because they are plentiful? I'm not familiar with infosec but if the bar for getting certified is "I can take a class and pay $XX to get this certificate" then of course they're worthless.

I agree, but in theory that can mean that we haven't found good certifications yet.

There are very few certifications that are worth the paper they are printed on.

Find me good certifications that are actually meaningful and relevant to my career, and I’ll do the study work and get them.

I have yet to find any.

And don't forget people being asked to do coding exercises for non-development jobs :|

(I've had that happen several places)

One problem with viewing the certification thing as a solution is people can then question - how do you know if you got the person who graduated at the top of their class versus someone who barely graduated? How are lawyers/doctors vetted beyond their certifications?

Make the bar for passing high enough such that even a person who scores the lowest passing score has demonstrated that he/she can at least code. A standard exam doesn't solve all problems with hiring, but it could at least help solve the very first "can this person even code at all?" screen that weeds out the total phonies.

Oftentimes this is the "CS degree from a good school" stick. But we don't have an easy way to check those claims, nor to evaluate what constitutes a 'good school'.

Id say recertification is an option as time passes. It keeps people up to date and on their toes.

Maybe just luck? I interviewed someone for a senior position last week and that candidate didn't know what an array was. That was probably the worst case I've seen but by no means the first time I've seen someone struggle with the very basics.

I think it's a matter of scale (how many you interview) and how good the people in front of you filtering candidates are.

Go long enough interviewing hundreds, you'll see a few no matter what. Have a crappy enough filter in front and you'll see them right away.

Same here. I have given an interview to exactly one person who would fall into this category, though most have been bad coders.

I remember interviewing a candidate that didnt even know what a binary tree was (context was big-O complexity of algorithms). That interview was really bad. Left the candidate in tears (which was not intended, but I think of their realization they werent going to get the job), and me annoyed at the waste of my time (should have been caught in phone screen instead of on site).

Was it necessary to know on the top of your head without Googling what a binary tree is for the position the candidate applied for? I've been a developer for 12 years and I've never had the use for that. Computer science is a VERY large field and being good at everything is impossible.

Asking the right questions at interviews are crucial for finding the right people. If a candidate for a programming job knows binary trees but doesn't listen to other peoples views I would say he's less worth to us than a listener that easily learns new concepts but is currently not familiar with binary trees.

BTW, leaving a candidate in tears is not professional recruiting. Please let someone with more people skills accompany you to your interviews, you might leave people with scars that takes years to heal.

I've been a developer for 30 years, and I haven't ever had a need for it, either - but I still know what one is. I expect that you do, too.

I came across it when studying computer science 20 years ago, yes. Heard about it after that but never directly needed the knowledge.

I'm sure it's used under the hood in a lot of code I write and have written but so is XOR, manual memory management and a bunch of other lower level implementations that I don't need to spend time on when developing on a higher abstraction level.

Not sure why you would expect all programmers to know about binary trees specifically.

Binary trees are the simplest kind of nontrivial tree, and trees are used extensively in programming. Most computer problems are solved using trees of one kind or another.

If you've never needed to know it, what is its value for finding a good candidate? A lot of these questions are basically testing whether you did a CS degree. If you're self taught, you might be just as good a coder, but have never had reason to learn what a binary tree is or how to implement quicksort, or whatever similar puzzle.

It's a nice way to filter out people who can code and basically do the job, but didn't have the financial resources to get a CS education, and weren't lucky enough when researching to see that his is an interview question. Although at least they'll know for next time.

Why on earth did you think that was a good, relevant question to ask? Did you ask about how to implement merge sort? I learned about it in college in the early 90s. Haven't implemented it directly since.

I'll bet, even with this feedback, you'll continue to ask that question, just because.

How often would you estimate either of binary trees or big-O were discussed in one year of that job?

At least, for sure I know I wouldn't hire you as a recruiter.

Most programmers never need to interact with binary trees directly, and I would hazard a guess that if I asked ~10 of my compatriots about big-O notation, maybe 2 of them would understand what I was talking about.