Live data from Hacker News

People suck at technical interviews

seldo.com

81–90 of 177 posts

Re: People suck at technical interviews

#81
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…

The biggest problem with a "work there for a day" interview IMO is that there's no time to do anything useful. You can't get familiar with a codebase of any size in a day.

Re: People suck at technical interviews

#82
post #48

Earlier quoted context omitted.

> You aren't interviewing people to determine how good they are at interviewing, because interviewing doesn't generate money for your company. Depends. At most companies, how you handle a simple interview is still relevant if it's for a revenue generating or client facing role (e.g., sales, marketing, and project management). Granted, most technical roles aren't generating revenue or in contact with clients, so this…

most technical roles aren't generating revenue Wait, what? The products I build don't generate revenue for my employer?

He means you're not selling directly to clients in a typical SE role.

Re: People suck at technical interviews

#83
post #61
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…

Testing 4=='4' is far from pointless. For better or worse, programming as the majority of us practice it is no longer about flipping bits or moving bytes or red-black trees or building common collections data structures. It's now about a language plus an api or apis, and the language of front end web development is javascript. So checking if front end or fullstack dev candidates have a basic understanding of types in…

Well, testing 4 == '4' is pointless in my opinion, because you should never use the '=='-type equality in JavaScript. I never use it, so I don't even know what that evaluates to. You should always use ===, and set up a linter to enforce that.

What I think is valuable to understand is the concept of truthy and falsy, as I've seen even some experienced JavaScript programmers struggle with that. Maybe that could be a decent interview question.

Re: People suck at technical interviews

#84

I'm just about to finish a B.S. in CS, so I've recently been on the other side of the table. I like to think I'm "aware" enough to give good feedback about my experiences. I've interviewed with two of the large "top" companies. They were two very different experiences. One decided to have me do multiple interviews, with whiteboard coding. The first interviewer was my favorite, because we got to talk about the design…

Outwith very senior C level roles you should need no more than 2 interviews to decide which candidate to make an offer to. Spending an entire day with 5 or 6 different interviews is just a waste of the candidates and the company's time.

"just a waste of the ... company's time."

If the wrong guy gets hired and everyone is to blame, then no one is to blame. Especially if one of the 8 interviewers has moved on since the hiring, and can be blamed completely, at least on the paperwork. CYA is very popular.

There's also a little manufacturing consent going on. I've been to interviews knowing the guy is already hired because he golfs with my VP, but we'll manufacture some consent by having someone in the group pretend to have input. I can either agree with the VP that his golfing buddy is a great hire, or hit the streets.

Re: People suck at technical interviews

#85
post #21
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…

When you hire somebody for your your team, company is not the only one stakeholder. The CEO won't spend 40 hours/week with new hire. Your personal productivity and happiness depends on new hire and if he has (1) bad communication skills (2) unpleasant to be around, it's no hire no matter his technical skills. There are exceptions to this rule of course - like when you won't personally work with the person or he is genius.

Re: People suck at technical interviews

#86
Followup question: Where can I find a list of companies (other than npm and Matasano) that don't interview with the stupid "write code on the whiteboard" method?

I've got some (1.5 years) experience, and I can write code. But put a whiteboard marker in my hand and ask me questions you know the answers to, in a high-stakes, high-pressure environment, and I fall apart.

Case in point: a recent technical interview I did, I did reasonably well until the last 1 hour session, which was the "code on the whiteboard" problem. I got code that functioned but wasn't fast enough. At home, after 1 google search and a few minutes, I solved the problem.

I'm definitely in favor of the "do a small project" type of code interview. It has its own pitfalls, but it's way better, IMO.

Re: People suck at technical interviews

#87
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…

I'd like to know what company you work for so I can apply there. My email is in my profile.

It says in his profile ...

Re: People suck at technical interviews

#88
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...

Most candidates cannot take a day off and just work for somebody else -- employment contracts may prevent that.

Re: People suck at technical interviews

#89
post #25
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 comp…

I don't generally ask those kinds of questions. Mine are more of the algorithmic variety (i.e., given this problem, how do you solve it?). Having said that, the last 10% of getting the job is demonstrating that you know SOME programming. I may ask you some programming questions like the one you presented, just to see whether you know programming at all. If you got this right, you're 95% of the way in the door, as opposed to just 90% of the way in the door. It's not a deal breaker -- I can teach you the difference between 4 and '4' -- but it's a huge plus if you get it right.

Plus, like the article says, most people suck at tech screens, so that interviewer may have just been asking random questions with no clear idea of what they're looking for.

Re: People suck at technical interviews

#90
post #62
post #55

> The famous fizzbuzz test simply asks "are you aware of the modulo operator? No it doesn't. It could be implemented with counters you reset when needed. Didn't really read any further, I don't think this person should really be giving technical interviews anyway.

Yeah, but not knowing the mod operator would get you dinged.

I thought the point of the FizzBuzz was that the asker doesn't care about 'clever' (for some definition of clever) answers, but rather, "Can this person actually write something which solves the problem, no matter how brain dead a solution"
Post reply on HN