How to conduct a good programming interview • Hacker News Board

Re: How to conduct a good programming interview

#141

Post by jon_richards » Mon, Sep 11, 2017, 4:17 AM UTC

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…

My favourite was an interview (in Java), where the interviewer said I needed to process some data (something abstract like a "record") and that I could assume I get my data in a "var". I asked what sort of data structure the variable held. He said "It's a var. You know what a var is, right?"

So many problems...

Re: How to conduct a good programming interview

#142

Post by linkregister » Mon, Sep 11, 2017, 4:29 AM UTC

nolemurs wrote: post #126

meggar wrote: post #125

Earlier quoted context omitted.

Your opinion is based on the assumption that your interview process yielded an accurate assessment of competence.

Well, sure. We're not talking sophisticated things here though. The exercises that I've formed this opinion from were closer to fizz-buzz than to data structures or algorithms questions. If it takes you 20 minutes to code something about as hard as fizz-buzz (on a computer, with internet access), and the code you have at the end is terrible, I feel pretty confident saying you're not an effective engineer.

Yet the Google and Facebook interview questions are decidedly not trivial fizzbuzz problems. They're more on the order of the second midterm of a 300-level algorithms class. This is not stuff that most 10-year engineers have in their heads.

I'm not commenting on your company's interview process; I'm merely affirming the earlier poster's claim that there is a serious issue with the Google interview process and its cargo-cult-followed successors (Facebook, et. al.).

Re: How to conduct a good programming interview

#143

Post by balls187 » Mon, Sep 11, 2017, 4:41 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…

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.

Re: How to conduct a good programming interview

#144

Post by balls187 » Mon, Sep 11, 2017, 5:06 AM UTC

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 problem without unnecessarily wasting resources)

3. Understandable (goes hand in hand with maintainable)

4. Maintainable (can be modified by another developer, or even yourself after a few months)

Coding on a computer can lend itself to all of these (no brainer there), but you lose a key aspect of whiteboarding that I think is really important--how a candidate approaches solving a problem.

Knowing how to implement merge sort, or memorizing every possible linked-list question isn't all that valuable--but having a concrete approach to tackling problems is, and I want to understand that process from my candidates. I want to know the design tradeoffs you make, how you think about optimization, how do you reason about constraints as you learn about them.

It seems that explaining your process while coding on a computer would be difficult to do without practice--and if you're going to practice, why not instead just practice whiteboard coding, which is how most tech companies interview.

Re: How to conduct a good programming interview

#145

Post by diggernet » Mon, Sep 11, 2017, 5:11 AM UTC

monkeywork wrote: post #83

diggernet wrote: post #37

Earlier quoted context omitted.

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.

are you suggesting that if you have "proven yourself " you should be able to skip the interview process?

I am suggesting that "Why not try and go on some interviews?" is a silly, and potentially offensive, thing to say in response to someone describing their difficulties with the interview process. Especially when discussing a field where there is considerable ongoing debate about the usefulness and sensibility of various common interview techniques.

Re: How to conduct a good programming interview

#146

Post by thaumasiotes » Mon, Sep 11, 2017, 5:23 AM UTC

tribythrowaway wrote: post #100

sillysaurus3 wrote: post #64

Earlier quoted context omitted.

Yeah, I'm a big fan of your approach. Unfortunately it seems quite difficult to get anyone to do it. Most companies have interview pipelines that are well-established and immutable, so only new companies are inclined to try it. And even Triplebyte unfortunately fell back on a combination of abstract coding tests and amorphous "cultural fit" criteria. It was a neat hack as a candidate to propose to the interviewing co…

Triplebyte's flaw is like that of many other take-home tests: they favor people who lied about how long it took. When I did it, I had to implement a regex parser. I knew intuitively that the state machine approach was best, but if I read up on state machines and coding them, I would bust the 3 hour limit, so I did the best I could to deliver something working within the three hours. Feedback: "Obviously the state mac…

The state machine approach can't handle perl-compatible backreferences (since true regular expressions can't use them), which apparently some people want. That's feedback you can defend yourself from to some degree.

When I implemented a regex parser for Triplebyte, the time limit was much longer than three hours, and I did use state machines. The feedback I got was "we thought you wrote a great, full-featured regex parser, but we need someone who comes off better in interviews".

Re: How to conduct a good programming interview

#147

Post by SmirkingRevenge » Mon, Sep 11, 2017, 5:26 AM UTC

Ezhik wrote: post #48

khc wrote: post #22

Earlier quoted context omitted.

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

I think that if somebody with 10 years of actual and relevant experience fails the interview process, the interview process has a problem.

It also depends on who you happen to be competing with for the position at the time.

To "fail" an interview might just mean you were their second choice, out of current applicants.

Re: How to conduct a good programming interview

#148

Post by jetru » Mon, Sep 11, 2017, 5:28 AM UTC

Clubber wrote: post #134

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

It's not easy to fire employees.

Firing employees can scare and stress other employees, create bad blood and criticism on job boards which will make it even harder to hire good employees. Firing might mean you have to still pay the employee for a few months. It might be hard to determine if an employee is a complete failure, which means you might have to give the employee a few months to maybe even a year if you want to accurately determine if they're not performing. It's not cheap at all.

Re: How to conduct a good programming interview

#149

Post by Apocryphon » Mon, Sep 11, 2017, 5:50 AM UTC

jetru wrote: post #148

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.

It's not easy to fire employees. Firing employees can scare and stress other employees, create bad blood and criticism on job boards which will make it even harder to hire good employees. Firing might mean you have to still pay the employee for a few months. It might be hard to determine if an employee is a complete failure, which means you might have to give the employee a few months to maybe even a year if you want…

California is an at-will state. Surely tech companies can learn to innovate their HR processes to create a transparent, professional, and optimal solution to remove a poor hire.

And maybe not all poor hires are created equal. In which maybe the cost of training up bad hire would be less expensive than firing them, and the opportunity cost of taking longer time in hiring a better candidate?

Re: How to conduct a good programming interview

#150

Post by nolemurs » Mon, Sep 11, 2017, 5:55 AM UTC

Clubber wrote: post #134

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 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 alternative hire. If you're paying a 6 figure salary with massive benefits like Facebook or Google, you usually have a long queue of qualified candidates to choose from. Maybe the next guy will turn out to be better than the guy you passed on.

> You will never get a chance to hire them again, and probably all of their friends.

I happen to know that Google gets lots of repeat applicants. They have an explicit "wait a year before reapplying" policy.

I really doubt many people who want to work for these companies decide not to because a friend didn't get the job. That's just sort of crazy.