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

21–30 of 188 posts

Re: How to conduct a good programming interview

#21

Post by ThrowawayR2 »

wjossey wrote: post #6
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…

I also agree. As someone who has recently co-founded a startup, this is something my co-founder and I have spent a lot of discussing and exploring. My personal experience with this style of interview was that it really helped me to personally demonstrate my abilities. I was interviewing at a startup in San Francisco in 2012 who wanted me to do a quick version of "battleship" as part of their hiring exercise. I propos…

> They needed to "benchmark" me against other candidates, and the only way to do that was with a consistent "test".

If your employer were ever sued by a candidate for discrimination and it came to light that you had received different treatment than other candidates, some very uncomfortable questions regarding the reason would be asked in the courtroom. An unfortunate bit of fallout from the litigious environment we live in today, but it is what it is.

Re: How to conduct a good programming interview

#22

Post by khc »

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…

As a counter example, I also have about 10 years of experience, but never studied for interviews. On average I pass about 50% of the interviews at companies big and small (ex: passed Google, failed Facebook). I think people often looked at questions and think "there's no way I can do them", but many times you can get some hints and use enough first principles to do well enough.

Individual questions are often bad indications of quality but interviews often consist of 4-5 or even more questions and in aggregate they do say something about the candidate. Some companies do require candidates to pass all the questions and that's a different problem.

Re: How to conduct a good programming interview

#23

Post by edem »

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…

While you can get away with only basic algorithmic skills and I also agree with your points about being able to ship/talk to users/etc I think that having decent algorithms & data structures skills is essential for a developer. For example I have worked on projects where people were not able to ship a product for a year with 10 people and our new 3-man team shipped within 6 months just because we figured out that an algorithm solves the problem. You just can't do well in some contexts when you don't have the ability to figure out whether the problem you are struggling with has a well-known solution. I think it all boils down to having at least a decent ability in all areas (like product management, soft skills, math, etc) involved in order to be able to be productive in all environments.

Re: How to conduct a good programming interview

#24

Post by kudokatz »

wjossey wrote: post #6
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…

I also agree. As someone who has recently co-founded a startup, this is something my co-founder and I have spent a lot of discussing and exploring. My personal experience with this style of interview was that it really helped me to personally demonstrate my abilities. I was interviewing at a startup in San Francisco in 2012 who wanted me to do a quick version of "battleship" as part of their hiring exercise. I propos…

It's also important to make sure people are well-rounded. If one can tweak an architecture to put a queue in the right spot, she/he may still be the person that cannot properly implement simple concepts like "separation of concerns" or forgets input validation or security checks.

At the end of the day, with start-ups I really value that mix of system and hands-on code. Without initial hires having both, it's harder to build a solid system while iterating so quickly. Amazing people skills are also key.

Over-leveling and bad hire situations are no good for anybody.

Re: How to conduct a good programming interview

#25

Post by jerryr »

baddox wrote: post #16
kevmo314 wrote: post #5

> If you ask the candidate the define the requirements for the task you're going to give them, you can't be surprised if the candidate imagines a use case with entirely different requirements from what you expected! This section really resonated with me. I've had a few interviews where I came up with a different answer than what the interviewer expected and this resulted in a lot of tension, as the interviewer assert…

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?

Re: How to conduct a good programming interview

#26

Post by GeneralMayhem »

baddox wrote: post #16
kevmo314 wrote: post #5

> If you ask the candidate the define the requirements for the task you're going to give them, you can't be surprised if the candidate imagines a use case with entirely different requirements from what you expected! This section really resonated with me. I've had a few interviews where I came up with a different answer than what the interviewer expected and this resulted in a lot of tension, as the interviewer assert…

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?

Re: How to conduct a good programming interview

#27

Post by gaius »

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…

They're compensated for their time, of course.

Taking on paid work for another company, possibly a competitor, would put nearly anyone who did so in breach of their contract with their current employer, as well as complicating their tax situation. Not to mention the vacation time they would be burning on it. You will only be able to hire freelancers or people currently unemployed by this method. Do candidates set their rate, or is it just a token amount?

Re: How to conduct a good programming interview

#28

Post by HugoDaniel »

Here is how to do a good coding interview if you are a recruiter:

1. Do your homework: know what projects drive the interviewee (what kind of things she likes to code, what recent projects has she been involved in), make sure they are a match for your company projects and goals

2. Ask the interviewee for a git repository and take a careful holistic look at it (commit messages and code, timespan, branches, merges etc...)

3. Go for a 2h lunch with the interviewee in a relaxed environment to check speak communication skills (talk about whatever you think is interesting, if you can't have or don't know how to have 2h lunches you shouldn't be interviewing, check your life first and learn how to enjoy it before doing interviews).

4. Stop asking programmers to write code in 40 minutes. Learn how to respect before expecting respect in return, if you didn't take the time to read through their code repositories then don't ask for a 40 minute code problems.

Re: How to conduct a good programming interview

#29

Post by Goopplesoft »

> 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 the right questions, it's relatively easy to get a strong signal from a candidate by having a deep discussion on their work on prior projects. Both are needed and very useful.

Re: How to conduct a good programming interview

#30

Post by TomK32 »

morgante wrote: post #9
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…

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.
Post reply on HN