I will not do a tech interview • Hacker News Board

Re: I will not do a tech interview

#451

Post by x0x0 » Thu, Aug 22, 2013, 2:06 AM UTC

tmoertel wrote: post #200

baddox wrote: post #167

Earlier quoted context omitted.

> Interview situations are very, very different than the others. How exactly? Freezing up in a meeting can get you fired just like freezing up in an interview can get you turned down for the job. Sure, you'll get comfortable with your coworkers, and they'll get more forgiving of temporarily lapses, but I think most interviewers (for non-terrible jobs especially) purposefully give some extra leeway to interviewees, si…

The primary way in which interviews are different from after-the-hire social interactions is that interviews are high-stakes events, and the candidates know it. For some people, that knowledge is enough to put them into a self-reinforcing mental death spiral. Their fight-or-flight response takes over and they literally stop thinking as their bodies switch into survival mode. That's why, when you're interviewing candi…

I'm embarrassed to admit that in one of my first interviews I was asked to code bubble sort and choked for the first 30 seconds (it felt like a lot longer) until I reminded myself "I can do this" and sort of got back into things. I'd be tempted to disagree that this is such a big factor but it happened to me on bubble sort.

Re: I will not do a tech interview

#452

Post by pbreit » Thu, Aug 22, 2013, 2:09 AM UTC

I understand the sentiment, the traditional interviewing process doesn't seem like the best way to evaluate candidates. However, the proposal breaks down for the vast majority of good hires in that it is impractical to expect someone with a full-time position to quit in order to try out for a new team.

Re: I will not do a tech interview

#453

Post by cglace » Thu, Aug 22, 2013, 2:16 AM UTC

baddox wrote: post #167

untog wrote: post #72

Earlier quoted context omitted.

Maybe somebody can explain this better to me -- but if you freeze up in interviews, are you also going to freeze up in developer meetings? During code reviews? When you're in the room with clients? Of course not. Interview situations are very, very different than the others. Meetings and code reviews are with co-workers, whom you know and trust. Meetings with clients could be nerve-wracking for other reasons, but the…

> Interview situations are very, very different than the others. How exactly? Freezing up in a meeting can get you fired just like freezing up in an interview can get you turned down for the job. Sure, you'll get comfortable with your coworkers, and they'll get more forgiving of temporarily lapses, but I think most interviewers (for non-terrible jobs especially) purposefully give some extra leeway to interviewees, si…

Why would you get fired for freezing up in a meeting?

Re: I will not do a tech interview

#454

Post by _getify » Thu, Aug 22, 2013, 2:24 AM UTC

I won't do tech interviews either, but not because I think I will fail at them. I think they are completely bogus and give totally the wrong signal. It's a waste of my time AND the company's time. I wrote up my thoughts on this exact thing a few months back: http://blog.getify.com/technical-interviews-suck/

TL;DR: Everything you need to know about if I'm a good fit is available online in my OSS (et al) track-records. If that's not good enough for you, that's not the kind of job I want anyway. I want to work for companies that value the full lifecycle of OSS work, which you can only see in such a way, and CANNOT judge via tech interviews.

By the time I walk in the door for an in-person interview, I expect you to already know that I am fully qualified (tech and otherwise), and you're looking now to judge my cultural fit by sitting me down in a real team meeting and seeing how it works, etc.

If I show up and you try to quiz my tech skills, you didn't do your homework on me, and I have no more time for you, so I'll just chuckle and walk out. Politely of course.

Re: I will not do a tech interview

#455

Post by jebblue » Thu, Aug 22, 2013, 2:49 AM UTC

tmoertel wrote: post #240

untog wrote: post #72

Earlier quoted context omitted.

Maybe somebody can explain this better to me -- but if you freeze up in interviews, are you also going to freeze up in developer meetings? During code reviews? When you're in the room with clients? Of course not. Interview situations are very, very different than the others. Meetings and code reviews are with co-workers, whom you know and trust. Meetings with clients could be nerve-wracking for other reasons, but the…

Can I offer you some advice? An interview is a negotiation. The rules aren't fixed. If you're asked to do something that won't give a reliable measurement of your ability, say so and offer the interviewer a better option. You'll probably get what you want. In the scenario you described, I might try something like this: "I think I see what you're trying to measure by asking that question, but it assumes a working styl…

>> Can I offer you some advice? An interview is a negotiation.

Probably good advice but most programmers I know including me are terrible negotiators which is why at least I work for the man instead of being a rich entrepreneur with that house at 3000 Ft overlooking the ocean with an unobstructed view.

Re: I will not do a tech interview

#456

Post by ballard » Thu, Aug 22, 2013, 2:57 AM UTC

tiglionabbit wrote: post #338

tmoertel wrote: post #240

Earlier quoted context omitted.

Can I offer you some advice? An interview is a negotiation. The rules aren't fixed. If you're asked to do something that won't give a reliable measurement of your ability, say so and offer the interviewer a better option. You'll probably get what you want. In the scenario you described, I might try something like this: "I think I see what you're trying to measure by asking that question, but it assumes a working styl…

I've tried that. The response is always, "This is how we do our interviews. If we changed it for you, it would be hard to compare you to our other applicants".

Yup.

Business theater continues despite evidence it doesn't work. [1] Consider this a signal everything else is broken too. Notice their signals to show you are more than a technical automata to "fill a process void in the value chain".

The best interviews are as casual as possible, and not called interviews.

Good interview process looks like:

- 2 phone screens (recruiter||hr and then hiring manager && closest cowoker, if any)

- webcam screen

- a couple on-sites that may lead to:

- questions about what they've been working on, what's important to them, their career development goals and eventual desired package (that's basically it)

- take someone out to lunch

- play a sport with them [2]

- work on a current problem

- have an adventure

(very important for hiring manager and coworkers to have a say; placing staff under a manager is fail.)

Skip the:

- behavioral questions

Before hiring someone on a temporary project basis. Full time in a reasonable amount of time (average 6 months), or part time if that works better for them. This way, it's cool to feel each other out in the non-creepy professional way and there's no hurt feelings.

[1] http://www.techrepublic.com/blog/career/google-admits-bizarr...

[2] I hate all sports, except Scrumball and World Cup.

Re: I will not do a tech interview

#457

Post by jebblue » Thu, Aug 22, 2013, 2:58 AM UTC

I felt like I was reading something I wish I'd written, thanks.

Re: I will not do a tech interview

#458

Post by welly » Thu, Aug 22, 2013, 3:00 AM UTC

cglace wrote: post #453

baddox wrote: post #167

Earlier quoted context omitted.

> Interview situations are very, very different than the others. How exactly? Freezing up in a meeting can get you fired just like freezing up in an interview can get you turned down for the job. Sure, you'll get comfortable with your coworkers, and they'll get more forgiving of temporarily lapses, but I think most interviewers (for non-terrible jobs especially) purposefully give some extra leeway to interviewees, si…

Why would you get fired for freezing up in a meeting?

You wouldn't. Certainly not in any company or organisation that I'd work for.

Re: I will not do a tech interview

#459

Post by SomeCallMeTim » Thu, Aug 22, 2013, 3:01 AM UTC

fizx wrote: post #386

SomeCallMeTim wrote: post #299

Earlier quoted context omitted.

>It's in fact illegal in most jurisdictions, including California. IANAL, but AFAIK it's absolutely not illegal in California; what's illegal is preventing you from working for a competitor AFTER you quit. I've never had a salary employment contract in California that DIDN'T say they owned everything I did in my off time, at least if I was working on something in a similar domain. The best contracts explicitly state…

The interpretation is complicated, but its neither black or white. Also, its standard in asymmetric contracts (EULAs, employment, rentals) for the drafting side to completely overreach. RTFM here: http://www.leginfo.ca.gov/cgi-bin/displaycode?section=lab&gr...

>.... except for those inventions that ... [r]elate at the time of conception or reduction to practice of the invention to the employer's business, or actual or demonstrably anticipated research or development of the employer

Seems pretty clear on the "similar business" front. IIRC that's been the wording in many if not most of the contracts I signed while I was still working as an employee in CA.

I've mostly worked in games, too, and so that pretty much meant "no game dev in my free time," period. A strong motivator to go indie/consulting.

Re: I will not do a tech interview

#460

Post by geebee » Thu, Aug 22, 2013, 3:03 AM UTC

thedufer wrote: post #383

justincormack wrote: post #367

Earlier quoted context omitted.

"The goal of interviewing is to avoid false positives, not to avoid false negatives" - why is it? I can rectify a false positive, but if I miss greatness I might fail. If you hire people that others do not look at you can get people who are very loyal too.

Rectifying a false positive is very expensive (cost of time they're not producing but drawing a salary, eating dev time for training, etc. + cost of firing), and firing people is a morale issue as well. Maybe this is from the perspective of a company that has no shortage of applications, but rejecting an applicant that would've been good costs basically nothing (dev time + travel if they got through phone screens). I…

I think part of the problem is that the technical grilling isn't necessarily reducing false positives after a certain point. You may simply be selecting people who have front-loaded data structures in an "exam ready" way and rejecting candidates who have a fine background in this area but aren't exam ready. Do you really reduce false negatives by doing this? I almost have to wonder if you increase them, since you may simply be selecting for people who know how to prepare for an interview (and who aren't so busy with important work that they can afford to drop everything to front load the information).

Think of it like this - you have two candidates. The first is exam ready for data structures and algorithms. You want merge sort? He whips out mergesort. You want red-black trees? You got it.

A second candidate is clearly aware of what run time is, and what trade-offs happen in different sorting algorithms. He's clearly aware of what can happen when a binary tree gets out of balance, and is aware of the types of more balanced trees. However, his knowledge is not exam ready. He can clearly code, but he starts to fade on the edge cases and in the implementation details. He mentions the chapter in a well respected data structures and algorithms book he'd read should this issue come up.

My question is, do you really protect yourself against false negatives with a no-hire on candidate #2? Candidate #1 may simply be someone who has figured out how to hack the programming interview. He might not be an especially good developer, not especially good at working with clients, with teams, with pushing through and getting it done. Or he might be very good at this. I'm just saying that I doubt that being "exam ready" is much of an indicator beyond the obvious coding ability and awareness of candidate #2.

However, this process clearly creates a huge number of false negatives - by bouncing #2, there's an excellent chance that you're passing on a superb candidate, and for what? A reduction in false positives that may be close to zero?

One thing - I think part of the disagreement on this board may come from the different definition people have for intensely technical interviews. Some would consider #2 to have passed. My own experience is that interviewers often do expect an "exam ready" preparation on data structures and algorithms, in addition to a few other branches of computing, which is probably I take a more cynical view of these interviews.