Tell HN: Hey algorithm on a whiteboard during an interview guy? Go Fuck Yourself

Well, in general I agree. I would think the best way to test someone, is to have them solve a business problem in the office for a week. But that isn't exactly easy to manage when you have many candidates who themselves do not have free time.

FizzBuzz is best asked during the interview, possibly with a whiteboard. It has nothing to do with our business.

Because quite simply, resumes don't work. Lots of great developers have terrible resumes, lots of terrible developers have great resumes, they have zero correlative value in picking hires. When working on hiring pipelines I spend most of my time arguing for their complete removal.

Interviews around resumes can have amplifying effects. Being able to talk a good game about your past does not mean you can perform at writing software. Further there is a whole class of developers who do very poorly explaining their past and selling themselves. Lots of those developers do a great job of solving actual REAL problems for REAL businesses. Further, some of us work in environments where talking at any depth about the technical problems we've solved open both parties to potential lawsuits.

Maybe in some industries, with some population of developers a Github profile is useful for evaluating candidates. But there are whole swaths of candidates who have no profile on Github, or only use it for dumping toy projects or experiments. It is certainly not something you can build a repeatable hiring pipeline around.

This leaves us with very few options. Design sessions on a whiteboard suffer from many of the same problems as traditional interviews, but they are at least similar to an activity that is actively part of a developers job. It is a near daily occurrence, at least on the teams I've been on, to have sessions solving problems at the white board.

Work samples are ideal, but the combination of business relevant, not proprietary, representative and able to be completed without being a huge burden is very hard to come up with.

So, while I completely agree, our industry is terrible at filtering talent and in the future we are likely to back on our current processes as silly, I suspect the future will hold more design sessions and work samples, not less. Hopefully we just get better at creating them.

Like standardized testing, whiteboarding problems is another good data point. It provides a well-understood test given in a well-understood context. It shouldn't stand alone, but it might be the case that a person who can't do a simple to intermediate algorithm at a whiteboard in front of others under a pressure isn't a good fit.

Personally, I usually find questions about basic networking and the fundamentals of programming to be most revealing. You usually don't need to dig very deep to find out if a person really has a clue.

I personally use whiteboard coding tests. If a candidate prefers, I am okay with paper or code editor but I don't allow book or internet use. I don't penalize for syntax unless it indicates gross misunderstanding of the language. I usually ask questions that typically require 5 lines of code and under 10 minutes of effort. For calibration purposes, I expect myself or other coworkers to solve the problem in 2-3 minute. Most candidates fail in these basic coding tests.

I also don't use obscure puzzles. I used them when I was starting out interviewing but have long since given up. Puzzles are usually solved by those who heard them before or are very strong candidates but that is pretty rare.

In my industry github is not common because all code is proprietary. I don't want to penalize those who use their personal time for non coding activity. I do ask people about their roles and experiences. A lot of time people exaggerate their contributions and skills in their resume. Even with a basic query on their resume, you can find out they don't know much. Often the work was done as part of a team where they had minimal contributions.

I feel your pain. I am graduating in a few months and recently interviewed at one of the "big" companies. I interviewed with 4 different teams on 3 separate occasions totaling 40 hours give or take. And what was the process like?

A bombardment of random questions and whiteboard problems. One involved an algorithm to determine the best 8 pin pattern for an analog clock. They said they wanted to see how I tackled problems. I was furious.

In the end though, how do you judge a developer's competency? I know there are people who thrive on these problems but can't actually program on a complex system and vice versa. You will eventually find a problem that you crush and a team that fits your niche. At least that's what I have been told.