Three hundred programming interviews in thirty days • Hacker News Board

Re: Three hundred programming interviews in thirty days

#191

Post by dang » Wed, Jun 24, 2015, 12:49 AM UTC

el_fuser wrote: post #143

KingMob wrote: post #55

Earlier quoted context omitted.

I appreciate that you guys might not be statisticians, but if you're going to try and analyze data like this, you simply must address survival bias. As it stands, these data are meaningless unless you assume dropouts are completely unrelated to your screening. You claim doing well on the Fizzbuzz wasn't correlated with interview performance, but you also said "We saw twice the drop off rate on the coding problems as…

>> I appreciate that you guys might not be statisticians and apparently very few on HN in general, seeing how this piece was upvoted. Google has been studying their process in the last few years and are reaching different conclusions than these guys. Leave it to the reader to ascertain which group has more validity.

This is not the kind of comment HN needs more of. A better version would (a) drop the snarky putdown, and (b) actually say what Google's conclusions are. Then readers could decide for themselves to what degree those findings contradict these, instead of being told what to think.

Re: Three hundred programming interviews in thirty days

#192

Post by DrStalker » Wed, Jun 24, 2015, 1:06 AM UTC

nvarsj wrote: post #129

geebee wrote: post #39

Earlier quoted context omitted.

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…

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.

Re: Three hundred programming interviews in thirty days

#193

Post by foobarqux » Wed, Jun 24, 2015, 1:07 AM UTC

gjm11 wrote: post #146

foobarqux wrote: post #91

Earlier quoted context omitted.

Interview stress is of the type I call "defusing the bomb": everything at stake, essentially immediate time constraints and confrontational. This never occurs in real life.

"Unfortunately something not so different sometimes does. E.g., you're at a startup, you have a critical demo for your best-hope customer, it was scheduled very aggressively because the CEO wanted to fit the customer's availability, it's happening in one hour, and nothing is working. Not exactly confrontational (though it could easily get that way if you aren't careful) but just as stressful. Of course it's far bette…

Usually those situations are just "grinding", you need to work expediently, and there is time pressure, but it is not immediate and you don't need to think nearly as much as in an interview. (code -> compile -> ohshit -> repeat quickly) not (oh shit, how do I solve this algorithmic question I have never seen). Most people don't freeze up in the 1-hour until demo situation.

On the other hand, the time constraints in an interview are immediate: you have a few minutes to come up with a solution to a problem (interviewer will put up with at most 10 minutes of silence or babbling), it's often a zero-to-one problem (usually there isn't a way to have a partial solution) and those factors combine into exponentially increasing sense of pressure: as time goes on you become less likely to solve the problem.

Finally, if this situation does happen at all and, contrary to my claim above, certain people do freeze up, it does so so infrequently as to be immaterial in a hiring decision in the vast majority of cases. Its practical importance is certainly disproportionate to the weight placed on it in interviews.

Re: Three hundred programming interviews in thirty days

#194

Post by dsp1234 » Wed, Jun 24, 2015, 1:12 AM UTC

tomtang0514 wrote: post #120

geebee wrote: post #39

Earlier quoted context omitted.

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…

I've seen several companies giving out such homework to me or my friends back in college. And to be honest, none of the are among the "great culture company list" people are talking about. Beside all the issues you mentioned above, those tests don't have a clear PASS line. You spent hours on that and can be rejected for no reason. Back in college I've done a code challenge from Box and my solution ranked No.1 in thei…

(Obviously no one has ever agreed my term so far.)

My company does 4 hour work-product tests, and we pay each of the candidates for their time. We're in Portland, not SV, so maybe there is a difference in environment.

Re: Three hundred programming interviews in thirty days

#195

Post by Retra » Wed, Jun 24, 2015, 1:12 AM UTC

brudgers wrote: post #148

Retra wrote: post #126

Earlier quoted context omitted.

Half are below the average of practicing surgeons. But the average surgeon is much better because you weed out a lot of incompetent people who can't get certified.

Surgeons are not number 10 heating oil commodities. The difference in quality between one surgeon and the next matters when it comes to an operation's outcome. Likewise - and this is the gist of my comment - licensing software engineers might raise the minimum bar, but it won't make hiring any easier because licensing doesn't establish relevant expertise or pertinent experience. Obstetricians not thoracic surgeons ar…

What do you mean licensing doesn't establish experience or expertise? That depends entirely on what you use to qualify people for licenses.

Naturally, you won't hire a heart surgeon to do a brain transplant, but then you don't have a generic "surgeon" license, you have separate "brain surgeon" or "heart surgeon" licenses. You get a Cesarean from someone licensed to do it, and that won't be a thoracic surgeon.

And it _would_ make hiring easier, because you have a much smaller pool of candidates to look at. The problem with licensing is that you end up having to pay for a license, and technology changes to fast to keep licensing relevant. And so much of tech education is expected to be done without guidance or experience.

Re: Three hundred programming interviews in thirty days

#196

Post by notduncansmith » Wed, Jun 24, 2015, 1:16 AM UTC

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…

Our company does like to give a 2-4 hour take-home exercise after the technical phone screen, but (barring exceptionally bad submissions) we make a point to collectively spend as much time reviewing it as the candidate spent implementing it, for this exact reason. It's proved to be a very helpful filter so far.

Re: Three hundred programming interviews in thirty days

#197

Post by foobarqux » Wed, Jun 24, 2015, 1:28 AM UTC

gjm11 wrote: post #164

RogerL wrote: post #153

Earlier quoted context omitted.

You are ignoring the data. Person after person says they do fine in the job, yet have trouble with interviews. I've presented in rooms where the lowest ranking officer was a colonel, and most were important people at the Pentagon. No freeze up, easy peasy, because I know what the hell I'm talking about and because I know I'm not going to be judged on some bullshit evaluation. (re: "x Don't make up theoretical situati…

What data am I ignoring, and how do you know? I made no comment on what kind of interview works best. I merely observed -- what is certainly true -- that sometimes "defusing the bomb" situations actually do come up in real life, where everything is at stake and you have to work under very severe time pressure. Do you disagree that such situations sometimes arise in real life? If not -- if your point is that that isn'…

See my other comment but I think the differences are the immediacy of the time pressure, the sophistication of the thinking required and the all-or-nothing outcome.

Re: Three hundred programming interviews in thirty days

#198

Post by xraystyle » Wed, Jun 24, 2015, 1:28 AM UTC

tokipin wrote: post #159

overgryphon wrote: post #77

Earlier quoted context omitted.

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…

I don't think there's any relation. Some people may be nervous just because they are interacting with strangers, whereas they would have no problem with people they already know. Personally I don't have nervousness/stress issues in interviews, but I've found that conversation screws up the analytical mode that I use when I'm programming. It's like how people say they don't like having their managers interrupt them in…

Couldn't agree more. When I'm trying to think through a problem I want everyone around me to be friggin' quiet and leave me alone.

When I'm thinking about an abstract concept, trying to visualize how the pieces fit together, 'talking it through' is not helpful either. It's really goddamn distracting.

The feedback I got from my last 'cs 101 algorithms whiteboard quiz for a web dev job' was, "You need to talk more and explain what you're thinking." Ugh. Do you want the code or do you want me to talk, because you're not gonna get both.

Re: Three hundred programming interviews in thirty days

#199

Post by mbrameld » Wed, Jun 24, 2015, 1:34 AM UTC

fsk wrote: post #173

geebee wrote: post #39

Earlier quoted context omitted.

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…

If 90% of the people pass the take home test, then why was that step necessary in the first place? I've also soured on take-home test. I recently did a C/C++ one, I know I aced it, and I didn't even get a phone interview. I figured out afterwards what they were doing. They were giving the take-home test to EVERYONE who applied. Then, after you submit a solution, they read your resume. After looking at my (correct) so…

It's not that 90% of all developers can pass the test, it's that 90% of the developers that make it to the test part of the process can pass it. It should be a final filter to make sure they can walk the walk.

Re: Three hundred programming interviews in thirty days

#200

Post by hobs » Wed, Jun 24, 2015, 1:38 AM UTC

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.

And the person who could potentially write the "most perfect" code with all of the conditions applied is often not within that company's price range.

I did interviews at a company for about 2 years and there was constant pressure from management to do trivial crap like that, it finally came to a head and I invited management and one of the "rockstars" to do a mock interview.

When it was evident that the person they thought of as a "rockstar" could not solve these tests(without prior knowledge of the problems), they immediately discounted them as a worthless and stopped bugging me (about that, of course not about everything else).