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

51–60 of 524 posts

Re: On asking job candidates to code

#51

Post by cuillevel3 »

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've been looking into changing jobs and yes: it is a huge time sink. Traveling to interviews, being available for phone calls, preparing and researching... Especially the smaller companies are struggling to set up a good hiring process. I tried to discuss salary ranges before going into interviews to filter out some companies, but it didn't help. One recruiter put me on a one hour train ride, turns out there was some miscommunication about the job description..

However I really liked the Thoughtworks challenges and couldn't resist coding for eight hours. It's better than spending one hour on-site for a badly designed 'challenge'.

Re: On asking job candidates to code

#52

Post by afarrell »

One thing which I've wanted to see a company try is to give someone code to read and asking them to walk through how they would go about understanding it. I've done this once when I worked at MassChallenge and was trying to hire a more senior engineer to work above me and I felt like it gave me a good idea of his ability to talk through problems and work with others, but that was only one interview and I'd like to see a larger sample size.

Re: On asking job candidates to code

#53

Post by to3m »

CiPHPerCoder wrote: post #44
_ak wrote: post #38

Earlier quoted context omitted.

That's what probation periods are for. Use them.

What do you mean by probation periods? Something like... "Hi, I'd like to ask you to work for a very temporary contract with us so, if it doesn't work out, you have to scramble to find more work and maybe risk homelessness."

This is pretty standard in the UK. Your new full-time job is commonly effectively at-will for the first 3 months, and possibly more.

See, e.g., http://www.jobsite.co.uk/worklife/probation-periods-19677/

Re: On asking job candidates to code

#54

Post by emodendroket »

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, for one, am tired of processes that don't respect my time.

Re: On asking job candidates to code

#55

Post by LankyDataGeek »

jessegreathouse wrote: post #48

I think a coding test is the wrong approach. Typically a coding test is too simple to be meaningful, or too difficult to be practical. Instead I would have a Mock PR in a github style discussion forum. Have it be a contrived example of some things that could be improved or some things that could spark really good discussion. Give the mock PR link to the candidate and ask them to Peer review the code. Make the discuss…

This is a great idea!

Re: On asking job candidates to code

#56

Post by IanCal »

macNchz wrote: post #27
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…

The time involved in these things really can add up... I was recently asked to do a take home challenge that took a couple of hours to hack together, followed by several hours of nailing down edge cases due to the nature of the task. Then the company scheduled a phone call during which I thought we'd discuss the design decisions I'd made while working on the task. Instead, the interviewer had never seen the code I se…

Often these things are scored and ranked separately. Your phone interviewer will likely have scored you on various things, the score from your coding challenge will be taken as well, then everyone will sit down and discuss how people did and rule people in/out.

Re: On asking job candidates to code

#57

Post by patio11 »

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…

(Speaking in personal capacity here.)

There exists a continuum of hiring practices which place more or less burden upon candidates. I would encourage HNers with input into their company hiring practices to choose less burdensome approaches over more burdensome approaches, particularly when less burdensome approaches also yield additional signal about ability.

A thing you can expect to be asked in 2016: you can expect to be asked to have an on-site interview in a city you do not live in. (How many people will be asked to do this for the SFBA or NYC? Literally jumbo jets full, this week.) For some candidates, this will involve more than 16 hours on planes, a (minimally) overnight stay in a business hotel, and six solid hours of interviews in the course of an 8~10 hour day. This requires minimally 2~3 days of these candidates' lives.

Most companies keep "conversion rate between onsites and job offers" very close to their vest. To put it mildly: it is not guaranteed that if you're flown out you will get an offer.

If you are hypothetically designing your interview process, and you replace the onsite with even an excessively long project, that's a win. The project can be written at the candidate's own pace and schedules conveniently around their other obligations. They do not have to arrange child care, take off time from work, or make tradeoffs like "Do I do the project or do I attend a friend's wedding?"

If you fly across an ocean and start bombing an interview, that's a terrible result for everyone. If you happen to be doing a project and discover "Oh, wait a minute, I've really miscalibrated here: this is far above my level of expertise with $FOO and honestly if this is the character of the work then I'm not sure I want to do it", then you have an easy option: simply close the window and, maybe, send a two-sentence email to the person who you were talking to.

Smart use of projects as a filtering mechanism can minimize costs to candidates and the company of administering high-cost testing (e.g. onsites, long projects, etc) to candidates who will ultimately not be successful at receiving offers and/or defer the high-cost assessments until the anticipated chance of receiving an offer is "very high."

Re: On asking job candidates to code

#58

Post by ebbv »

I understand the appeal of having candidates write code as part of the application process, but in my view it's useless and worse, it will drive off some of the best potential candidates you could get.

First, why is it useless? Because it is an artificial and contrived exercise and not real work. Even if you design your requirements to mimic your real work environment, there's something key missing; the candidate has no knowledge of your team and your environment. How I would write code for my current team vs. how I would write code at any other job I've been at is different. You're basically asking the candidate to take a guess at what kind of paradigms your code reviewers like and what they don't like and hope it works out. One team might find use of closures smart and great, and another might find it unintuitive and adding unnecessary complexity. Your applicants have no way of knowing and just have to hope they write code your team likes.

On top of that, one contrived exercise is not a good way to get an idea of a persons' actual skill and knowledge. I'd much rather have a 30-90 minute conversation with someone where nobody writes any code than to review a contrived example. I get the appeal of the programming task, it can be done asynchronously and thus doesn't require any developer time until you go to do the review. But is it really saving you much time? Anyone who's code doesn't pass unit tests or any other automated level of screening wouldn't probably make it very far into a conversation either.

If I have an applicant spend 1-4 hours writing a code example I've had them use at least as much and probably more of their time for far less benefit than if I had simply called them up on Skype and talked to them about programming. The conversation will reveal not only a lot more to me about their actual skill set, but also their personality and how they might fit into my team. Now I realize teams doing exercises aren't skipping the conversation step, but I'm advocating for skipping the programming task step and going right to the conversation if someone's resume is solid and they can intelligently answer some basic questions (a handful of questions that should take no more than a couple minutes to answer, not an essay.)

Second, why would I say it drives off good candidates? Because I know a lot of really good developers (including myself) who skip any job posting that requires writing code as part of the application process. Why do I do that? Because it tells me the team behind this application is immature. They haven't yet gotten to the point in their careers where they realize these exercises are a waste of everyone's time. That means there's probably going to be a lot of other young dude bullshit in the team that I'm not interested in dealing with.

Re: On asking job candidates to code

#59

Post by robodale »

orng wrote: post #4

I really hate having to solve these kind of programming challenges. I've already sent you my CV, with references from former/current employers and co-workers. Call them up if you are worried that I'm lying on my résumé, don't waste my time by making me work for the chance of maybe getting a job as only payment. Doing multiple interviews already takes up enough of my time, seeing as I'm the one who has to commute to y…

Right with you buddy. I no longer accept coding challenges or even interviews that go over 30 min. I tell them my services are $150/hour. If you want me to do a 4-8 hour exercise for the privilege of interviewing further then make it worth my time...just like any other consulting gig I do.

Re: On asking job candidates to code

#60

Post by stutsmansoft »

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 personally would love this style of job screening.

I'm not at all worried about 8 "unpaid" hours.

Post reply on HN