On asking job candidates to code • Hacker News Board

Re: On asking job candidates to code

#191

Post by r2dnb » Tue, Mar 15, 2016, 4:29 PM UTC

jcadam wrote: post #89

A couple of months ago I did a 'homework' assignment for an interview (it involved writing a simple REST service in go, even though I have at least one personal project demonstrating exactly this skill -- to an even greater degree -- in my github profile). During the phone-discussion after turning in the project, the mid 20-something lead developer couldn't find anything to nitpick (I could have) and even told me he…

I am sorry to hear that and I understand your frustration. As someone else said : Keep going. And do not doubt what you're worth.

You know, the thing is there's nothing new, you're just seeing today what the illusion of the paycheck prevented you to see before. Take this as an opportunity to move your life forward : no matter how exciting your next job is, give to yourself a deadline to bootstrap a SAAS business as a nightjob and have enough customer within 6 months to - at least - replace your salary.

Re: On asking job candidates to code

#192

Post by gorpomon » Tue, Mar 15, 2016, 4:29 PM UTC

On paper (or blog), having a candidate write code for an interview is better than a BS whiteboard session.

In practice, it means I spent 20 hours on my last piece of sample code I submitted to a job I was excited about. Only to be told no thanks, with the feedback of:

"Your app meets what we spec'd out, but it differs from our style."

And to be clear, after I repeatedly asked for what they were looking for in this code, they replied "we are purposely providing nothing except functional requirements to see what you produce".

I could have given them exactly what they want, but I guess they'd rather just wait and hope that someone magically codes the same way they do?

Honestly I should have billed them after that.

Re: On asking job candidates to code

#193

Post by pyb » Tue, Mar 15, 2016, 4:31 PM UTC

tptacek wrote: post #131

jasode wrote: post #129

Earlier quoted context omitted.

>No interviewing software developer prefers an extra 6 hours of on-site interview to an off-site coding challenge. Sure, Google/Microsoft have the legendary "6 hour" marathon interviews with multiple teams with lunch in the middle but for smaller scale of companies, they don't have bandwidth to mess around with all-day interviews. It's ~2 hours. In this thread, it shows I'm not the only one who prefers onsite whitebo…

This is just not true. I talk to interviewing developers every day, and very few of them are interviewing at Google. The final round of on-site interviews usually eats a whole day, and is preceded by a whole battery of time-wasting phone interviews, which themselves eat as much time as a coding challenge and often involve coding with someone else over the phone or Skype . There are companies that are not Google that…

Are they not only getting very desperate candidates ?

Re: On asking job candidates to code

#194

Post by ryandrake » Tue, Mar 15, 2016, 4:31 PM UTC

maxaf wrote: post #159

ryandrake wrote: post #149

Earlier quoted context omitted.

Often the "information sideband" is the very fact that the company decided to cut off all communication as a way to convey rejection. If they treat random people that way, how do you think they treat people who are obligated to be on their worksite every day? Companies: DON'T DO THIS! I, for one, actively discourage smart friends from interviewing at places that treat candidates like shit.

This is especially hilarious^W demoralizing when the same company continues to actively recruit across all available channels. Successive waves of aggressive recruiter spam from some of my past "dead silence" rejections continue to cause hilarity^W^W rub salt on the wound to this day.

Respond with "I'd love to start a conversation about this great opportunity, but I'm still waiting to hear back from you about the interview we did 6 months ago!" :-)

Re: On asking job candidates to code

#195

Post by aprdm » Tue, Mar 15, 2016, 4:32 PM UTC

herval wrote: post #156

The process I've seen working best to this day was at Pivotal Labs: pair for a half hour to one hour with 3 different people in the team you're being hired for. You get to measure everything, from communication skills to cultural fit. Perhaps pair on an internal tool, or even better, an open source project (in which case the candidate gets an extra incentive for not wasting their time). If you're dealing with too man…

I've interviewed there. Only two people I've paired with, one in the morning and other on after lunch. I had two problems:

* The 2nd guy I've interviewed with was completely non interested on doing it. He was checking the phone all the time and getting off and on. I felt so awkward because of his lack of interest.

* I didn't get _ANY_ feedback at all, just got refused. After 6hours in their office...

Re: On asking job candidates to code

#196

Post by jasode » Tue, Mar 15, 2016, 4:36 PM UTC

tptacek wrote: post #126

jasode wrote: post #23

Earlier quoted context omitted.

See my previous footnote about them receiving 1 million resumes to fill 1,000 slots. If that's true, it is more selective than any Ivy League university. Here's another one showing 75,000 resumes received in one week : http://www.sfgate.com/business/article/Google-gets-record-75... When you have the luxury to pick the best, from the best of the best, you don't have to follow the advice given by HN armchair quarterbac…

No. That's not how a market works. Google can in fact maintain high and consistent standards for incoming developers. But because their processes are so dysfunctional, they overpay to do it. And engineer headcount costs are a huge component of their business --- so much so that they've been accused of breaking the law to collude with other companies to avoid competition in hiring! Google is succeeding in spite of the…

>Google can in fact maintain high and consistent standards for incoming developers. But because their processes are so dysfunctional, they overpay to do it.

But there's no evidence that switching to self-paced work samples would cost them less. With Google's popularity, they'd get more false-positives from candidates that copied the code from widely disseminated previous projects. False-positives cost money.

Your medium size firm with smaller volume of candidates won't have that problem of increasing false-positives.

Sure, with whiteboard interviews, the rejected candidates (and even ex-Googlers) can write a "brain dump" blog with blow-by-blow algorithm questions but history seems to show that these don't work so well as cheating mechanisms.

What kind of work sample project could Google realistically design for 10000 programmers to complete? (It can't be as hard as "solve this Clay Millennium problem" or as easy as "reverse this string". Anything between those 2 extremes is trivial to copy to github.) How often do they need to redesign the work sample? What about objective "comparisons" which was touted as a feature of that method? What about the programmers that don't want to do the work sample? (They do exist!) Is there also a cost to filtering them out?

It's great you're really enthusiastic about work samples and want more companies to adopt it but I see no slam dunk evidence that they are the universal best method for every company.

Re: On asking job candidates to code

#197

Post by joantune » Tue, Mar 15, 2016, 4:42 PM UTC

"It turns out that most people would put together a Rails app with more lines on their Gemfile than lines of actual code they wrote. Worse"

- how is this worse then rewriting the wheel? write code only when you must

Re: On asking job candidates to code

#198

Post by jorgecurio » Tue, Mar 15, 2016, 4:44 PM UTC

jcadam wrote: post #89

A couple of months ago I did a 'homework' assignment for an interview (it involved writing a simple REST service in go, even though I have at least one personal project demonstrating exactly this skill -- to an even greater degree -- in my github profile). During the phone-discussion after turning in the project, the mid 20-something lead developer couldn't find anything to nitpick (I could have) and even told me he…

They want someone who uses asynchronous programming in coffeescript to build a blog and use shit load of preprocessors and if the library was just released on HN they expect you to use it in production and deal with it.

Don't do these take homework projects. Don't work for free.

Re: On asking job candidates to code

#199

Post by nobleach » Tue, Mar 15, 2016, 4:45 PM UTC

dominotw wrote: post #173

pyb wrote: post #171

Earlier quoted context omitted.

Same here, companies don't ever look at my Github code. I built up a portfolio partly in the hope to make future interviews easier, but it hasn't worked at all!

I have like 3 projects with > 1000 stars and they are used in production by atleast couple of people. But, noone gives a shit about that they would rather have me reversing a binary tree on a whiteboard.

I remember reading that comment about Google... even though a ton of people at Google use Homebrew. The question is, what would would you be writing at Google? Would you be reversing binary trees? Would you need to instantly know which sorting algorithm would be most efficient at the drop of a hat? or would you be building more tools like you already have. The one thing that isn't immediately clear from your GitHub is if YOU wrote the code and HOW you wrote the code. I'm not defending worthless practices like asking you all kinds of CS riddles that the interviewer doesn't even remember... but I am saying that there are reasons to test your ability to reason through a legitimate problem. Because of this, I am a huge fan of this style of interviewing: "We have a problem... tell us how you might approach solving this. What resources would you use? Why?"

Re: On asking job candidates to code

#200

Post by im_down_w_otp » Tue, Mar 15, 2016, 4:46 PM UTC

estefan wrote: post #185

im_down_w_otp wrote: post #170

Weird. I've created from scratch: new CRDT data-types for geospatial problems, new highly-available transaction patterns that provide useful causal history and atomic visibility, large-scale messaging platforms (400k ops/sec), high-throughput machine learning pipelines, lock-free lightweight-process mailbox implementations, and an end-to-end build pipeline for generating bare-metal rumpkernels to be parallel deployed…

Because there are a lot of shit candidates. You might know you're worth talking to, but try hiring and you'll see why people want to separate the wheat from the chaff.

I have tried hiring. Many times. As recently as yesterday.

Using a combination of (semi-)rigorous personality profiling (time constrained), and mapping the abstract problem domain of their prior work to the problems I actually have for them to work on, it's been possible to align new people with the work such that they're intrinsically motivated, and make sure all the bases are covered for the necessary roles (hacker, inventor, finisher, watchdog, etc.) to carry a very large greenfield project from start to finish.

I've never once given a cute riddle, puzzle, or coding challenge as a part of the interview process, and actively dissuade others from doing it as well.