On asking job candidates to code • Hacker News Board

Re: On asking job candidates to code

#141

Post by drubio » Tue, Mar 15, 2016, 3:24 PM UTC

jcadam wrote: post #98

stuaxo wrote: post #92

Earlier quoted context omitted.

I'm curious where you are based, been worried about a similar thing happening, but doesn't seem to yet - (am based in UK).

Oh, I'm in Florida. The local market isn't that great (though I am presently employed) so I've been interviewing for remote jobs.

Remote is insanity now a days, it was a reasonable market a few years ago but not anymore. There's a glut on both the supply and demand sides.

Many years ago there was a limited demand for remote work, which probably tapered the supply, but in my experience from every 3 leads you followed (granted you had the experience), 2 were promising and 1 was almost always an offer. Now a days it's more like you need to follow 30 leads to get one 'meh' answer. I don't feel it's an age issue, it's just a general market condition.

With more companies acceptance of remote work, mixed in with the "we can't find local talent" mantra, the hiring process has turned more hands-off which in turn is producing these insane hiring procedures and cycles.

To make matters worse, everything from the smallest start-up to the largest tech company is adopting the same 'exclusive hiring practices' while they sit back wait for the resumes to roll in and/or send in work samples. All of this is hands-off trying to get candidates to 'fill slots' costs them next to nothing until the final phases. But for candidates it's just a time consuming PITA.

My only advice is to treat the process as any business transaction. Try to gauge how much they are invested in the hiring process, if they are asking you for hours or days on end while they appear to invest a couple of minutes of 'human time' RUN! These are lottery-like odds of landing an offer and unfortunatly this is endemic in large companies as well as unknown startups.

Re: On asking job candidates to code

#142

Post by tptacek » Tue, Mar 15, 2016, 3:26 PM UTC

ryandrake wrote: post #140

tptacek wrote: post #115

Earlier quoted context omitted.

The "no homework" thing is such a red herring. Companies that do work samples minimize on-site coding interviews , because the whole point of offsite work sample testing is that most candidates can't provide an accurate picture of their aptitude in an on-site coding interview. No interviewing software developer prefers an extra 6 hours of on-site interview to an off-site coding challenge. The problem developers have…

> No interviewing software developer prefers an extra 6 hours of on-site interview to an off-site coding challenge. I'd prefer it, since if I pass the coding challenge, I'm likely in for a airplane flight and an on-site interview anyway, so I've still lost that time from my life in addition to the time spent on the coding challenge. Unless the coding challenge is conducted INSTEAD of an on-site hazing session, in whi…

You're always going to get flown out. But the hazing session might take 2 hours instead of 8, and won't involve you coding on a whiteboard.

Very good companies can tell you over the phone after you finish work sample challenges what your odds are of getting an offer.

Re: On asking job candidates to code

#143

Post by orng » Tue, Mar 15, 2016, 3:27 PM UTC

mikeash wrote: post #122

orng wrote: 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.

Why ask technical questions about the skill you want to see, when you could just ask for a demonstration of that skill?

Because asking a few quick questions doesn't waste 8 hours of your candidates time.

Re: On asking job candidates to code

#144

Post by ryandrake » Tue, Mar 15, 2016, 3:27 PM UTC

Hermel wrote: post #18

In my experience, asking candidates to read and explain someone else's code is a much better indicator than letting them do some whiteboard programming.

This is a great point. Most programming jobs I've seen are about 10% writing new code and 90% maintaining / fixing / extending old code. I'd rather know that you can jump into a codebase you've never seen and get productive quickly than know that you can invert a binary tree on a whiteboard.

Re: On asking job candidates to code

#145

Post by drumttocs8 » Tue, Mar 15, 2016, 3: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…

You may have just built part of his product for him. I wonder how the front-end interview went...?

Re: On asking job candidates to code

#146

Post by smarks » Tue, Mar 15, 2016, 3:29 PM UTC

maxaf wrote: post #114

mtberatwork wrote: post #105

Earlier quoted context omitted.

> The fact that so many employers treat candidates like this Don't give up. Most established companies aren't run by 20-somethings. If the seniors are already in their mid-20s and lack professionalism, then most likely there are other issues going on at this company. You may have dodged the proverbial bullet.

> 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!"

+1 for the phrase "information-rich sideband".

Re: On asking job candidates to code

#147

Post by 15155 » Tue, Mar 15, 2016, 3:31 PM UTC

otabdeveloper1 wrote: post #103

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…

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

Re: On asking job candidates to code

#148

Post by cdibona » Tue, Mar 15, 2016, 3:33 PM UTC

innertracks wrote: post #101

Last week, I finished 2-3 hours of on-site interviews which required a flight and an overnight stay after an initial phone screen, a phone technical interview, and a short technical challenge online. I was surprised how a couple really basic concepts evaporated from my head during the in-person white boarding. The questions though were reasonable and the interviewers were friendly. All in all a positive experience ju…

So I know you're kidding about the last, but a good nights sleep can make a huge difference to recall and memory and performance during an interview. I have interviewed tons of people and can always tell who had to fly internationally to get there..

Re: On asking job candidates to code

#149

Post by ryandrake » Tue, Mar 15, 2016, 3:33 PM UTC

maxaf wrote: post #114

mtberatwork wrote: post #105

Earlier quoted context omitted.

> The fact that so many employers treat candidates like this Don't give up. Most established companies aren't run by 20-somethings. If the seniors are already in their mid-20s and lack professionalism, then most likely there are other issues going on at this company. You may have dodged the proverbial bullet.

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

Re: On asking job candidates to code

#150

Post by cdibona » Tue, Mar 15, 2016, 3:35 PM UTC

dasboth wrote: post #104

sixtypoundhound wrote: post #72

The real problem here isn't coding interviews; its how we (hiring managers) approach the entire question. The goals of a technical interview should be: - Confirm the credentials presented aren't complete BS - Validate they know enough to be immediately helpful - Assess their long term potential (brains, social skills) Coding challenges tend to be good at the first two points but very questionable for the third. Incid…

"you would be silly not to include some form of practical test" Yes, I'm coming to the realisation that it's idealistic to assume that anyone with N years experience will be at a certain level of ability. "(potential) is best measured by talking with them about a project they really cared about" I agree. I've always thought that once you've made sure that a candidate's programming knowledge isn't fabricated, the best…

One of the best interviews I 'gave' was when the interview was for a position programming on a topic I knew almost nothing about. I had the person bring their laptop and walk me through their implementation of the topic at hand, then asked how they'd scale/improve it given more cpu/memory/etc and what kind of constraints the larger environment would impose upon the work.

It was super neat. Totally hired that person.