Live data from Hacker News

I will not do a tech interview

medium.com

301–310 of 554 posts

Re: I will not do a tech interview

#301

Earlier quoted context omitted.

It's expensive in other ways though. A programmers who is currently employed but thinking about moving on probably won't agree to a two-week trial period because of the substantial risk that they get rejected afterwards and end up unemployed. That makes the trial period expensive to him . In turn, it makes it expensive to the employer as well, because you'll filter out good people.

Can they not do this two-week project after hours? Must it be in your office, on your schedule? Where you code, the hours you code, these do not matter. The code is what matters.

Sure, but now it's not going to get full time dedication, maybe half that if you're lucky. So it's more like four weeks. And maybe they don't even have that much free time, so it's even longer.

Re: I will not do a tech interview

#302
post #85

Earlier quoted context omitted.

The problem is that interviews are high stress affairs. Stress produces adrenaline. One of adrenaline's known effects is to prepare us for "fight or flight", meaning that higher order logic is shut off, digestion is shut off, our senses sharpen, reactions improve. This is great when you've got to climb a tree to get away from a tiger. This is horrible if you are trying to demonstrate your ability to function mentally…

Sorry, but a negative reinforcement cycle of tensing up in a medium stress situation is exactly the kind of characteristic that I'm trying to screen out in an interview. Stressful situations happen a lot more than never in the real world (and sometimes they even involve talking to people, like customers) -- I don't want to have coworkers who can't handle that.

Interview skill really has nothing to do with job performance (and I'm pretty good at interviews). It's a lot like standardized testing: "this metric is completely irrelevant but at least it's testable!"

Re: I will not do a tech interview

#303

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/…

Generally, I'm not hiring people to explain things out of the blue to people who already know the answers. I'm hiring them to build things. So I don't like to spend a lot of interview time on pure quizzing.

The primary filter for me these days is the pair programming interview. Can they make something? Do they think clearly about what they're making? Do they ask good questions? Can they explain why they did something, and what other options are?

Re: I will not do a tech interview

#304

Earlier quoted context omitted.

> I don't want my employees to have to learn everything just-in-time What about just some things . And in most cases, it's not learning for the first time but brushing up on the topic. To expect people to have encyclopedic knowledge of every edge-case problem your company deals with on a day-to-day basis is ridiculous.

As OP said, you would not be able to google the specific B-Tree question because if you don't know about B-Trees you wouldn't know that you need to google it. There's a difference between things you know you don't know (and therefore can google), and things you don't know you don't know (and therefore will not google).

"I can see you're a bright individual and you have a great track record for writing and shipping good software, which is clear from your github account and your previous employers' endorsements. I have no doubt you'll be able to come up to speed on which is something we use a lot around here. We're looking for people who can learn quickly. Welcome aboard!"

Re: I will not do a tech interview

#305
post #85

Earlier quoted context omitted.

The problem is that interviews are high stress affairs. Stress produces adrenaline. One of adrenaline's known effects is to prepare us for "fight or flight", meaning that higher order logic is shut off, digestion is shut off, our senses sharpen, reactions improve. This is great when you've got to climb a tree to get away from a tiger. This is horrible if you are trying to demonstrate your ability to function mentally…

Sorry, but a negative reinforcement cycle of tensing up in a medium stress situation is exactly the kind of characteristic that I'm trying to screen out in an interview. Stressful situations happen a lot more than never in the real world (and sometimes they even involve talking to people, like customers) -- I don't want to have coworkers who can't handle that.

I think your estimate of interviews as a "medium stress situation" is somewhat simplified and personal. Interviews push you into completely unfamiliar territory, in which you're simultaneously trying to solve context-free problems, defend your answers, and gauge the personality and preferences of your interviewer (an answer that works for one won't always work for another).

A client meeting, code review, or dispute with a manager can be stressful, but you can answer from a position of strength. You know your code, have reasons for your decisions, and have met some standard to get the job. Interviews may be less demanding, but for some people it's a huge problem that there's no solid place to stand.

Re: I will not do a tech interview

#306

this is a very good idea. i've had multiple interviews where i did well on the phone and the tech-out, only to receive a "take home exercise".. with guidelines such as "it will be graded by style and architecture in addition to correctness of function". This would mean half of my saturday in a coffee shop coding an elaborate solution using latest technology and good patterns.. with some resentment because i just wast…

Same thing. I got an open ended problem that would take a measure of forever to solve: Specifically to write a program (in your favorite language!) that would do natural language processing and discern emotions and feelings about subjects from text. We were supposed to include our own lexical parser. The author's strategy scales poorly with complex and interlocking problems. Where it is more important to show potenti…

> I got an open ended problem that would take a measure of forever to solve: Specifically to write a program (in your favorite language!) that would do natural language processing and discern emotions and feelings about subjects from text. We were supposed to include our own lexical parser.

I know of a YC alumni company that asks for a weekend project on roughly that level and when rejected candidates ask if they can upload their work to Github, the company declines because they'd "like to keep an even playing field for future candidates."

Then you're left with choosing between having an awesome project you can't show off and being an inconsiderate jerk who uploaded code despite being asked not to.

Doesn't really make one enthusiastic for the next time you're asked to do an "exercise" or a "project."

Re: I will not do a tech interview

#307
post #72

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/…

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…

My favorite technical interview was when one of their engineers got me on Skype, and told me to explain (line by line) the code for one of my open-source projects (which he picked out).

I didn't prepare for this, but it allowed me to convey my engineering thought process and brag a little :) I really enjoyed it.

Re: I will not do a tech interview

#308
post #300

Earlier quoted context omitted.

if you freeze up in interviews, are you also going to freeze up in developer meetings? Are you really saying that your developer meetings are as high-stakes as job interviews?

Are job interviews really that high-stakes? There are always more jobs for skilled tech people.

There are always more jobs, but not always of equal desirability. Knowing that this company is the only one in the perfect location, on a project that fascinates you is about as high-stakes as it gets.

Re: I will not do a tech interview

#309
post #135
post #129

Earlier quoted context omitted.

I'm curious, is this a money issue, i.e., you refuse because it feels like working for free? Or is it just a principal thing? I doesn't seem unreasonable to me to ask even a senior developer to do a small coding assignment as part of the interview process unless they can show a good, relevant coding sample. If we're going to agree that whiteboard coding isn't a great way to evaluate someone, and we can't ask you to d…

I'm curious, is this a money issue, i.e., you refuse because it feels like working for free? Not OP, but it doesn't "feel" like working for free. It is working for free. Having someone perform work for you without paying them is illegal in the United States (see minimum wage laws). There's a simple solution; pay them $x per hour to do your 3 hours of work. Even if you pay them $100 per hour that's a cheap way of filt…

Interview programming assignment = work? I don't agree with this.

Re: I will not do a tech interview

#310
post #67

On-site interviews are a necessary for the most part, but phone screens have always been the bane of my existence. About 50% of the time I can barely understand what the other person is saying, mostly because the person conducting the interviewer is not a native English speaker. I almost never have an issue in person with non-native English speakers because you're able to pick up so much more context from subtle phys…

I should do the same. I am not native speaker and everytime I start a phone interview I feel like I'm already 10 points behind in the game we are playing.
Post reply on HN