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

31–40 of 188 posts

Re: How to conduct a good programming interview

#31

Post by Xoros »

Those white board stuff reminds me when I was a CS student in the beginning of the 90's in France.

We had our exams on paper. And believe me, writing LISP on paper, knowing if you forgot one parenthesis you got 0 point ("if I type it on a computer, it fails !"), was pretty and unnecessary stressful.

So I relate with candidate facing that. Dude, on your day to day work, you WILL have a computer to check those !

How can you decently check those skill on a white board ? I totally agree with what's stated in this post.

Re: How to conduct a good programming interview

#32

Post by morgante »

TomK32 wrote: post #30
morgante wrote: post #9

Earlier quoted context omitted.

I used to think that, but honestly after recently going through a job search I think it's untenable for most scenarios. As a candidate, I want to be able to interview with multiple companies simultaneously—if I had to do a trial week with each company, I'd never be able to get multiple parallel offers. There's also significant onboarding complexity which I hadn't factored in. One company had me do a trial period and…

pair programming should cut the startup time.

It would also substantially increase the cost of this interviewing method.

Re: How to conduct a good programming interview

#33

Post by [deleted] »

sillysaurus3 wrote: post #18
morgante wrote: post #9

Earlier quoted context omitted.

I used to think that, but honestly after recently going through a job search I think it's untenable for most scenarios. As a candidate, I want to be able to interview with multiple companies simultaneously—if I had to do a trial week with each company, I'd never be able to get multiple parallel offers. There's also significant onboarding complexity which I hadn't factored in. One company had me do a trial period and…

True enough, but it sounds like the above model isn't for you. It's for everyone who is talented but doesn't have the option to go interview with multiple companies simultaneously. Most devs are in that position. I'd much rather commit to a single company that I want to work at and do this process to put me ahead of the other candidates. But that's not a decision that everyone feels the same about.

[deleted]

Re: How to conduct a good programming interview

#34

Post by pcmaffey »

sillysaurus3 wrote: post #2

While there are a variety of ways you can conduct a programming interview, the goals typically are the same: Will the candidate be able to write working code if they join the team? Can the candidate discuss code and problems with the people they'll be working with? Can the candidate reason about arbitrary problems and constraints? Is the candidate someone we would enjoy working with? All of these can be solved direct…

Rather than working on a real issue, I'd recommend a made-up task/feature, modeled after something they might actually do. Just put it in a repo and share to all candidates. It shouldn't take more than half a day's work. Then the next round is all about the candidates presenting their work and explaining their thought process.

It's simulated, but exemplary of real work. And easily repeatable. (Also no need for NDA, etc.) Just requires a thoughtful engineer to develop the task.

Re: How to conduct a good programming interview

#35

Post by baddox »

GeneralMayhem wrote: post #26
baddox wrote: post #16

Earlier quoted context omitted.

I love interview horror stories! In my most recent job search, which was early this year, I debated with one interviewer whether checking for key existence in a hash was a constant time operation. I insisted it was, and the interviewer insisted otherwise with the same amount of conviction. That was just a small portion of an all-day onsite interview. After leaving, I was told they were looking for a more senior candi…

Could just be a terminology mismatch. Checking for hash existence should always be constant, but checking for key existence is generally only amortized constant (that is to say, not constant across all lookups) - he may have wanted you to talk about addressing schemes and degradation at high load factors?

There was no subtle argument. It only came up because I was on the whiteboard solving some simple word game that involved matching user input against a list of valid words (e.g. the Scrabble dictionary). When asked to explain the running time of the various operations, I said that we can store the dictionary in, well, a dictionary, and checking whether the user input is a valid word will be a constant time operation. The interviewer insisted, with no subtle argument about amortization or collisions or addressing, that this was in fact a linear time operation.

Re: How to conduct a good programming interview

#36

Post by XCSme »

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 interviews! If you like what someone did, hire him. You can't get to know a person after 1 or even 10 interviews, because the interview environment is totally different from the work environment.

PS: I have been interviewed by 14 different people at Google. I didn't get the job. The overall conclusion was that some interviewers loved me, my skill and my work, others didn't like me from the start or simply didn't care about me. Some of them had a good day so they gave a good "review" even though I made mistakes, some of them had a really bad day (one fell of the chair) and gave me a really bad review even though, related to the actual interview questions, I did really well.

(14 interviews = applied twice, 2 x (5 on-site + 1 online), and they also wanted 2 extra interviews to take a decision)

Re: How to conduct a good programming interview

#37

Post by diggernet »

EGreg wrote: post #20
jghn wrote: post #15

Earlier quoted context omitted.

This is something which has vexed me for ages. I would fail most contemporary software interviews. I personally don't view myself as a great developer but whenever I make comments like "I would fail most contemporary software interviews" people who have worked with me swear that I must be full of it. Perhaps they're just being nice. I'm pretty sure I'd fail the current software interview at my company, yet I remain g…

This may be like "approach anxiety" for when guys never strike up a conversation with a woman they are interested in because they think all women will reject them. Why not try and go on some interviews? How can you possibly know you will be rejected without even going on one interview? Do you think all companies are the same, and your competition is all prepared for whatever it is you imagine they are doing? You're s…

I believe your error here is "without even going on one interview". There are many developers who have proven their skills and abilities on the job, and also have a proven ability to repeatedly fail interviews. This is precisely why the developer interviewing process is such a hot topic here.

Re: How to conduct a good programming interview

#38

Post by baddox »

jerryr wrote: post #25
baddox wrote: post #16

Earlier quoted context omitted.

I love interview horror stories! In my most recent job search, which was early this year, I debated with one interviewer whether checking for key existence in a hash was a constant time operation. I insisted it was, and the interviewer insisted otherwise with the same amount of conviction. That was just a small portion of an all-day onsite interview. After leaving, I was told they were looking for a more senior candi…

Wouldn't that argument be easily settled by discussing the implementation of a hash table?

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.

Re: How to conduct a good programming interview

#40

Post by CJefferson »

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.

Post reply on HN