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

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

7 pointsbrooklyndavs10 comments

The way we interview and hire in this industry is, generally, fucked up. I've been interviewing off and on for the past 6 months. I've observed two methods that companies use. Both, it seems to me, are bad ways to judge the quality of a developer, although one slightly less so.

1. You need to whiteboard this code out. It's an algorithm that I use to show how smart I am. Solve it without any access to books or the internet. While I watch you. Oh, this problem has nothing to do with our business.

2. Here is a link to our obscure little puzzle. You have X number of hours/days to solve it. Have fun spending all your free time this weekend figuring it out! Oh, this also doesn't have anything to do with our business.

I guess if these are the only two ways #2 is preferable but that's like preferring death via lethal injection to death via the electric chair.

There has to be a better way. Why do I even have my gitHub account in my resume? Why do I list the companies I've been at and the roles I've had? Why don't you ask me my experiences solving REAL problems for REAL businesses? Whiteboard algorithm guy? Go Fuck Yourself

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.

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.

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.

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.

Is there a way to compensate someone monetarily for this week? Bring them on in some sort contractor capacity? Maybe more people would bite at an opportunity like this, especially if they are getting paid for their time. Personally, I know I would.

What about those who already have a job? And unless the company is hip, the really good candidate accept one of the half dozen offers they already got.

This biases the hiring pipeline to people who do not have jobs currently. Its possible that you want that bias in your process, but I doubt it.

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

I'm talking about complex algorithms here. Not something simple like FizzBuzz. Besides, I hope FizzBuzz (or something similarly simple) could be done via an initial phone screen. If you need to see the code fire up some sort of collaboration tool. It seems like a waste of everyone's time if they come in for an in person and they fail at FizzBuzz.

Reply on news.ycombinator.com