Live data from Hacker News

I will not do a tech interview

medium.com

141–150 of 554 posts

Re: I will not do a tech interview

#141

I'd go so far to say that most interviews do not seem to serve much purpose other than to boost the interviewer's egos. The more that a company is full of engineers who feel trapped in their jobs or lives, the more that this seems to be the case. The other irritating thing is that people seem to prefer selecting people who are technically more intelligent than they are, but who are less socially apt that they are. It…

I read things like this and I just wonder... Who are these people talking on the Internet, and what universe do they actually occupy?

Because they have some decent points about how the interviews they've been in have been flubbed by the people conducting the interview, but they seem ENTIRELY inconsistent with my experience at any place I've interviewed ever, and I don't think it's my experience any time I've conducted an interview either.

Maybe I'm just not working in the wrong part of the industry? I mean, I think I've gotten some variety in interviewing, like: Silicon Valley - a small-to-medium networking software startup, and a small social media startup. Seattle - Amazon. NYC - Bloomberg, a tiny mobile-software company, and a medium-size very-late-stage media startup.

... and they all have about the same in-person technical-interview processes, which is to say, a little bit of talking mixed with a series of exercises like: here's a toy question, go solve it for us. I say "okay, here's what I'm thinking, X Y and Z, this what you mean? do you care whether it's built more like this or more like that?" start throwing some code on a whiteboard, etc etc

Re: I will not do a tech interview

#142
post #123
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…

Well, jobs are high stress affairs too. We often have to maintain production systems that fail in cryptic ways at the most inconvenient times. I postulate that such situations are more stressful than solving some binary search tree problem on a whiteboard.

Most of my developer jobs haven't been particularly high stress. Perhaps there is some selection bias here in that if you rely on the usual high stress interview process for developers you increase the chance of working with people who create systems that regularly need hot patching in production. Sounds like a dreadful job to me, so I guess that if there is any truth to this speculation that I should be happy about the selection mechanism.

Re: I will not do a tech interview

#143
post #92
post #78

Earlier quoted context omitted.

There is a common theme but an interview and a crisis situation are not the same. Its like attending an exam, its not the same getting work done in the real world. >>Learning how to be interviewed is as useful a skill as learning how to code. No, learning how to build is a useful skill. Learning how to be interviewed is mastering the art of being the best rat in the rat race. The whole point is even if you win, you s…

> Its like attending an exam, its not the same getting work done in the real world. Of course it's not. Real world is much more stressful than an interview. During an interview you chat with another developer in a room with a whiteboard. In the real world you are woken up by a phone call at 4 AM to fix a critical system, knowing that if you screw up even slightly, you'll lose a very important customer. I've experienc…

But you have much more background at 4am, you know the likely failure modes, you aren't dealing with a black box. An interview is often a black box you do not even know what you are trying to optimise for...

Re: I will not do a tech interview

#144
post #43

> I politely suggest that a short contract job might be the best option for a company to evaluate a senior developer I like the twist of doing the contract off site on the developers own time. Every time I see someone on hacker news saying, "we've solved the interview problem. We just require every new hire to give up their old job and contract with us for a week to see if they are a good fit", I often wonder about t…

I've seen companies do a "challenge" style interview, where it's less of a contract and more of a "take this problem home, code something up to solve it, push to github and let us know when you're done". Then the interview portion is discussing the solution. It means you can calibrate across candidates better, but I think the advantage of an onsite contract job is the two-way feedback, especially in a smaller company…

In my experience, these take home projects are woefully underspecified. Do they know this and expect me to email them with "good questions"? Or want me to not email them and "fill in the blanks" on my own? Do they want something that "just works"? Or something that is "reusable"? And so on. There's a reason we don't write production code by just throwing a document over the wall.

Re: I will not do a tech interview

#145

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

This is weird. I would definitely fail your interview. Yet, at the same time, I've shipped over a dozen products, dozens of releases, consistently, to hundreds of thousands (if not millions) of people. I have a solid track record of clean, bug-free, efficient code. In 14 years of development, I've never had a bad review, and I've consistently ranked on the 'A-track' at all companies that I have worked for. I have low ego, work well with others, am a great teacher. Yet, my top priority is the craftsmanship of software: understanding user requirements and shipping great products that meet those requirements. My priority isn't being able to describe the intricacies of closures.

Re: I will not do a tech interview

#146

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

Numerous people cannot remember the names of acquaintances they've lived and worked with for years. If you name a concept a programmer works with every day, it's entirely reasonable that that programmer does not remember the name because she knows the concept by its syntax, not its name.

A lot of interview questions are also asked using synthetic examples that are not complete solutions. A good programmer will reach out and explore the full technical ramifications of the requirements instead of merely solving the problem. Knowing that complexity adds a whole new level of stress versus simply solving the easy problem the interviewer intended.

A lot of people have trouble sleeping the night before an interview. It's more stressful than anything they will likely encounter at your company because it determines a major, unpredictable branch point in their future. Unless informed their continued employment is at risk over the outcome of a meeting, client meetings will not have the same degree of stress.

Re: I will not do a tech interview

#147
post #73

Lot's of very skilled people interview poorly. Nervousness, social stress, anxiety etc. So don't feel bad, people who interview applicants a lot know this. It's not a mark against you. If they are interested in you, they'll find a way to learn if you have the knowledge/skills they require for the job. If I don't know the answer to a question or if it is ambiguious, I tell them. For example, I was once asked to descri…

I'm not sure it's that simple. I had an interview where I got tripped up by a simple condition in a if statement. I don't remember exactly what it was, maybe it involved a quirky negation.

But either way I would've never had a problem with something that simple sitting here at my own computer. Did the interviewer understand that it was just an interview fluke? Probably not. After all, it was such a simple thing.

So I would warn against believing you can see past people's interview issues. Companies in general seem to have a misplaced level of confidence in their hiring processes, even assuming their proxies for intelligence weren't naive.

Re: I will not do a tech interview

#148
post #43

> I politely suggest that a short contract job might be the best option for a company to evaluate a senior developer I like the twist of doing the contract off site on the developers own time. Every time I see someone on hacker news saying, "we've solved the interview problem. We just require every new hire to give up their old job and contract with us for a week to see if they are a good fit", I often wonder about t…

I've seen companies do a "challenge" style interview, where it's less of a contract and more of a "take this problem home, code something up to solve it, push to github and let us know when you're done". Then the interview portion is discussing the solution. It means you can calibrate across candidates better, but I think the advantage of an onsite contract job is the two-way feedback, especially in a smaller company…

This is the way the company I work for currently does it.

They provide the candidate with a piece of terrible code, ask for a code review of as many issues as the candidate can find, and also for a refactored copy of the code. Both of which are completed remotely on the dev's own time.

This is before even meeting the candidate in person. Once we meet in person for the first time, another terrible piece of code is provided -- in this case a basic data structure -- and another code review is requested. The candidate is given 15 minutes to complete it.

It's interesting what comes back. Some people comment only stylistic issues, others only logical or architectural issues. One person got up and left during their alone time.

Other than these, no coding is required.

So far, it's worked out pretty well. And when I was going through it, I enjoyed it.

Re: I will not do a tech interview

#149
post #85

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

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.

Re: I will not do a tech interview

#150
One good thing about reading/browsing HN is that you can get an impression of the ideas that are starting to emerge. One thing that seems to be emerging now is that people are rethinking the grueling technical interview process.

There was a huge emphasis on avoiding false positives in the interview process - largely because a single bad hire can do great damage to a software development team. But people seem to be learning that these grueling processes may not do as much to avoid the false positives as we thought, and are creating a vast number of false negatives.

I am no longer interested in participating in this sort of multi-day technical exam taking. I've studied stochastic processes, mathematical optimization, data structures and algorithms. I've taken exams on them. I've hit the books for a couple of weeks prior to interviews where I've been grilled on these subjects in greater depth than I experienced during my exams in grad school. It's important knowledge, I get that, but I don't want to have to mentally reload the material in "exam ready" memory simply to pass yet another interview. I will rely on my general knowledge and my ability to look things up on the job. My interviewers should feel free to evaluate my knowledge, but does this really have to be more grueling and take four times as long my final exams in college/grad school?

It's not that a technical screening isn't valuable, it's that the grueling nature of these interviews means that if you can't recursively print out all permutations of a string on the spot, right now, don't get confused up there at the whiteboard, you're a no-hire. It can be very clear that the interviewee is aware of what mergesort is, how recursion works, the importance of run time in algorithms, and that the candidate almost certainly at one point implemented it. They want to see it, now, in code, on the whiteboard. Or, these days, typed into a screen that an interviewer is looking at.

A couple of years back, last time I was looking for jobs, I spent one and a half days in interviews. I was asked to code a singleton, add a branch to a binary tree, traverse a binary tree, now without recursion please!, find the long term probabilities in a markov chain, formulate a linear program and prove that the dual of the primal is the primal of the dual, now with matrix notation please!, write a bunch of outer joins, convert a curve into a piecewise linear function (don't lose convexity, please), on and on. Each interviewer was fresh, I was shuttled from room to room. Then I came back for three hours of interviews with management. No hire.

Another special one was where I only got to talk to a recruiter, passed a few java tests (about an hour), and then took a homework assignment (spend no more than 5-7 hours, please!). Didn't hear back, didn't hear back, didn't hear back. About a month, and the recruiter calls, oh, they've decided not to pursue this any further.

This is a rant, and perhaps an angry one. I feel bad about that, and it doesn't feel great to admit that I've failed in these interviews, either. But I'm glad that some pushback against this practice seems to be building.

Post reply on HN