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

91–100 of 188 posts

Re: How to conduct a good programming interview

#91

Post by [deleted] »

tptacek wrote: post #69
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…

I think asking candidates to do "real" work is bad for a bunch of reasons: * It's intrinsically exploitative, even when compensated, because real work done under similar terms is paid far more highly than prorated salary (it also does weird things to salary negotiation, by extracting an up-front concession on rate). * It requires different candidates to work on different problems, which means you're not getting a rel…

[deleted]

Re: How to conduct a good programming interview

#92

Post by HugoDaniel »

jonathankoren wrote: post #84
HugoDaniel wrote: post #74

Earlier quoted context omitted.

Well the .2 "Ask the interviewee for a git repository" can be a private repository. It is a very hard problem to solve if they have no visible code to show but it does happen in other areas. Imagine asking for a management candidate for the private e-mails he shared in certain tricky situations of previous jobs. Or even public e-mails. Or even to take 40 minutes to write in a whiteboard a team statement for a certain…

> Well the .2 "Ask the interviewee for a git repository" can be a private repository. If someone shares a private git repo, they should not be hired, and in fact should be fired from their current job, and possibly sued. (Think Anthony Levandowski sharing Google lidar designs as an example of his work with Uber.) This isn't promoting trust. This is a violation of trust.

Yes I agree with you but I was not making the point of sharing a repository you shouldn't share to a recruiter (I do own a few private repositories that I wouldn't mind sharing to recruiters).

My point was that seeing code is not as mandatory for a recruitment as we currently make it so. I gave the comparison to management but it happens even in engineering areas. It is worth to know your candidate before asking to write a solution to an air conditioning problem in a whiteboard in 40 minutes when applying to a mechanical engineering position. Specially if your company never solves air conditioning problems.

Re: How to conduct a good programming interview

#93

Post by daveFNbuck »

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?

The suggestion, which many experienced people also make, is that once you've proven your ability the interview shouldn't focus on that. Spending 5 hours asking about algorithms is a waste of time when you already know someone has the technical chops.

Re: How to conduct a good programming interview

#94

Post by vitus »

walshemj wrote: post #47
vitus wrote: post #41

Earlier quoted context omitted.

> 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

I never said anything about internships being a source of cheap labor. Please don't put words in my mouth.

While yes, an intern typically makes less than a full-time engineer, you have to realize that the intern reduces the productivity of the host engineer, who has to spend time training the intern, looking over the intern's work, and so forth.

The real value in the internship program is that it essentially creates a extended interview process after which we can evaluate the individual (given firsthand experience of how they operate in a work environment), and the individual can evaluate the company.

Re: How to conduct a good programming interview

#95

Post by johnvega »

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 wonder where companies or hiring managers can post their job openings that supports this hiring process sometimes called Trial Employment or Job Audition for Software Engineers. Looks like a great way to get the best hire and also prevent a bad hire, although it can only work for a very limited number of companies and candidates.

Re: How to conduct a good programming interview

#96

Post by ng12 »

alkonaut wrote: post #70
gaius wrote: post #27

Earlier quoted context omitted.

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…

I think it would be prudent for the interviewer to just say that "of course we will compensate for your time because this takes a couple of hours". If you happen to have a contract that forbids you from doing that, just say "Can't take any comp, I'm happy to do it for free". I don't think the key is compensation, but at least not assuming the subject will work for free. If you are the interviewer in that situation, g…

Unless your company was exceptionally unique in some way I'd probably just pass instead. It's awfully one-sided: you're just sending me some code and I'm supposed to invest hours on it. At least with an onsite interview our priorities are aligned: neither of us want to waste more time than we have to.

Re: How to conduct a good programming interview

#97

Post by jpatokal »

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.

Re: How to conduct a good programming interview

#98

Post by nsxwolf »

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 didn't do a technical interview at all for my last few jobs.

Re: How to conduct a good programming interview

#99

Post by alkonaut »

ng12 wrote: post #96
alkonaut wrote: post #70

Earlier quoted context omitted.

I think it would be prudent for the interviewer to just say that "of course we will compensate for your time because this takes a couple of hours". If you happen to have a contract that forbids you from doing that, just say "Can't take any comp, I'm happy to do it for free". I don't think the key is compensation, but at least not assuming the subject will work for free. If you are the interviewer in that situation, g…

Unless your company was exceptionally unique in some way I'd probably just pass instead. It's awfully one-sided: you're just sending me some code and I'm supposed to invest hours on it. At least with an onsite interview our priorities are aligned: neither of us want to waste more time than we have to.

Yeah we all have different taste in interviews, I'd much rather spend 2h working for free than writing som tree traversal or fib function on a whiteboard for ten minutes. Interviewing is hard.

Re: How to conduct a good programming interview

#100

Post by tribythrowaway »

sillysaurus3 wrote: post #64
tptacek wrote: post #60

Earlier quoted context omitted.

Almost. Instead of doing this, take an old set of bugfixes from the tree, 1-3 of them, give the same bugfixes to every candidate, and come up with a standard rubric for judging the fixes. (If it's an open source project, synthesize 1-3 bugs, using the history of bugs on the project as a guidepost). This is a "work sample test", and it's the gold standard for judging technical qualification. Firms should rely on them…

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 machine approach is better, which you didn't use. You're not qualified."

Guess I should have just lied and gotten placed like the ones who did.

Post reply on HN