Live data from Hacker News

On asking job candidates to code

philcalcado.com

151–160 of 524 posts

Re: On asking job candidates to code

#151
post #147

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.)

> The guy was scared of competition. Or being moved down in the stack ranking and cut.

This is a great point. I wonder how many good candidates get rejected simply because an interviewer's bonus depends on him remaining the most talented person on the team?

Re: On asking job candidates to code

#152
post #68
post #25

Earlier quoted context omitted.

We ask candidates to pick a work sample of something they already have, if they have one they can provide. If they don't we give them a relatively painless coding test instead. It's not perfect, it'd be great if everyone could have a work sample but as you say that's just not the world we live in.

I appreciate this approach. I'd love to be more active with outside-of-work projects, but my days are usually already full. And I can't provide a lot of code samples because the majority of my work is IP.

This is true for most good people at big companies. Your day is already 60 hours long, and your company forbids (via IP ownership) coding outside of work. I fear that most of the interview approaches pointed out in this thread select against people who are already successful at well-regarded companies. Don't you want people like this in your interview funnel?

Re: On asking job candidates to code

#153

Earlier quoted context omitted.

I, for one, am tired of processes that don't respect my time.

Would you rather Some Co. just hire you and try you out for a few months simply based on your resume?

It doesn't have to be one or the other. There is a broad spectrum between "try out based on resume" and "6 hour whiteboard hazing session".

Re: On asking job candidates to code

#154
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 never heard from them again and all of my attempts at communication were ignored."

Unfortunately, this seems to be par for the course these days - I have a lot of friends who complain about the same thing. It's just indicative of a total lack of professional courtesy, and you should consider yourself lucky that you didn't end up working with people like that.

Re: On asking job candidates to code

#155
post #116
post #108

Earlier quoted context omitted.

> Taking up hours of a candidate's time is excessive, but it seems reasonable to ask for some demonstration of your ability, when so many candidates simply cannot code. So why not simply ask technical questions during an interview? I'd think you'd be able to determine whether or not someone know what he is talking about by simply asking him a few questions on the matter.

Because there are plenty of people who can regurgitate things but not be able to do much with it. I've seen it with CS grads from good schools, its disconcerting and confusing.

Why are you asking "fact regurgitation"-type technical questions? I prefer to ask open-ended ones, questions that start a discussion that will quickly determine if the candidate really understands what they are saying. It also reveals correct but rigid thinking, something I would like to generally avoid but that doesn't always come up in a coding exercise.

Re: On asking job candidates to code

#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 many candidates, issuing a simple 1-hour coding challenge will weed out the uninterested (and won't favor people that have 4-8 hours to devote to a huge coding challenge).

Re: On asking job candidates to code

#157
I am in the midst of my job search, fortunately I'm not currently working (due to an international move) so I have more time.

So far, I have completed around 12 1 hour phone coding tests, the same amount of 30 min chats with recruiters, I have 8x 5 hour on-sites scheduled, have spent about 4 long days on one take-home assignment, 6-8 hours on another, and have two more assignments to complete, both of which I estimate will take over 8 hours each.

I haven't had a weekend for the past 2 weeks because I've been working on assignments and I'm pretty stressed and exhausted.

This process has made me consider changing careers because it's so exhausting. When companies give you take-home assignments I don't think they realise how many things you have going on at the same time.

Additionally, I've found that a one hour coding test has allowed companies to move faster in the process with me than those who have given assignments. When I receive an offer from a company I am happy with then I will tell those companies with assignments I haven't finished that I won't be moving forward with them and they will miss out on a great candidate!

Re: On asking job candidates to code

#158
post #32

When we hire, after a few phone interviews we give the programmer an in person coding exercise that is very basic. Open a file and parse data, etc... They can use the internet. It's very basic. 80% of the candidates cannot do that. I'm not exaggerating. Maybe I'm missing something here, but it's pretty astonishing to me.

Do you require them to do it in a specific language or let them choose which one they are most comfortable with? How do you decide which programmers to bring onsite? Have you considered giving them different options in the from of doing a take home test or coming in and coding inperson instead?

We require a specific language... the language we use for the job. The phone interview asks technical questions, a few design questions, and some personality geared questions. The technical questions are basic and cover some of the basic concepts of the language and basics of OO.

We haven't considered doing a take home test for 2 reasons. 1) We want to see how well the person can get around windows/keyboard. I believe this is important. 2) What we are asking to code is very basic. If we sent something home it would have to be harder.

Are you thinking that the in-person coding would make them nervous? I ask because we are clearly doing something wrong if it's hard to find candidates that can do basic programming. Even if the person is entry level, that would be fine as long as they are an A player at the entry level... if that makes any sense.

Re: On asking job candidates to code

#159
post #114

Earlier quoted context omitted.

> You may have dodged the proverbial bullet. Wish I could upvote this twice! Every rejection I've ever received came with an information-rich sideband that told me more about the prospective employer than an acceptance would have. In at least half of such cases I said to myself: "phew, that was a bullet I was lucky to dodge... imagine how it might feel to work with these people!"

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.

Re: On asking job candidates to code

#160
> we would ask you to use just your language’s standard library, no third-party libs or frameworks... With the problem description, we sent to candidates a functional test suite, a binary that when started would try to connect to the candidate’s server implementation, open lots of sockets, sends lots of messages, and verify the results against what the problem description stated. The candidate was instructed only to send their submission once it passed the functional test on their local box.

Incidentally, this is exactly how the "Sun Certified Java Developer" certification was structured. You were only allowed to use java.* and javax.* packages provided as part of the JRE, and even among those things like the SQL packages were off limits. Instead of sending a test suite, they provided an interface you needed to implement and then when you submitted it, they had some sort of test suite that tested your code for conformance to the spec (and if it failed, you failed). If it passed, someone would manually review your program to make sure it made sense with respect to the requirements (which were intentionally somewhat vague, like real requirements) and if you passed that step, you had to write an essay about WHY you made certain design decisions (like sockets+serialization vs. RMI, etc).

This was by far the most challenging and fun task of its type that I've done, and to this day if I see that someone has that certification I know that they have what it takes to get things done. This methodology should really be utilized more, although for many companies the overhead of designing such a challenge would be way over the top. Makes me think that things like https://www.stockfighter.io/ have a future in our industry.

Post reply on HN