How to conduct a good programming interview • Hacker News Board

Re: How to conduct a good programming interview

#131

Post by nolemurs » Mon, Sep 11, 2017, 2:12 AM UTC

throw2016 wrote: post #86

nolemurs wrote: post #53

Earlier quoted context omitted.

> I completely understand the need for these technical interviews and weed out obvious bad programmers and get experts on board but sometimes from a business point of view it just doesn't make sense. The thing is that the main goal of the technical interview is not to hire all good candidates. The main goal is to avoid hiring bad candidates. A large high paying company like Facebook has plenty of candidates to choose…

The desire for a 'good candidate' and the paranoia about making a mistake is sounding increasingly utopian. There is a certain nervousness and even a hint of hysteria about it. A bad hire is not the end of the world, and is easily corrected and one can't help feeling there is some magnification going on somewhere about hiring mistakes. There is near constant evaluation and feedback loops in most organizations. A 'bad…

> The desire for a 'good candidate' and the paranoia about making a mistake is sounding increasingly utopian.

I don't know where you're getting your 'perfect hire narrative' idea from; this is simple cost/benefit analysis. If making a bad hire is a lot more expensive than failing to make a good hire (and I'm pretty sure it is by a factor of at least several times - failing to make a good hire is really cheap), then you choose to make the cheap mistake of not hiring instead of the expensive mistake.

This is about as far from utopianism or looking for the 'perfect hire' as you can get. It's all about finding enough 'good enough' hires, while avoiding expensive mistakes.

Re: How to conduct a good programming interview

#132

Post by nolemurs » Mon, Sep 11, 2017, 2:31 AM UTC

CJefferson wrote: post #40

XCSme wrote: post #36

Interviews suck for both parties, a world without interviews would be a better world. Why can't we just hire someone based on his experience and projects he previously worked on? You can have a first month as a "trial" where both parties can cancel the contract. Why interviews suck is because they are very, very biased and subjective and also not a good way to estimate the actual performance of a candidate. Say no to…

I'm sure most businesses would love that situation, but for employees it would require you quit your current job, but have a good chance of being fired after a month at your new job. I imagine young employees would be happy (I did a bunch of short-term contracts myself), but once you have a mortgage and kids, it's nice to be a little more certain about your new job, before quitting your old one.

> I imagine young employees would be happy (I did a bunch of short-term contracts myself), but once you have a mortgage and kids, it's nice to be a little more certain about your new job, before quitting your old one.

And just to make this really explicit - this means that a company with this hiring practice would have a very hard time hiring experienced competent engineers. If I were looking for a job, I'd have lots of options, and I would not waste time on a company that demanded this.

Re: How to conduct a good programming interview

#133

Post by tptacek » Mon, Sep 11, 2017, 2:59 AM UTC

mahyarm wrote: post #122

tptacek wrote: post #67

It's good to think carefully about how you interview candidates. Most of the ideas in this post are good. You should definitely let candidates type answers on computers. You should definitely work to put them at ease, in an environment that approximates their actual working environment. But really, this is window dressing. The problem is that technical interviews just don't work reliably. We have better ways to quali…

Is there a case study somewhere for such an interview? Like a description or a video or such? Also how do you deal with the standardized interview being published? As in 'company X' uses a live coding exercise and they ask you to do X in a succession of changes. It would quickly come out for most larger companies.

You're smart people. I'm serious. For any of these types of concerns, you will come up with reasonable answers. My only advice is: don't overthink it. Solve problems when you know you're going to need to solve them, but err initially on the side of making things less onerous for candidates.

Re: How to conduct a good programming interview

#134

Post by Clubber » Mon, Sep 11, 2017, 3:09 AM UTC

nolemurs wrote: post #53

thiscatis2 wrote: post #4

So reading over some of the questions posted on technical programming interviews I must say that I would definitely fail such an interview without studying for it for a month first. Having recently discussed job interviews of ex-colleagues that went to EBay, Facebook, Google, etc.. I wouldn't even pass the whiteboard test. However I'm shipping scaleable API's used by web and native apps, using Continuous Integration…

> I completely understand the need for these technical interviews and weed out obvious bad programmers and get experts on board but sometimes from a business point of view it just doesn't make sense. The thing is that the main goal of the technical interview is not to hire all good candidates. The main goal is to avoid hiring bad candidates. A large high paying company like Facebook has plenty of candidates to choose…

>The cost of failing to hire a good engineer is small - they can just take the next guy. The cost of hiring a bad engineer is large.

This is absolutely and completely backwards. The cost of hiring a bad engineer is small. You can always fire them. The cost of failing to hire a good engineer is enormous. You will never get a chance to hire them again, and probably all of their friends.

Re: How to conduct a good programming interview

#135

Post by blitmap » Mon, Sep 11, 2017, 3:24 AM UTC

nolemurs wrote: post #53

thiscatis2 wrote: post #4

So reading over some of the questions posted on technical programming interviews I must say that I would definitely fail such an interview without studying for it for a month first. Having recently discussed job interviews of ex-colleagues that went to EBay, Facebook, Google, etc.. I wouldn't even pass the whiteboard test. However I'm shipping scaleable API's used by web and native apps, using Continuous Integration…

> I completely understand the need for these technical interviews and weed out obvious bad programmers and get experts on board but sometimes from a business point of view it just doesn't make sense. The thing is that the main goal of the technical interview is not to hire all good candidates. The main goal is to avoid hiring bad candidates. A large high paying company like Facebook has plenty of candidates to choose…

This leads me to think a good technical interview will identify people who strictly fail all or a large majority of the problems posed.

Someone who you would want to consider is someone who can reason and navigate most of the technical problems put forward - and it would certainly be great to have someone who can solve them all.

I like the previous responder who said people skills/communication and time management are important. Regardless of if a person can solve a problem or not, I'd want them to identify things to discuss or be able to deliver a solution at the end of the allotted time for a question. I want deliverables. You can't move forward without feedback.

Re: How to conduct a good programming interview

#136

Post by Clubber » Mon, Sep 11, 2017, 3:25 AM UTC

Goopplesoft wrote: post #29

> 5 minutes of resume discussion > 45 minutes of coding As anyone else found that a good resume discussion is often much better than the coding component? I've concluded that implementation difficulties, decisions made (tradeoffs, technologies, etc.) and the collaborative environment around projects, are much better signals than the code part of my interviews. If you've dealt with a broad range of tech and can ask th…

Absolutely. If a person can't tell good from bad with that, they shouldn't be interviewing.

Re: How to conduct a good programming interview

#137

Post by Clubber » Mon, Sep 11, 2017, 3:29 AM UTC

pnw_hazor wrote: post #111

There is no reason to haze potential employees. Just fire them if they don't work out. You set expections by telling them up front they are on probation and that they will be fired if they fail to live up to their resume. Some of the worst programmers I ever worked with could pass hazing interviews like a champ. Whereas some of the best would refuse to step foot in companies with a reputation for hazing their prospec…

That's a funny term to apply to this type of interview process, but it fits. Kudos.

Agree on the invalidity of technical interviews. We hired a guy who correctly answered every question I asked, but he could never ship a product. He always got distracted by silly things. He was great at solving tough little problems, but never could grasp the big picture.

Re: How to conduct a good programming interview

#138

Post by [deleted] » Mon, Sep 11, 2017, 3:37 AM UTC

tptacek wrote: post #67

It's good to think carefully about how you interview candidates. Most of the ideas in this post are good. You should definitely let candidates type answers on computers. You should definitely work to put them at ease, in an environment that approximates their actual working environment. But really, this is window dressing. The problem is that technical interviews just don't work reliably. We have better ways to quali…

[deleted]

Re: How to conduct a good programming interview

#139

Post by skewart » Mon, Sep 11, 2017, 3:54 AM UTC

tptacek wrote: post #67

It's good to think carefully about how you interview candidates. Most of the ideas in this post are good. You should definitely let candidates type answers on computers. You should definitely work to put them at ease, in an environment that approximates their actual working environment. But really, this is window dressing. The problem is that technical interviews just don't work reliably. We have better ways to quali…

> Rather than trying to read subjective, noisy signals from in-person interviews, give candidates a small battery of work-sample tests. These can be bug-fixes, small features, diagnostic challenges, or even specification writing assignments.

I agree that work sample interviews are a huge step in the right direction.

Recently though, I've been thinking about taking things even further: instead of giving sample projects, why not give candidates actual work that you need done, and pay them for it, like you would a contractor? Sample projects are inevitably going to be somewhat contrived, and they'll never be evaluated in quite the same way actual code submitted in a PR will be.

This approach lets the candidate and the company "date" for a while, letting each see how the other one actually works, before they decide to tie the knot of full-time employment. I think it's the most natural way for professionals to get to know each other, build trust, and develop well-informed opinions.

Of course there are plenty of practical logistical challenges, but it does seem like a freelance-to-full-time process could lead to better outcomes all around.

Re: How to conduct a good programming interview

#140

Post by tptacek » Mon, Sep 11, 2017, 4:04 AM UTC

skewart wrote: post #139

tptacek wrote: post #67

It's good to think carefully about how you interview candidates. Most of the ideas in this post are good. You should definitely let candidates type answers on computers. You should definitely work to put them at ease, in an environment that approximates their actual working environment. But really, this is window dressing. The problem is that technical interviews just don't work reliably. We have better ways to quali…

> Rather than trying to read subjective, noisy signals from in-person interviews, give candidates a small battery of work-sample tests. These can be bug-fixes, small features, diagnostic challenges, or even specification writing assignments. I agree that work sample interviews are a huge step in the right direction. Recently though, I've been thinking about taking things even further: instead of giving sample project…

There are all sorts of problems with this approach.

Contract software development --- relatively short projects with no up-front commitment to long-term work --- is, when sold and delivered competently, much more expensive than salaried software development. That's why people hire full-time.

The very best software developers know this. They're not as a rule especially good negotiators, but they're familiar with the market. For every firm offering them temp-to-perm work, there are 4 others competing over who can offer the most attractive immediate full-time offer.

That makes the "standard" recruiting pipeline for temp-to-perm companies an adverse selection problem. And, I believe, it's also often an exploitative one. People taking these temp-to-perm contracts aren't getting paid 2-3x their salaried rate to work on temp terms. But that's the lower side of what contractors demand to accept the kind of risk we're talking about with these projects.

Really, companies that do temp-to-perm are telling the market, "we're so bad at qualifying candidates that we're going to fob the entire problem off on our candidates, and hope there are enough competent people with such poor negotiating skill in the labor market that we can get away with that indefinitely". For now, they're probably right --- although taking this pathway is, I think, doing damage to the long-term integrity of their team and processes. But I wouldn't bet on it.