Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

On asking job candidates to code

philcalcado.com

Post reply on HN
Print view View original

161–170 of 524 posts

Re: On asking job candidates to code

#161

Post by jameshart »

jasode wrote: post #23
kasey_junk wrote: post #19

Earlier quoted context omitted.

> For a company like Google Inc who is more selecitve than Harvard University Nitpick, but I'd love to see a citation on that. Google, like every technology company on the planet (modulo a small error value) goes to great lengths to recruit and hires lots and lots of people.

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…

The fact they have to filter down from a large number of applications to a small number of roles doesn't say anything about how selective they are.

    SELECT TOP 1000 FROM resumes ORDER BY received_date
will produce 1000 job offers but speaks nothing to selectivity.

Re: On asking job candidates to code

#162

Post by markbnj »

philbarr wrote: post #77
Tunabrain wrote: post #9

> As brain-dead as I was after eight hours at my project, [..] Is giving out an 8+ hour programming project as part of the application process really considered good hiring practice? If you apply to five jobs, you're expected to spend an entire unpaid work week writing code that doesn't benefit anyone? If a company receives 20 applicants, their ideal candidate selection wastes a collective work month? I don't really…

I got laid off recently and was applying for all the jobs I could find. So I had to do a bunch of these programming projects. I don't mind them per-se, but it takes so long to do each one and you have to be ultra-clean with each one. I don't think companies take into account that you might not have that much free time. It's particularly stressful when you don't get through. On pair programming tasks, I had a pair pro…

>> The best process was the one where I finally got a job. We talked on the phone for an hour and a half and by the end you could just tell we had that, "developer bond". His approach was the best I'd seen. He just talked through some of the problems he had, I proposed solutions and we talked through pros and cons. He treated me as an equal from the start. After that we had the face-to-face HR questions (how do you resolve conflict, etc.) which they have to ask because it's a big company, and another one with another manager but by then it was pretty much a done deal.

I've had the same experience, and I absolutely agree. Just about all my best interviews were with someone where we just hit it off and talked deep tech for an hour. On most of these we had to consciously cut the conversation off because we went long. I don't think that, when this sort of interaction occurs, you know the person is going to be good at writing production code. But at least you do know they're the "sort" of person you would expect to be good at it, and frankly none of the other methods discussed do a better job at providing that assurance.

Re: On asking job candidates to code

#163

Post by jameshart »

kejaed wrote: post #123
otabdeveloper1 wrote: post #103

Earlier quoted context omitted.

> ... and even told me he thought I was a better programmer than him. Probably that's exactly why you were ignored. The guy was scared of competition. (Maybe they were looking for a tech lead and he felt threatened by your expertise.)

A's hire A's and B's hire C's. http://www.hrdusa.com/As_hire_As.html

And since everybody knows they're an A, the only explanation for a 'no hire' decision must be that the interviewer is a B.

Re: On asking job candidates to code

#164

Post by sarciszewski »

mtberatwork wrote: post #99
CiPHPerCoder wrote: post #11

Earlier quoted context omitted.

The problem is: Writing good resumes and having a lot of experience with programming is a good heuristic for "experience" and "knows how to play the game" but not meaningfully useful for "excellent at programming". Work-sample tests measure the latter. A worker's experience is a heuristic for programming skill, but a heuristic of a heuristic is like an average of a set of averages: Useless.

> Work-sample tests measure the latter. I think that's debatable. The quality of your measurement is then simply a function of how well your tests are in the first place. Do you really think giving a person FizzBuzz is any kind of accurate predictor of future success at a job?

(Switching back to my old account because rate limits.)

I wouldn't ever use something like FizzBuzz to assess a candidate. It would be more of "here's a mostly finished sample application with a corresponding SQL file, add this feature (e.g. a search bar for a blog) and fix any (intentionally introduced) security bugs you find".

They would be evaluated based on how successfully they complete the main task, and if they have an eye for finding/patching vulnerabilities, that's a bonus that can be used as a secondary selector if a lot of candidates pass. If no one does, it won't be used against them.

That's how I'd approach it, personally. Something specific to the kind of work we're doing, but abstract enough to be approachable without a lot of insider knowledge.

Re: On asking job candidates to code

#166

Post by burgessaccount »

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 think there is a fundamental incentives problem in hiring - employers don't have a strong incentive to treat candidates well, because either they won't need to hire again soon, or they will be trying to hire someone who really wants a job who will forgive them for bad treatment. It's a good argument for moving to a recruiter model - companies have a stronger incentive to treat recruiting companies well if they want to keep having top talent referred to them. (This idea is spelled out in this post from a while back: http://blog.hireart.com/is-it-time-to-centralize-hiring/)

Re: On asking job candidates to code

#167

Post by dominotw »

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've noticed that your github profile doesn't even get looked at until you jump through all the standard phonescreen/homework hoops.

Even after than many interviewers look at your resume like 10 minutes before the interview there is no chance that they would read through your code on github. github as your resume is overrated.

I am curious to know if people hire or get hired purely based on their github profile without a technical interview.

Re: On asking job candidates to code

#168

Post by vonmoltke »

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…

Finally, some validation that my interpretation of their process is not insane.

One thing that really rustles my jimmies is the constant assertion that "false negatives are (effectively) free". I think Google and the companies who hire like them seriously underestimate how much this costs them, both the direct costs of spending so much to ultimately reject people and the indirect costs from the work that is not getting done or being foisted on another overloaded engineer.

Re: On asking job candidates to code

#169

Post by JoeAltmaier »

vonmoltke wrote: post #168
tptacek wrote: post #126

Earlier quoted context omitted.

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…

Finally, some validation that my interpretation of their process is not insane. One thing that really rustles my jimmies is the constant assertion that "false negatives are (effectively) free". I think Google and the companies who hire like them seriously underestimate how much this costs them, both the direct costs of spending so much to ultimately reject people and the indirect costs from the work that is not getti…

The root issue is that, the costs of bad hiring are even higher than that. For a rapidly-growing company bad hires can snowball into a bad organization.

Re: On asking job candidates to code

#170

Post by im_down_w_otp »

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 to N-number of Minnowboard Max devices. Among other things.

If you asked me to do homework to prove to you that I can "program", I'd have a brief discussion with you about how misguided that seems, thank you for your time, and walk away.

I mean fully "hundreds of connections" to a socket pool? Are you serious? If I submit a solution that can do "hundreds of thousands of connections" that includes QuickCheck tests for your protocol and my implementation, Ansible scripts for deployment and orchestration, and a Makefile that builds it, tests it, bakes it into a unikernel, and drives the Ansible scripts to push it out and start the end-to-end load test, do I get to be CEO or something?

Why is tech hiring so full of strange, meaningless obstacle courses? Do we just collectively not have better ideas?

Post reply on HN