Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to conduct a good programming interview

lihaoyi.com

Post reply on HN
Print view View original

151–160 of 188 posts

Re: How to conduct a good programming interview

#151

Post by Apocryphon »

nolemurs wrote: post #131
throw2016 wrote: post #86

Earlier quoted context omitted.

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 y…

What makes a bad hire? Couldn't a 60-70% hire be trained up, rather than expecting all of the candidates to be 90%?

Re: How to conduct a good programming interview

#152

Post by OJFord »

tvelichkov wrote: post #88
nolemurs wrote: post #68

Earlier quoted context omitted.

It seems unlikely to me that as a full time Facebook engineer Koum would have still had time to create a multi-billion dollar startup. It also seems unlikely to me that he would have been motivated to put in that work for an employer, or that Facebook would have given him the time or freedom necessary to do it. If he had been hired, he'd have probably been a fine engineer, but there's really no reason to think he'd h…

Are you saying that Facebook employees are not motivated to work? Or that now after he has been hired, he is not adding any value anymore? Facebook is a multi-billion dollar startup and its created by the people working there. So it may not be my favorite company, but I give respect to that, and the people working there. I can't say what's the skillset to be an effective engineer at a large company, but I do believe…

> Facebook is a multi-billion dollar startup

Where 'startup' is used to mean 'hip place to work', I gather?

Re: How to conduct a good programming interview

#153

Post by jonathankoren »

jpatokal wrote: post #97
jonathankoren wrote: post #87

I have to disagree with this trend of having people write code on a computer instead of a whiteboard. Sure, it mimics the real world, but in practice you spend a bunch of time dealing with crap about syntax errors, and argument order mismatch instead of dealing with the actual underlying algorithm. Even worse, you may end up with a candidate that realizes that there's probably a library that would be really useful fo…

Is doing interviews in an IDE and expecting fully functional code actually a thing? My company uses a simple text editor: perfection is not expected, and it's still way better than a whiteboard.

I can confirm that this is a thing at multiple companies. Instead of of testing the actual algorithm, you'll encounter such blasts from the past like: "Network Socket Debugging", "How The Fuck Does Java Read From STDIN?", and everyone's favorite, "Why The Fuck Did You Give Me Text Data In CSV Format?"

I have seen this go well exactly once. And they provided an environment with a working (albeit do nothing) scaffold along with test data. Also it was like a three hours in a room.

Re: How to conduct a good programming interview

#154

Post by walrus1066 »

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…

Problem is, these algorithm based reinventing the wheel exercises don't filter out bad candidates. Being good at these has no relevance in 99% of companies.

We give candidates a take home exercise which is a simplified version of our business domain. We look for clean, readable, well tested OO code.

We had to turn down a CS PhD because their solution didn't meet any of these criteria (no tests, for example).

Were we to do algorithm trivia instead, they would have passed with flying colours and we'd be burdened with unmaintainable code.

Re: How to conduct a good programming interview

#155

Post by skewart »

tptacek wrote: post #140
skewart wrote: post #139

Earlier quoted context omitted.

> 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 m…

You make a lot of good points. Temp-to-perm could easily turn into an adverse selection situation, and there is potential for it to get exploitive.

That said, I do think there is appeal for candidates in contracting for companies as a way to get to know the teams a bit better before deciding where to take a full-time offer. At least it's something I've been glad I've done at times, and wished I could have done at other times.

Plus, most developers are not the very best developers, and they won't have four competing offers after only a couple of weeks of job searching. For an awful lot of developers they'll need to spend hours prepping for interviews, working on take-home projects, going to onsites, and talking on the phone with hiring managers and recruiters. They spend a lot of time and effort for which they're not getting paid anything, and which is largely orthogonal to their actual work. When they do get a few offers they have to make a decision with limited knowledge of what working at each company will actually be like.

I dunno. I still think it would be awesome if job-seekers and hiring teams could get to know each other in some more natural and meaningful way than the feats of strength performed in today's interviews. Maybe temp-to-perm is too problematic though.

Re: How to conduct a good programming interview

#156

Post by rimliu »

balls187 wrote: post #144

Being a better interviewer is important. As stated, some types of questions aren't good judge of skills, like implement mergesort. If you can implement mergesort, you probably studied up for your interview. You're not testing anything, other than did the candidate care enough to study. Interviewing should test the candidates ability to write code that is: 1. Correct (solves the problem) 2. Efficient (solves the probl…

So do you want someone who is good at explaining how they are looking for the solutions, or someone who is good at finding the solution? For me personally approaching a problem never involves a whiteboard.

Re: How to conduct a good programming interview

#157

Post by lewisl9029 »

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…

For my first job-search out of school, I actually started off by accepting a temporary, fully-remote contract position for one of the first startups I was interviewing with at the time.

After a short 1 hour pairing session with their front-end lead, I was offered a choice between going through the full 1 day interview gauntlet onsite at SF to arrive at a full-time offer on the spot, or a 2 month remote contract to give us both some more time to decide if we want to proceed with working together full-time (the actual length of the contract was negotiable, I just went with 2 months because I felt that's about how long it'd take me to finish interviewing with all the companies I was interested in). They made it clear that I could continue to interview at other companies during that time frame, as long as it wasn't so disruptive that it impacted my quality of work, and that I should feel free to turn down the full-time offer at the end of the contract if I find a better offer elsewhere. I felt the latter option suited me better at the time, because it was still fairly early in my interview process, so I didn't have any offers coming up on the immediate horizon, and I was still definitely interested in exploring my options some more before deciding on my first full-time job. So I accepted it.

I had a blast working there for those 2 months, learned a lot, and among other things, completed a decidedly non-trivial addition to their app. At the end of the contract, they offered me a very generous full-time position, but I ended up taking a competing offer at my current employer instead. There was no hard feelings, and we parted on good terms.

I guess what I'm trying to say is, yes, temp-to-perm definitely isn't right for every candidate (or most candidates, for that matter), but it will give both you and the candidate much more confidence in the decision on whether or not to go full time than any interview process ever could, and there's nothing wrong with offering it as an alternative to the standard interview gauntlet and letting the candidate decide what's best for them.

You definitely have to come to terms with the fact that it's a 2-way street though, meaning you have to accept the risk that the candidate might find at the end of the contract period that it's no longer in their best interest to proceed with a full-time position at your company, and that they are free to act on that realization. Otherwise, if you try to place limits on that aspect of the arrangement, the only candidates who would likely accept it would be the truly desperate ones whom you were probably never interested in hiring in the first place. I for one certainly wouldn't have accepted the arrangement if I wasn't free to continue interviewing during the contract and free to turn down the full time offer at the end of it.

Re: How to conduct a good programming interview

#158

Post by lewisl9029 »

balls187 wrote: post #143
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…

Other than the pain of being rejected (or rather the lack of validation), where does this reliability problem manifest? Elite tech companies have no problem with the current implementation of technical interviews. Engineers whos skills range from Great to Mediocre don't have a problem finding a job. Software quality has generally improved or stayed the same.

> Engineers whos skills range from Great to Mediocre don't have a problem finding a job.

How are you defining "skills" in this case? "Skills" as in the skills needed to perform well in the traditional technical interview gauntlet?

If that's the case then you have a tautology on your hands.

And if not, then maybe it'd serve us better as an industry to try to find a better proxy than the traditional technical interview for whatever definition of "skills" we really want to optimize for.

Re: How to conduct a good programming interview

#159

Post by zaphirplane »

kevmo314 wrote: post #45
baddox wrote: post #38

Earlier quoted context omitted.

I discussed it briefly. My interviewer was unpersuaded, and the other interviewer in the room (who wasn't performing this interview) suggested we just move on. I believe the unconvinced interviewer was simply a very junior developer and an even more junior interviewer. He seemed quite nervous.

One of the worst interviews I've had the interviewer was not only similarly incorrect, but then afterwards proceeded to try to give me advice on interviewing skills, and how I should've "taken his hint" and been "more amenable to other answers". I probably would've been open to alternate answers if they were, y'know, factually correct.

Thinking you are awesome because you know the answer to a question you have prepared for and asked many times, is one of my minor irritant

Re: How to conduct a good programming interview

#160

Post by bryanrasmussen »

nolemurs wrote: post #150
Clubber wrote: post #134

Earlier quoted context omitted.

>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.

Firing is never fast or easy. It usually takes months to realize your mistake since it takes that long to get up to speed on a new job, And then you have to hire someone else, and get them up to speed. As a result, you're delayed by months, and out months of salary. Also, firing is terrible for morale. You really can't do it that often. Failing to hire a good engineer is only a big cost if you can't find a decent alt…

maybe, but if you trust your friend and he says the recruitment process sucked are you really going to want to go through it?
Post reply on HN