How to conduct a good programming interview • Hacker News Board

Re: How to conduct a good programming interview

#41

Post by vitus » Sun, Sep 10, 2017, 6:22 PM UTC

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…

> asking the candidate if they'd be comfortable doing an actual task on the actual codebase, having them sign an NDA, and then giving them a bugfix to perform. They're compensated for their time, of course.

At Google, we call these internships.

Well, more or less -- there are restrictions regarding enrollment in a degree program, the work is for a fixed duration rather than for a fixed scope, etc. But the goal from the company's perspective is largely the same.

I'd be surprised if internships at other companies in the sector don't serve the same purpose.

(obligatory disclaimer about how these are my opinion's, not the company's, etc etc)

Re: How to conduct a good programming interview

#42

Post by amriksohata » Sun, Sep 10, 2017, 6:23 PM UTC

For me I have interviewed many people with a technical test, that was the easiest part i.e determining their competency. The hardest part is figuring out what their work ethic is, can they pull their own weight and will they cause friction in a team, sadly you only find that out often AFTER hiring them.

Re: How to conduct a good programming interview

#43

Post by nsxwolf » Sun, Sep 10, 2017, 6:34 PM UTC

edem wrote: post #23

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…

You can have decent algorithm skills and not be able to demonstrate that in an interview environment. You get more than 20 minutes in the real world and you're allowed to do research.

Most algorithms that developers will commonly need to use already exist and the skill is not developing algorithms but recognizing which to use and when. Understanding it enough to adapt it to specific needs. That's not the skills interviews test for.

Re: How to conduct a good programming interview

#44

Post by morgante » Sun, Sep 10, 2017, 6:37 PM UTC

Xoros wrote: post #31

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

No good interviewer is grading whiteboard coding on whether you forgot a parenthesis or semicolon.

Re: How to conduct a good programming interview

#45

Post by kevmo314 » Sun, Sep 10, 2017, 6:40 PM UTC

baddox wrote: post #38

jerryr wrote: post #25

Earlier quoted context omitted.

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.

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.

Re: How to conduct a good programming interview

#46

Post by sillysaurus3 » Sun, Sep 10, 2017, 6:41 PM UTC

gaius wrote: post #27

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

In my case, I offered to do it for free. (It wasn't their idea to give me a task on the actual codebase.) Almost nobody would be fine with that, but I want to work there. The other option was to hope that none of the other candidates seemed like a better choice. It's good to lock in an opportunity.

Perhaps it's unworkable in the general case. That would be unfortunate; it's the most effective type of interview.

Re: How to conduct a good programming interview

#47

Post by walshemj » Sun, Sep 10, 2017, 6:46 PM UTC

vitus wrote: post #41

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…

> asking the candidate if they'd be comfortable doing an actual task on the actual codebase, having them sign an NDA, and then giving them a bugfix to perform. They're compensated for their time, of course. At Google, we call these internships. Well, more or less -- there are restrictions regarding enrollment in a degree program, the work is for a fixed duration rather than for a fixed scope, etc. But the goal from t…

doesn't work for those not still at university and there are strict rules in the USA about the role of an "internship" its meant to educate the intern not be a source of cheap labour

Re: How to conduct a good programming interview

#48

Post by Ezhik » Sun, Sep 10, 2017, 6:46 PM UTC

khc wrote: post #22

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

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

Re: How to conduct a good programming interview

#49

Post by Jabbles » Sun, Sep 10, 2017, 6:48 PM 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…

It can also depend on whether you count the O(k) time needed to hash a string of length k.

Re: How to conduct a good programming interview

#50

Post by njovin » Sun, Sep 10, 2017, 6:51 PM UTC

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…

As a hirer at my current company I would love to end interviews but far too many candidates have resumes that look impressive but they then fall short on pretty basic code scrutiny. The ease of appearing competent due to previous successes (whether by team support or outright luck) make interviews a necessary evil.

You would be amazed the number of candidates we get with solid work history who submit code samples containing red-flag issues like SQL injection vulnerabilities. We always provide helpful feedback and politely decline these hires (we are a small time and we all learn from each other but I can't start off a senior-level hire who doesn't understand the basic web security) only to find out that they've been placed at some other company for their sought-after senior/level salary.