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

Three hundred programming interviews in thirty days

blog.triplebyte.com

Post reply on HN
Print view View original

201–210 of 248 posts

Re: Three hundred programming interviews in thirty days

#201

Post by Eridrus »

technofiend wrote: post #64
eitally wrote: post #16

Earlier quoted context omitted.

My wife is in this position now, and it's not for a programming job. She works in pharmaceuticals, in pharmacovigilance & risk management. She does a lot of data analysis & writing (the latest report she wrote for Health Canada & the FDA was 461 pages). A company she's interviewing with asked her to do a sample writing task as part of her application/interview. She hasn't decided whether it's worth it or not. For som…

I had a similar experience last year applying for a major technology company. Although I still lightly code in the devops sense (process automation) and to do typical management data analysis my day job is managing people, processes and crises. If you have billion dollar trading systems and need a cool-headed guy who can talk to VPs or directors in one breath and SAs, DBAs, SAN, Network, etc guys in the next I'm your…

> at some point you have to rely on technical people to do their jobs.

On one hand, I totally agree that technical tasks should be left to the technical people, preferably those who are actually working on the system. There's almost nothing worse than a manager trying to take technical decisions out of people's hands.

> Am I wrong to think if I'm going to manage a 60-100 person organization across three timezones I don't really need to be under the hood in the code any longer? Or am I clueless?

On the other, I think people want to work for people they respect and to the extent that people respect technical chops that might be what they are screening for. Though the hash map question sounds like a soft ball, so it might be screening for a baseline of software competence.

Re: Three hundred programming interviews in thirty days

#202

Post by mshenfield »

overgryphon wrote: post #77
ammon wrote: post #27

Earlier quoted context omitted.

Yeah, we agree. We don't plan on asking everyone to do hours of work on their own. A lot of people don't have the time. However, we're also seeing a bunch of applicants who are good programmers, but become really stressed in interviews and do badly (they freeze). These people have trouble getting jobs. What we want to do is offer them the option of doing a larger project on their own, rather than our final interview.…

Interview environments are always stressful, but so are other common workplace situations. Being unable to manage stress effectively might contribute to poor on-the-job performance, even for people with great pure coding ability. The process right now seems focused on finding people who are the best at only coding. In the future, do you intend to also consider communication skills? Senior developers act as mentors fo…

Programming interview stress is a terrible indicator of real-life leadership ability. But communication skills are still an incredibly important of being a good programmer, often more important to success than programming ability (http://blog.codinghorror.com/how-to-write-without-writing/).

Personally, I've spent hours working on a project or problem only to find that, be it the result of miscommunication, lack of critical thinking by a manager, or lack of understanding on my part, what I'd created contributed nothing to the bottom line success of our organization.

Anyone, what kind of resources are there to objectively assess a candidates communication skills, leadership ability, and teamwork? What is a constructive way to provide feedback and resources for interviewees about their performance?

Re: Three hundred programming interviews in thirty days

#203

Post by rwallace »

DrStalker wrote: post #192
nvarsj wrote: post #129

Earlier quoted context omitted.

I like the idea of giving candidates a choice. For me personally, I would almost always take the "homework" if it meant no (or very short) in person interview. I like to code, not interview. Still, 6-7 hours is pushing it, it should be a few hours (3 or 4 at max, if you're not going to do a face to face), and a genuinely interesting problem (the kind of problem can tell you a lot about the company itself!). When I in…

Homework can't replace an interview, unless you're willing to hire people who can code without any idea if they will fit in with the team or be able to work with others.

That sounds intuitively reasonable, but does an interview actually have significant accuracy in filtering out people who will do badly on those criteria? As far as I know, such data as is available says human intuition is completely wrong about this and an interview is not significantly more accurate than flipping a coin.

Re: Three hundred programming interviews in thirty days

#204

Post by crdb »

geebee wrote: post #39
protonfish wrote: post #6

It's great to see some objective research being done on this, and I am very interested in following the results. They mention evaluating the effectiveness of giving a candidate a project to do "in their own time." I recently had a interview that included this and I can share the result: I accepted an offer from a different company that didn't require it. I doubt my life is that different than anyone else's, with a fu…

I did this once. After a take home quiz that took about an hour, I had a 6-7 hour "homework" problem. I did it, and sent it in. It took the company a month to get back to me, though I did stay in contact with the recruiter. The final answer, delivered by the recruiter, was "we've decided not to more forward at this time." No other feedback. I have no idea if anyone even looked at it - I never did speak to a dev at th…

"these tests allow the company to burn a lot of a candidate's time, but not the other way around "

Oh yes the other way around. At a previous employer, two of us took 3 full time months to review over 100 qualified candidates (i.e. that returned the task) to make 10 offers.

We made an offer to anybody who met our standards - whilst management initially restricted our headcount, they allowed us to expand the team as great people got in touch and the main restriction ended up being the maximum salary we were allowed to offer (which had us have to give up on half a dozen candidates). (We offered people the chance to show us their FOSS contributions to skip the task, but even those with big reputation couldn't resist tackling the problem.)

That's 3 full time months of not doing ANY work, no output, just full time recruiting, for two people who were probably in the top 10% of the company in terms of compensation.

It's not just expensive in time but also politically, as the team has no output to show for the period.

Where McDowell is correct is in the context of a large company whose hiring needs are very different. But I think that if you are building a small team where every member counts, you have no alternative.

Re: Three hundred programming interviews in thirty days

#205

Post by nandemo »

mbesto wrote: post #19

> In our first 30 days, we've come up with a replacement for resume screens, and shown that it works well. What's the metric that shows it works well? > The really exciting point comes when we can re-run all this analysis, basing it on actual job performance, rather than interview results. And how precisely do you measure job performance? If this is achievable, I've got a line of companies out my door that would love…

For this purpose, it shouldn't be too hard. You don't need the evaluation results for deciding raises or promotions, and you don't need to compare employees to each other. You just need to determine if the hiring decision was correct. We can do it with a binary score:

0. Oops, shouldn't have hired.

1. AAA would hire again.

I suppose you could make finer distinctions (need to fire this person/we regret hiring but will work on it/meets expectations/exceeds expectations), but my point is that the golden standard for evaluating hiring decisions is whether the hire is adequate or not for the job. I mean, if someone gave you an oracle or a time machine that allowed you to evaluate the employee on the job for a while before hiring them, all your hiring problems would be solved. Now, if you cannot evaluate if someone is good enough for the job, then you have a bigger problem.

Re: Three hundred programming interviews in thirty days

#206

Post by jsprogrammer »

tomtang0514 wrote: post #169
lockes5hadow wrote: post #133

Earlier quoted context omitted.

Even in C I would point out that the compiler will likely make such a trivial optimization for you. That was clearly a company full of morons.

Regardless of the compiler, let's say (x Some interviewers (not just the "homework") raise their bar by not allowing you to make any tiny mistake. And I just don't get it. If someone is good enough to write something like a lite version of Hacker New website in hours, I'm not going to turn him/her down because of such mistake.

Sometimes x << 3 is more readable than x * 8. It depends on why you are doing the shift/multiply.

Re: Three hundred programming interviews in thirty days

#207

Post by crdoconnor »

geebee wrote: post #39
protonfish wrote: post #6

It's great to see some objective research being done on this, and I am very interested in following the results. They mention evaluating the effectiveness of giving a candidate a project to do "in their own time." I recently had a interview that included this and I can share the result: I accepted an offer from a different company that didn't require it. I doubt my life is that different than anyone else's, with a fu…

I did this once. After a take home quiz that took about an hour, I had a 6-7 hour "homework" problem. I did it, and sent it in. It took the company a month to get back to me, though I did stay in contact with the recruiter. The final answer, delivered by the recruiter, was "we've decided not to more forward at this time." No other feedback. I have no idea if anyone even looked at it - I never did speak to a dev at th…

Ironically, the last time I complained about this practice on hacker news for exactly the reasons you described, somebody weighed into defend the practice, and an job applicant at his company weighed in to say "my application to your company was not even rejected, it was just ignored for months":

https://news.ycombinator.com/item?id=9437516

Re: Three hundred programming interviews in thirty days

#208

Post by rwallace »

eitally wrote: post #16
protonfish wrote: post #6

It's great to see some objective research being done on this, and I am very interested in following the results. They mention evaluating the effectiveness of giving a candidate a project to do "in their own time." I recently had a interview that included this and I can share the result: I accepted an offer from a different company that didn't require it. I doubt my life is that different than anyone else's, with a fu…

My wife is in this position now, and it's not for a programming job. She works in pharmaceuticals, in pharmacovigilance & risk management. She does a lot of data analysis & writing (the latest report she wrote for Health Canada & the FDA was 461 pages). A company she's interviewing with asked her to do a sample writing task as part of her application/interview. She hasn't decided whether it's worth it or not. For som…

Does she have existing samples of writing that she can point to, not locked up under copyright?

If so, then I would point to those samples and suggest those should be relevant data for assessment and I'd like to get further in the process before putting in extra work for this.

If they're prepared to discuss the matter, great.

If they just give a blank 'sorry, this is our policy,' then walk away. Why? Because if they're not willing to have a discussion with you, that means they don't care about you. It means they think they have a hefty surplus of candidates. Which means you are very unlikely to be the chosen one, and you would probably just waste a lot of your time.

Re: Three hundred programming interviews in thirty days

#209

Post by mkozlows »

ammon wrote: post #156
mwfunk wrote: post #152

Preamble: not middlebrow dismissal, I really like what they're doing here and will pay attention to them going forward. This is just picking a nit that my hypersensitive self just can't resist: "Fizz buzz style coding problems are less predictive of ability to do well in a programming interview" I'm sure this is 100% true, but I thought the point of fizzbuzz-type problems were to weed out people who couldn't program…

Yeah, we're just using it to mean a asking a simple programming problem (of fizzbuzz difficulty).

But if you're not evaluating the ones who fail, then what's the point of it? you're just grading for style points?

What I take away from your article is that being able to solve a FizzBuzz-style problem isn't correlated with being able to do a more intensive programming task later, which surprised me. What I take away from your comments here is that among people who were able to solve a FizzBuzz-style problem, some variety of style point scoring isn't correlated with being able to do a more intensive programming task, which... okay, that's totally plausible, and much less surprising/interesting.

Re: Three hundred programming interviews in thirty days

#210

Post by CydeWeys »

rqebmm wrote: post #140
ruswick wrote: post #134

Earlier quoted context omitted.

Maybe. I've always thought it would be interesting to make applicants pay an application fee. This would cut down on people "spraying and praying" with their application, and would lessen the workload for companies. It would also justify spending more time and effort in reading applications, since the company isn't just wasting resources reading bad applications. Even under the current system, at least the waste is s…

> Even under the current system, at least the waste is symmetric. But it's never symmetric. Someone in HR spent time setting up the job posting and managing the process. Someone in management took the time to respond to HR and review your resum, then approve the interview. At least one person at a time is in the interview with you. Then the entire team will spend time afterward breaking it down. A single hour spent b…

> A single hour spent by a bad candidate wastes at least 3 man-hours of work by the company, and most likely more.

So? Companies need employees. They have to do what it takes to get them. If it weren't worth it, they wouldn't do it.

It makes sense to me that more time in aggregate is spent by the company than the candidate, because the company has dedicated recruiting/HR/coordination people that handle the process. I, as an already full-time employed developer, don't have as much time to burn with interviewing.

Post reply on HN