Live data from Hacker News

People suck at technical interviews

seldo.com

161–170 of 177 posts

Re: People suck at technical interviews

#161

Earlier quoted context omitted.

I'm not sure why it makes you sad. On a germane-to-the-parent-comment sense, that's pretty much exactly what tptacek said. But on a wider scale, if you are trying to help someone, wouldn't you want to give them advice that truly helps them in a big and cross-task way? Much better than "get good at Rails", which is useful only for a subset of engineering roles (albeit a subset I may enjoy). In terms of time investment…

Yes, for the current state of the industry it is good advice. That is the part that saddens me, that "get good at sales" in order to get a job that has nothing to do with sales is sound, even the best, advice.

Software development is still sales. To successfully roll out a new internal product you need to sell your colleagues on it. To overhaul an existing architecture you need to sell your manager on its necessity. To prevent your coworker from making what you feel to be a poor choice, you need to sell her on your point of view.

Re: People suck at technical interviews

#162

Fizzbuzz isn't supposed to be a test of your knowledge of the modulo operator. It's supposed to be a very low bar that can filter out a large percentage of candidates who have no business being there. If you spend 20 minutes on Fizzbuzz, you're doing it wrong. It should take 10 tops, and be limited by how quickly the candidate can write.

I think FizzBuzz is so popular that if you even needed me to describe the question, I'd be a little confused. I don't think I know any programmers with more than a year or two of experience/schooling that have never seen FizzBuzz before.

Now don't get me wrong, I wouldn't think poorly of someone or of their programming skills because of that. But not knowing about FizzBuzz is like not knowing the name of the current president. Have you been living under a rock for the past 5 years? It seems to be mentioned at least once a week on any sort of newsfeed, forum or blog related to programming.

Re: People suck at technical interviews

#163
post #158
post #124

Earlier quoted context omitted.

I'm with @lostcolony: if I were interviewing and a candidate said "don't do that, it's unpredictable, do this instead" it's a great answer.

At the same time though, as someone looking for their first dev job, I'm not going to tell the interviewer "don't do that." Given the people I've met in industry, I can't see that ending well- I would expect some variation of "who does this kid think he is!?"

You can always phrase it as, "That's ill advised, here's why, my guess is it does X, but you probably shouldn't do that in production code".

Re: People suck at technical interviews

#164
post #20

This is a really excellent post. It talks about a bunch of things that are hobby-horses of mine (I help run recruiting for a large software security firm), and I find myself agreeing with more of it than I disagree with. I would go a little further than Laurie does. I think several of the goals he sets up for his process are not in reality achievable in an interview process. Starting axiom: job interviews are among t…

Thanks! To your suggestions:

1. I tried to emphasize how important it is to keep the candidate relaxed and comfortable. Your suggestions are good, though we are too small and resource constrained to spend several weeks on interviews; each candidate gets about 6 hours in total, at least an hour of which is with me.

2. I had this process at my last job -- I asked everybody the same opened-ended architectural design question, and found it very useful for hiring back-end engineers, but at npm it's obviously inappropriate for our front-end and CLI engineers, so I've yet to come up with a "standard" question. It's a great suggestion.

As an aside, I am pleasantly surprised to see how many constructive comments there were on this article. Sort of feels like HN from a couple of years ago.

Re: People suck at technical interviews

#165

Earlier quoted context omitted.

Yes, for the current state of the industry it is good advice. That is the part that saddens me, that "get good at sales" in order to get a job that has nothing to do with sales is sound, even the best, advice.

Software development is still sales. To successfully roll out a new internal product you need to sell your colleagues on it. To overhaul an existing architecture you need to sell your manager on its necessity. To prevent your coworker from making what you feel to be a poor choice, you need to sell her on your point of view.

Agreed. There is a sense in which almost all meaningful and social tasks are "sales". Scare quotes are used there, not because the same skill sets don't apply, but because you typically aren't actually transacting over the results of the conversation.

Re: People suck at technical interviews

#166

Earlier quoted context omitted.

> A recursive solution springs to mind, but I can recall implementing recursive solutions in production code only a few tens of times over a ten year career. If you are not comfortable with recursion, just remember: Recursion is really just a free stack. To use your example: Whenever you see an opening brace, push onto the stack. (Or, make a recursive call, which goes onto the call stack...) Whenever you see a closin…

Thank you for the helpful comment. I can't help but feel you miss the point of my post though. I can solve the problem. Verbally, (but admittedly less eloquently and less complete) I approximately gave your answer in the interview. Give me a quiet Monday morning, a pair of headphones and a compiler/interpreter and I can solve it well. It's the fact that it is being used as a filter when the person filtering doesn't k…

I understood your post. I didn't comment on your other points because I didn't feel I had anything to add. I was just trying to be helpful in regards to the particular problem you posted, and for anyone having trouble with recursive problems in general.

Re: People suck at technical interviews

#167
post #24

Earlier quoted context omitted.

He didn't say coding was bad. He said coding on a whiteboard is bad. And, if you evaluated 100 strong developers by comparing their performance at a terminal and a whiteboard, my guess is that you'd quickly see that he's absolutely right about that --- not only would everyone outperform the whiteboard with a terminal, but that the whiteboard deficit would be highly irregular, defying any attempt to "handicap" for it.

Coding on a whiteboard is also impossible or infeasible for candidates with some kinds of disabilities (e.g. blind). Sure, you can make an exception for those few candidates, but I suppose the fact that you even have to make an exception to your normal process for a particular candidate might bias you against that candidate.

There are lots of accommodations I would need to do for someone who is blind, or deaf, or missing his hands. (I knew (through association) a developer who had hooks for hands.) The fact that you need to put some changes into your recruitment process for disabilities doesn't mean your recruitment process is necessarily broken.

Re: People suck at technical interviews

#168
post #25

Earlier quoted context omitted.

As a junior developer, I find myself confused by your comment. It seems as if a large proportion of the posts on HN claim that, when looking to hire someone, they focus on problem solving abilities and and culture fit. However, in May when I was interviewing with companies (including YC backed startups), almost every company focused on quizzing me about trivia [1]. I was actually given a paper quiz by one of the comp…

I was treated with respect throughout the whole process, and the interview was very well done, with challenging questions that forced me to think, and didn't rely on language trivia. I would recommend the company to any of my friends, whereas I can't say that about almost any other company I interviewed with. This is a really important point to remember for interviewers. The interview process isn't just to help you f…

Of the many companies that have rejected me, Suitable Technologies (makers of Beam robot doubles) were the best. The biggest thing was that they rejected me as soon as they knew they had rejected me. Within a few hours.

Which hurt, in the short term, because I am a human being. But it was better than many other companies that would say "we'll tell you later today" and then wait a week, or wait for two weeks since my last interview and then reject me in the middle of the CTF they are running and I'm participating in (what, did my answers in the CTF suck?) and then invite me to apply for a job at the end of the CTF after rejecting me. That's really yanking my chain.

Re: People suck at technical interviews

#169
post #47

For my first job out of uni, I was asked to write pseudocode on a whiteboard to solve a simple scripting problem (call an executable repeatedly, changing the command line args). My background is nuclear engineering, and I was interviewing at a cloud/networking business, so I was already slightly outside my experience comfort zone[0]. I was explaining my thought process while writing on the whiteboard, trying my best…

"That's not pseudocode..." he said as he started to berate me for not writing bash.

I, literally, just slapped my hand against my forehead loud enough to get people to look at me.

It's an understatement to say that, as a profession, we have poisoned the well when it comes to interviews.

Re: People suck at technical interviews

#170

Fizzbuzz isn't supposed to be a test of your knowledge of the modulo operator. It's supposed to be a very low bar that can filter out a large percentage of candidates who have no business being there. If you spend 20 minutes on Fizzbuzz, you're doing it wrong. It should take 10 tops, and be limited by how quickly the candidate can write.

I think FizzBuzz is so popular that if you even needed me to describe the question, I'd be a little confused. I don't think I know any programmers with more than a year or two of experience/schooling that have never seen FizzBuzz before. Now don't get me wrong, I wouldn't think poorly of someone or of their programming skills because of that. But not knowing about FizzBuzz is like not knowing the name of the current…

People have different social circles. I mentioned FizzBuzz at my current position and none had heard of it, but they all banged it out in 3 minutes.
Post reply on HN