Live data from Hacker News

Hiring Without Whiteboards

github.com

321–330 of 471 posts

Re: Hiring Without Whiteboards

#321

I am starting to think the interview is a waste of time. Sure, you want to make sure the person is more-or-less who they claim to be on the surface, but you will never really understand their capability for reasoning with your problems until they are working in your process. One of my earlier jobs dealing with code involved a very brief interview (no whiteboard involved) followed by a 6 month contract offer. The deal…

> The deal was that I basically had 6 months to prove myself, and if everyone felt like it was working out (myself included) this would be bumped into full-time with benefits.

In the UK, we sort of have this in the form of probation - in most permanent jobs, you don't gain full employment rights until you've done a probationary period, which is usually six months. You get full salary and benefits during that period, but you can be fired with no notice at any time (or something like that).

In practice, though, the culture is not to use the probationary period as an extended interview, but more of a backstop against really screwing up hiring. You'd only let someone go after probation if they turned out to be absolutely incompetent or unsuitable, not if they were just disappointing.

It would be interesting to try using probation differently, though. Make the interview more of a screen, employ twice as many people as you need, only retain half of them at the end of probation, and be explicit throughout that this is the plan. I suspect you could implement and communicate this such that it wasn't absolutely horrible for probationers - active and transparent review during probation, one or two months' golden parachute, what else?

Re: Hiring Without Whiteboards

#322

I am starting to think the interview is a waste of time. Sure, you want to make sure the person is more-or-less who they claim to be on the surface, but you will never really understand their capability for reasoning with your problems until they are working in your process. One of my earlier jobs dealing with code involved a very brief interview (no whiteboard involved) followed by a 6 month contract offer. The deal…

In 2012 I was told Google gets 1 million applications a year. How do you decide which 1000 of those get 6 month contract offer? How many millions of dollars in lost productivity are you willing to lose of the people who don't pass your 6 month test that you had wasting space, taking up training time, having people have to review and reject their code, etc? What will those people do who gave up their lives somewhere else to be part of your company do when you tell them you've decided to not make them employee when their contract is up?

Re: Hiring Without Whiteboards

#323

The issue with LeetCode style interview is that almost EVERYONE can solve those questions after studying a couple weeks/months. The only thing that LeetCode questions predict is if the candidate has been training for LeetCode questions. The fact that Google, Facebook etc still use it as a gatekeeping mechanism makes me believe they want to find cogs that will specifically spend hours studying for it. Making sure that…

Maybe I am just extremely dumb, but the "hard" questions are actually very hard for me. The medium questions sure.

Re: Hiring Without Whiteboards

#324

Earlier quoted context omitted.

>There is statistical data saying the opposite Interesting study and really good discussion on HN at the time, but the opposite of "[Whiteboard interviews] often give a very good and reasonable signal that often has a high corollary to work performance" would be something like "People who do well at whiteboard interviews tend to be worse performers at work." I don't think that's what the study said at all; rather tha…

Also people act as though software is a job without anxiety. There is plenty of anxiety in this job. Sometimes under pressure you really do have to perform or push back and its good to know if people can do it.

The interview anxiety is a very specific type of anxiety - if it occurs during the day job - stay away from such company.

Re: Hiring Without Whiteboards

#325

Earlier quoted context omitted.

I hate take-home projects more than I hate whiteboard interviews. I think the best approach would be giving the candidate a broken app and have they debug it live or in a take-home debug-and-fix or debug-and-improve exercise. Could also have some refactor assignment. Has any company tried something like this before?

I don't understand how take home interviews are being held up as a better solution. They have two major flaws: They lower the cost for the company to zero. So they can widen their pool, and take a chance on more candidates, with no extra cost incurred for them. If you take this to the extreme – every company asking every candidate to complete a take home – then the result is far worse for candidates. There is no feed…

> I can say "you shouldn't spend more than two hours on this" until I'm blue in the face, but candidates think they need to polish far beyond what is reasonable

> I'd prefer to design a better in person interview than take the easy route that is disrespectful of candidates' time.

Why don't you just let candidates decide for themselves how much time they want to spend on the task? You can set the expectations, saying that you expect that the task of a given complexity will to take between 1 and 2 hours; but candidates should be free to spend as little or as much time on a task as they like. Some candidates will value their time and spend no more than is advised; others will be sufficiently obsessed by the task to spend more time. Why should the latter group feel guilty about exceeding the recommended time limit?

Re: Hiring Without Whiteboards

#326

We use a 3 step process, sans whiteboard: 1. First interview, the candidate interviews us. What market we serve, what our development processes are, what our technology stack is. If they express interest by being prepared and asking good questions, we send them home with 2. a programming task. Choose 1 of 5 tasks. The tasks are not abstract problems or puzzles, but come out of the designs we've implemented. We ask fo…

>1. First interview, the candidate interviews us. What market we serve, what our development processes are, what our technology stack is. I somehow feel this rewards opinionated developers. Also right now I'm looking at a couple places because their recruiters called me up and said they were willing to meet my requirements which are basically pay - I don't care about most of these things, if they want me to do stuff…

Aren't opinions something an employer should want in developers? And not just opinions on tech stack but all the way up to requirements etc.

If I hire a developer "to build X," I would rather work with the developer who explains that X is the wrong thing and we should actually build Y, than the one who shrugs, asks no more questions, and builds a really excellent X - that later turns out to be the wrong thing to have built.

Re: Hiring Without Whiteboards

#327

Earlier quoted context omitted.

I don't understand how take home interviews are being held up as a better solution. They have two major flaws: They lower the cost for the company to zero. So they can widen their pool, and take a chance on more candidates, with no extra cost incurred for them. If you take this to the extreme – every company asking every candidate to complete a take home – then the result is far worse for candidates. There is no feed…

At Caltech, most exams were take home with a time limit of 2 hours. Some were "infinite time". The students hated the latter, because it means there was no end to the time you needed to spend on the exam, meanwhile there were other exams, etc., to take. With a 2 hour exam, there's an end to it, and you know how much time it should take to do the problems. Much better. It's even worse if you're being graded on a curve…

Like you said, "there were other exams, etc., to take.". Presumably other competitors have other exams as well? You'll thus be competing against people with different time management skills.

Re: Hiring Without Whiteboards

#328

We use a simple 2 step process that allows both the company and the candidate to have more certainty about the opportunity. This only applies to technical jobs. 1 - First interview. Does the candidate know about the company? Does he know anything about the business domain? Conversation about problems he has encountered in his past experiences. it works like a knowledge sharing conversation, you really get to know how…

Wouldn’t this exclude the strongest candidates who can get other job offers?

Re: Hiring Without Whiteboards

#329
post #321

I am starting to think the interview is a waste of time. Sure, you want to make sure the person is more-or-less who they claim to be on the surface, but you will never really understand their capability for reasoning with your problems until they are working in your process. One of my earlier jobs dealing with code involved a very brief interview (no whiteboard involved) followed by a 6 month contract offer. The deal…

> The deal was that I basically had 6 months to prove myself, and if everyone felt like it was working out (myself included) this would be bumped into full-time with benefits. In the UK, we sort of have this in the form of probation - in most permanent jobs, you don't gain full employment rights until you've done a probationary period, which is usually six months. You get full salary and benefits during that period,…

If you got 2-3 of those failed probationary periods on your CV though, you'd be stuffed. But that's probably a good thing.

Re: Hiring Without Whiteboards

#330

Earlier quoted context omitted.

>1. First interview, the candidate interviews us. What market we serve, what our development processes are, what our technology stack is. I somehow feel this rewards opinionated developers. Also right now I'm looking at a couple places because their recruiters called me up and said they were willing to meet my requirements which are basically pay - I don't care about most of these things, if they want me to do stuff…

Aren't opinions something an employer should want in developers? And not just opinions on tech stack but all the way up to requirements etc. If I hire a developer "to build X," I would rather work with the developer who explains that X is the wrong thing and we should actually build Y, than the one who shrugs, asks no more questions, and builds a really excellent X - that later turns out to be the wrong thing to have…

There's a difference between opinionated and having an opinion. I think Rust is much more pleasant to work with (an opinion), but I'm not going to let it stop me from using other things (not opinionated)
Post reply on HN