Live data from Hacker News

I will not do a tech interview

medium.com

511–520 of 554 posts

Re: I will not do a tech interview

#511
post #489

When I started my career I was in the UK civil service. One of the best things I took from that experience was the formal training they gave me in interviewing. The UK civil service used interview boards consisting of a manager of the role, a subject matter expert and an independent person from outside the organisation. It is an inherently high-stress situation for the candidate due to the numbers involved and and us…

Thanks for writing that! I hadn't realized it before, but after reading your comment it seems obvious to me that an interviewing process should be designed like this:

a) Acknowledge and minimize the unavoidable stress of the situation.

b) Use more general questions where candidates can choose their preferred approach.

c) Allow them to show their strengths instead of seeking out weaknesses.

Re: I will not do a tech interview

#512

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 something similar once. I got asked about the binary search algorithm. After some high level discussion on the idea behind it, I told the interviewer I hope I won't have to implement it. The algorithm is known for being easy to get wrong [1]. Nevertheless the interviewer asked me to write it down on paper (using python). I've done so, but made a few mistakes. I still got the job offer, so the mistakes were…

>Nevertheless the interviewer asked me to write it down on paper (using python). I've done so, but made a few mistakes. I still got the job offer, so the mistakes weren't a factor

I think this is an important consideration. I do interviews quite often at my current company. And two steps of the interview process is a technical phone interview and a technical on-site interview.

I always ask coding questions, but before I start, I clearly tell the guys that they can use any language they want, and that I do not expect the program to "compile" or parse (in case of interpreted languages). What I always try to read is 1) that the person is not completely lost about programming, 2) What is his approach to solving the problem, and that he can explain it to me.

The problem I have with technical interviews (I also have always hated them when I've been in the interviewee sit), is when interviewers setup an "all or nothing" style. Usually it is because they were told to interview you, but they really don't know to do an interview, so they just read a bunch of problems to you and wait for you to solve them... without trying to read anything from the process.

Re: I will not do a tech interview

#514
post #295

Earlier quoted context omitted.

It may be a negotiation but it is a very asymmetrical one. That by itself might be the root cause of a lot of the anxiety.

I feel like focusing on the asymmetry of it is a large part of the problem. If you're not walking into the interview prepared to disqualify these people as potential employers, that is doing a disservice to yourself.

I wish I could agree with you.

But the interview process is such a time suck (not to mention that you have to nick out on your regular job which you can only do so many times for a half a day before they get wise) that by the time you are walking into an office for an interview, you've already made a non-trivial commitment. You can only repeat it a handful of times (assuming you have another job or are otherwise professionally engaged) before it becomes a real burden.

Now, if you are unemployed and you have a substantial financial cushion or can pick up enough 'anytime/anyplace' freelance work, sure, interview with 5 companies a week, take your time and be picky. But how many job seekers are in such an ideal position?

Re: I will not do a tech interview

#515
My reality is a joke. The CIA creates all the web pages I visit. The torture me. Hell no I'm not taking a CIA job and getting tortured. You think I'm stupid.

God says... ehheh_thats_all_folks stricken maybe_I_didn't_make_it_clear invest conquered sensible

Re: I will not do a tech interview

#516

Granted, there are a lot of bad tech interviews out there (asking about algorithms that nobody ever uses) ... but I do not understand this. Imagine someone's being hired for a front-end position, and we don't have months to get them up to speed. I'm going to ask them to explain how a closure works. How they deal with AJAX. What they think about "!important". Things to be careful about with floats. How CSS precedence/…

As someone who recruits I'd say that I don't think the point is that there are parallels between interviews and other situations and the candidate is being rejected because of that, it's that I just didn't get enough information to make a decision.

Any part way competent interviewer knows the difference between a bad interview and nerves getting the better someone. When it's nerves we're not thinking "they're awful", we're thinking "i don't know how good they are".

At that point I'm generally too busy to try and come up with a bunch of other things myself on the off chance the person will respond better to a different situation BUT if the person were proactive and came back and said "I know I screwed that up, would it be possible to try X instead", I think I'd be open to that.

(That said obviously giving small paid projects work to all potential interviewees doesn't scale particularly well.)

Re: I will not do a tech interview

#517
post #253

Earlier quoted context omitted.

The freezing up is a factor of anxiety, and anxiety can have any combination of triggers. What usually happens in an instance like this (I'm assuming it's similar to test anxiety) is that somewhere along the way, they froze during an interview, and the memory of that compounded the problem for the next interview, and so on and so forth. So the anxiety could be tied solely to tech interviews. There are plenty of stude…

I also get very anxious during exams and always make silly mistakes. It saddens me to see some some interviewers on this thread that naively believe that the kind of stress a person feels during an exam (especially one where the tester is sitting in front of you and watching your every move) is the same kind of stress you might experience while trying to fix some problem in front of your computer.

Well, the thing about anxiety is that it's very irrational. Unless you've suffered from it or, like me, are very close to someone who does, it's very hard to understand. (I still have only a surface level understanding after a 10 year relationship with a sufferer.)

It's easy to look at all of the things taking a test and fixing code in an emergency have in common and make the rational assumption that someone who is bad in one situation would be bad in the other.

Re: I will not do a tech interview

#519
post #460

Earlier quoted context omitted.

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…

I don't see the relevance. The fact that you're asking someone to code a mergesort or a red-black tree tells me that you don't know how to interview, not that interviewing doesn't give you useful information. Candidate #2 sounds like they passed the interview - what did I say that made you think I'd reject them?

Yeah, if you're really bad at interviewing, it's not going to give you good information. I'm not disputing that. Interviewing, as it's done where I work (and everywhere I've interviewed, which admittedly isn't very many places), has been very effective at reducing false positives.

Re: I will not do a tech interview

#520

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 really want to address this in more detail than I have time at the moment to do so. I am a dissenter on this topic, though, so I would like to ask you to elaborate on your view of the trade-offs.

> cost of time they're not producing but drawing a salary

How many false positives do you know of who didn't produce anything? What is the actual chance that someone is going to be a net drag if they don't work out? Of course it can happen, but I get the impression from the more paranoid that it is likely or expected. I don't see that.

> eating dev time for training, etc.

This, I feel, is highly dependent on company and codebase. At my previous employer, I worked on real-time radar signal processing code which was very complicated and math-heavy. Someone who did not know what they were doing in that code could have easily cratered the productivity of one or more software or systems engineers. Simpler codebases would not be as bad.

> + cost of firing

Depending on your local laws and corporate structure, I can understand this issue. It takes an act of Congress to get fired from a defense contractor, though they have enough small layoffs to prune the dead wood once in awhile without a full-blown firing. I would like to know what the issues are for a smaller company though, since I really don't know the process. I get mixed signals as well. It seems like the employers and managers here speak of the difficulty in actually getting rid of people, while most of the individual contributors I know are worried about losing their jobs at the drop of a hat.

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

If your company is finding the people it needs more or less when it needs them, then I understand this view. However, if your company is also one of those that complains about how hard it is to find "qualified" people and how understaffed you are, then your false positives are costing your business far more than that, though the true cost is very difficult to quantify (as is the true cost of a false positive).

Post reply on HN