Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

People suck at technical interviews

seldo.com

Post reply on HN
Print view View original

21–30 of 177 posts

Re: People suck at technical interviews

#21

Post by tptacek »

Jemaclus wrote: post #3

My primary criteria when interviewing junior candidates are: 1) Do you have basic problem solving skills? 2) Can you communicate clearly? 3) Do I want to sit next to you for the next 6 months or longer? If you don't know Ruby, I can teach you. If you don't know Elasticsearch, I can teach you. What I can't and don't have time to teach you is how to solve a problem on your own without me holding your hand, and I especi…

Criteria #3 is toxic. It's one of those things people adopt with the best intentions, but (a) is often at odds with the best interests of the firm and (b) provides an enormous amount of cover for prejudices and, more perniciously, cognitive biases. When you're interviewing a candidate, assume your brain is trying to trip you up (it is!). Build a hiring process that treats your intuition as an adversary and eliminates cover for biases.

Re: People suck at technical interviews

#22

Post by jakozaur »

I disagree with author about coding question. In my experience if somebody is not able to code quickly a simple task (like fizzbuz, reverse a string), it's a terrible sign. It's a simple objective test that filter out a lot of candidates.

Yeah they may be able to be productive in some specific environment (e.g. deep in some framework, writing templates), but in general they likely don't have solid programming foundation and will produce code of lower quality.

Re: People suck at technical interviews

#23

Post by russelluresti »

I'm not sure I agree with the "team fit" thing. I get his point - most people don't understand what team fit is or can't separate it from personal bias. But here's my counter-argument.

Every company and team has different core values. "Team fit" means matching company and team values. For example, I work on educational software for teacher and students. My definition of "team fit" (for this particular team/company) is that the person care about improving quality of education. If you're applying just because you need a job but don't care about what it is we're making, I don't care about any of the other criteria listed in this article - I'm not hiring you. You may be smart, able to learn, and a great communicator - but you don't care about what we're building so you don't have the same core values as the rest of the company and team.

This is what "team fit" means - not what they look like, what they do in their off time, or anything else; "team fit" is "do they personally value the same things we value as a team"?

If you value transparency and collaboration and they prefer to work as a lone gunman, they're not a team fit. If you value rapid iteration and user feedback and they don't want to release anything until it's 100% perfect in their eyes, they're not a team fit. So on and so forth with the examples.

Re: People suck at technical interviews

#24

Post by tptacek »

darkstar999 wrote: post #17

> I used to ask people to write code in interviews. This is terrible. Bull! Last time I interviewed someone, they looked good on paper and decent on the phone. When it got down to solving a _simple_ problem on the whiteboard, he totally flopped. This is a totally realistic situation; we get together at least weekly and hammer out a solution on the whiteboard. Nerves could be an issue, but a good candidate should be a…

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.

Re: People suck at technical interviews

#25

Post by fnbr »

Jemaclus wrote: post #3

My primary criteria when interviewing junior candidates are: 1) Do you have basic problem solving skills? 2) Can you communicate clearly? 3) Do I want to sit next to you for the next 6 months or longer? If you don't know Ruby, I can teach you. If you don't know Elasticsearch, I can teach you. What I can't and don't have time to teach you is how to solve a problem on your own without me holding your hand, and I especi…

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 companies on equality comparisons in Javascript (e.g. "Does 4 == '4'?"), which I found pointless, as I can test that within seconds at a computer.

[1] The major exception was 42Debut. Even though they didn't give me an offer (just stopped replying to my emails, but c'est la vie), 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.

Re: People suck at technical interviews

#26

Post by bengali3 »

ap22213 wrote: post #16

Instead of technical interviews, I would love to just pay a potentially great candidate to come in and work for the day. Not only would it give them an opportunity to demonstrate what they know and show off their other skills, it would give our team a chance to see if they're a good fit. And, there would be some real financial incentive for them to give us a try. But, trying to get management and HR to change from th…

good point, especially since all day interviews are most likely requiring the candidate to take the day off anyways. On the other hand, i'm a mess the first month starting a new gig with all the lingo that I don't know yet...

Re: People suck at technical interviews

#27

Post by euphemize »

I'm currently studying for multiple interviews at "established" tech companies, and I wonder where the interviewers like the author are. I've already finished a few, and between having to implement a linked list, analyze a matrix, describe hashmaps and regurgitate sorting algorithms, the questions have not had much to do with everyday coding.

I'd be really happy to discuss how to implement feature X in an app, or how to design the moving parts of Y for a particular infrastructure and talk about the tradeoffs each implies. But I guess I'll get back at implementing a queue using 2 stacks, because that's what technical interviews seem to be for.

Re: People suck at technical interviews

#28

Post by tptacek »

ap22213 wrote: post #16

Instead of technical interviews, I would love to just pay a potentially great candidate to come in and work for the day. Not only would it give them an opportunity to demonstrate what they know and show off their other skills, it would give our team a chance to see if they're a good fit. And, there would be some real financial incentive for them to give us a try. But, trying to get management and HR to change from th…

There are big problems with processes that work this way --- as a group, they're "temp-to-perm" arrangements, although your "one day" version of it occupies the less odious end of the spectrum. I've written about the idea elsewhere on HN before and will try to dig some links up.

Re: People suck at technical interviews

#29

Post by collyw »

aliston wrote: post #2

I think there are some good points here, but I would argue that a lot of these are essentially points for hiring more junior engineers. There are cases where hiring for what someone already knows DOES matter. I have come across too many codebases that were clearly written by folks who were in the "get stuff done" mentality. Frankly, when you're learning a new technology in addition to trying to do your job, your code…

No really. I was hired in my current job 3 years ago, with experience. I didn't know Django, but had read enough, and seen a talk on it by someone else. I learned Django on the job, but my previous knowledge of databases and Perl complemented that. I didn't know Python, but its similar enough to Perl, I just googled to find the Python equivalent. Once you have a seen a couple of languages and concepts, learning new ones doesn't always hinder you so much.

Re: People suck at technical interviews

#30

Post by buckbova »

tptacek wrote: post #24
darkstar999 wrote: post #17

> I used to ask people to write code in interviews. This is terrible. Bull! Last time I interviewed someone, they looked good on paper and decent on the phone. When it got down to solving a _simple_ problem on the whiteboard, he totally flopped. This is a totally realistic situation; we get together at least weekly and hammer out a solution on the whiteboard. Nerves could be an issue, but a good candidate should be a…

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.

I would rather hire the strong developer that can code without autocomplete and write without spellcheck.
Post reply on HN