A Method I’ve Used to Eliminate Bad Tech Hires • Hacker News Board

Re: A Method I’ve Used to Eliminate Bad Tech Hires

#361

Post by arielweisberg » Thu, Nov 10, 2016, 2:20 PM UTC

toephu2 wrote: post #195

arielweisberg wrote: post #125

Earlier quoted context omitted.

100% This. I just wasted a bunch of time extracting an offer from one of AmaGooFaceFlix. Supposedly a top SV company with good compensation. Got an awful offer to relocate to an area where 1/4 to 1/2 the house costs twice as much and I would no longer be able to work from home. I would also lose a significant portion of my life commuting. The offer was comparable to what I made working remote from Boston. I don't mea…

Sounds like Amazon?

I don't publicly shame current or past employers as well as potential employers. It's why I listed multiple companies. You will have to reach out to me on some other medium to get details.

Re: A Method I’ve Used to Eliminate Bad Tech Hires

#362

Post by burger_moon » Thu, Nov 10, 2016, 2:24 PM UTC

pgl wrote: post #276

ceronman wrote: post #142

This is a great way of hiring, but unfortunately it doesn't fit in all scenarios. First, this model alone doesn't scale. Big companies interview hundreds of candidates every week. It's not possible to design and evaluate a weekend project for each one of them. This doesn't mean that they can't have projects, but early filters are needed. That leads to the classic phone and F2F interviews to rule out those who can't c…

> It's not possible to design and evaluate a weekend project for each one of them Can't you just design and evaluate one project that they can all do?

That will only work briefly because of glassdoor interview posts. However that might only mean tweaking it slightly every week or two.

Re: A Method I’ve Used to Eliminate Bad Tech Hires

#363

Post by jaymzcampbell » Thu, Nov 10, 2016, 2:25 PM UTC

Peroni wrote: post #306

shandor wrote: post #233

This seems like a pretty popular take on the interview process here on HN. However, there's one pretty glaring flaw that I've never seen discussed: if the interviewee can take the problem home, what prevents them setting up a hackathon with their friends at their place, and making the interview problem a team effort? A couple of knowledgeable friends can do wonders, and if you also prep with them a little you can pro…

This is the primary reason that you shouldn't make hiring decisions based on the test/problem results alone. The interview problem should only serve to be a conversation catalyst. If they got some help with the problem, outsourced the problem or simply googled prepackaged solutions to the problem then they are going to have a really hard time talking through the context of how they solved the problem. What you're tes…

Totally agree, conversation catalyst is a great way to phrase it too. This is very much the approach I've taken having had very mixed outcomes from trying to do just one thing or the other. I find using a simple, 100% self contained task that should take a few hours and then using that to kick start discussion has provided the best way for us to hire and screen people. We've found using a task that is very simple to get a working solution but provides a lot of scope for edge cases or growth to be effective. It allows the candidate to not blow a whole weekend on something for the sake of it but gives us obvious directions to take the conversation.

Communication skills seem to be held in much lower regard despite them being the key thing for effective day to day work. I can manage / handle working with someone who needs more time than a "rockstar" or hasn't memorized TAOCP if they'are able to communicate effectively. Outside of very specific roles, non-trivial software development is a team effort. It's usually extremely obvious within 15 minutes if a candidate genuinely gets what they've coded or is winging it.

Re: A Method I’ve Used to Eliminate Bad Tech Hires

#364

Post by kriro » Thu, Nov 10, 2016, 2:26 PM UTC

taneq wrote: post #111

usloth_wandows wrote: post #66

Earlier quoted context omitted.

If you can't code under pressure, you aren't a very competent programmer. Real world projects come with high pressure scenarios for software engineers. Code monkeys may be able to get away with low pressure, minimally impactful projects.

You're getting hammered for this, but for some jobs you're absolutely right. If you can't handle being put on the spot for a simple interview question, how are you going to go when a production line is down and it's costing your client $100k/hr, and the foreman's standing looking over your shoulder wanting to know when it'll be working? Not all jobs give you all the time in the world on a test server without interrup…

All these "yeah but imagine this horror scenario" (sorry to pick your example) descriptions sound like badly managed situations. Even in total failure situations like that...the foreman shouldn't be looking over your shoulder. The first step is to take a deep breath, assess the overall situation and get the programmers into their most comfortable mode to fix it. That can very well mean letting them think for 1h before starting doing anything. You can ignore that 100k price tag because that just leads to "just do something" thinking. It's very likely manically hacking away will actually end up making the situation worse and costing more.

Also...these situations can be trained for to certain degrees. There's well established precedents in crisis management. If you write code for a customer with a 100k/h downtime risk you should have done a very thorough risk analysis and have mitigation plans for most scenarios. The unknown unknowns that can happen are obviously the hard cases but you should be able to justify that these are going to be expensive no matter what. But even for these cases bricolage is trainable to a certain degree.

If you know there's 100k/h costs of failure you should also very specifically mention the fact that you are looking for these stress coping skills in the job description (and as such the interviewee should be prepared).

Re: A Method I’ve Used to Eliminate Bad Tech Hires

#365

Post by andy_ppp » Thu, Nov 10, 2016, 2:28 PM UTC

I liked the article but I'd rather people just come in and do some work rather than fitting things in (2 days in the office). I suppose with American holidays this isn't possible to take a couple of days but in Europe we get 25 days. I like the idea of paying for people's time too.

Probation is also important; I've used it when I don't like companies and I think companies should be willing to say to people it's not going to work out.

Three months is enough to know; people can look amazing on month 1 and lose their way. It is also important to never underestimate a manager who actually thinks through what they want from their staff and asks them to do it :-)

Re: A Method I’ve Used to Eliminate Bad Tech Hires

#366

Post by kriro » Thu, Nov 10, 2016, 2:33 PM UTC

shandor wrote: post #233

This seems like a pretty popular take on the interview process here on HN. However, there's one pretty glaring flaw that I've never seen discussed: if the interviewee can take the problem home, what prevents them setting up a hackathon with their friends at their place, and making the interview problem a team effort? A couple of knowledgeable friends can do wonders, and if you also prep with them a little you can pro…

Compared to "traditional interviews". It's probably well worth taking the risk of occasionally hiring someone like this. I'd say it's less likely to occur than someone who has more or less memorized some interview question book algorithms and happens to get asked the right ones.

Re: A Method I’ve Used to Eliminate Bad Tech Hires

#367

Post by stillworks » Thu, Nov 10, 2016, 2:36 PM UTC

flurdy wrote: post #349

blowski wrote: post #240

Earlier quoted context omitted.

Sounds like I'm completely the opposite of you! I'm fine with someone sitting next to me - I love pair programming. But cutting off internet access means no StackOverflow, no online documentation. The test should be very similar to normal working conditions.

Agree. Pairing up during the onsite follow up interview whilst you describe and extend your sample app is essential part of my recruitment preferences. That is how I expect people to work once they are hired so I expect candidates to be comfortable with it. Many are not, including me 10 years ago. But most are these days. I don't expect them to solve the problem perfectly during that time, or even at all. The importa…

> Agree. Pairing up during the onsite follow up interview > whilst you describe and extend your sample app is > essential part of my recruitment preferences.

When you say "describe and extend your sample app", where does this sample app come from ? Do you give the candidate a chance to work or go through the sample app on his own for some time before you pair ?

If that is the case then yes, I guess that is probably the correct way to do it.

However of late what I have experienced in general is that I have to go in, meet up people for the very first time in my life, they give me a problem and a laptop/computer/pairing station and a written description of the problem which I get maybe five minutes to assess and understand and then... have a go at it, while the strange (sometimes grumpy) developer sits next to me. If I go quiet for 5 minutes I get the "what are you thinking ?" question and then I have to talk while I write code at the same time !

Maybe it works for some or most of the people out there.

Not for me.

Re: A Method I’ve Used to Eliminate Bad Tech Hires

#368

Post by SonicSoul » Thu, Nov 10, 2016, 2:38 PM UTC

zachd1_618 wrote: post #49

This. 100% this. As many others are saying, I find that this is the most comfortable way for me as an interviewee to demonstrate that I do in fact know what I'm talking about. Put me in front of a room full of people and a whiteboard and throw something at me, and I'll freeze. Freezing in that situation and being a bad engineer are wholly separate things. Anecdotally, when I get one of these problems, I spent 20 minu…

i do love this idea but not sure if doing it remotely is a good idea. We do this in house because I am not sure how to be certain the candidate did not get help. I mean i believe people are generally honest but there will be cases when they are not, and I'd rather not find out 3 months after hiring them.

Also there are many indicators along the way, i.e. which parts the candidate got stuck at, did it take them 1 or 3 hrs to get to the same point (i.e. basic wiring of DB calls). I think all that would be lost if they did it on their own time.

Re: A Method I’ve Used to Eliminate Bad Tech Hires

#369

Post by shandor » Thu, Nov 10, 2016, 2:40 PM UTC

jaymzcampbell wrote: post #363

Peroni wrote: post #306

Earlier quoted context omitted.

This is the primary reason that you shouldn't make hiring decisions based on the test/problem results alone. The interview problem should only serve to be a conversation catalyst. If they got some help with the problem, outsourced the problem or simply googled prepackaged solutions to the problem then they are going to have a really hard time talking through the context of how they solved the problem. What you're tes…

Totally agree, conversation catalyst is a great way to phrase it too. This is very much the approach I've taken having had very mixed outcomes from trying to do just one thing or the other. I find using a simple, 100% self contained task that should take a few hours and then using that to kick start discussion has provided the best way for us to hire and screen people. We've found using a task that is very simple to…

You and GP both bring up a really mind-opening view into this. "Conversation catalyst" indeed, sorry but I'm definitely stealing that one.

> Outside of very specific roles, non-trivial software development is a team effort.

Couldn't agree more, and I have to say I'm rather baffled that so few recruitment processes are fine-tuned for this. Or maybe I should say that the image one easily gets is so. I myself have had pretty well balanced interviews that also tried to assess things like this, but I've always kind of considered myself just lucky.

When one takes your points into consideration, I can definitely see how having the take-home assignments offer value above the usual whiteboarding+bullshit bingo.

Re: A Method I’ve Used to Eliminate Bad Tech Hires

#370

Post by matwood » Thu, Nov 10, 2016, 2:41 PM UTC

shandor wrote: post #233

This seems like a pretty popular take on the interview process here on HN. However, there's one pretty glaring flaw that I've never seen discussed: if the interviewee can take the problem home, what prevents them setting up a hackathon with their friends at their place, and making the interview problem a team effort? A couple of knowledgeable friends can do wonders, and if you also prep with them a little you can pro…

> if the interviewee can take the problem home, what prevents them setting up a hackathon with their friends at their place, and making the interview problem a team effort?

Nothing, and that's fine. In fact we encourage candidates to use all resources on our take home interview test. I would probably be impressed if someone setup a hackathon to solve a rather simple take home problem.

A take home problem is simply another signal, and a jumping off point for discussions. If someone used some novel approach we'll discuss it and find out if they actually understand what they did.

The real surprising part is how many take home problems we have received that either do not compile, do not pass the test data we give, or look like the instructions were completely ignored. It ends up as a low effort FizzBuzz on our side.