Harder programming questions do a worse job of predicting outcomes • Hacker News Board

Re: Harder programming questions do a worse job of predicting outcomes

#21

Post by xiphias2 » Mon, Feb 18, 2019, 6:35 PM UTC

maxerickson wrote: post #10

xiphias2 wrote: post #3

,,Hard questions do filter out bad engineers, but they also filter out good engineers (that is, they have a high false-negative rate). Easy questions, in contrast, produce fewer false-negatives but more false-positives'' The philosophy at Google is that it's better to filter out 3 good engineers than to let in a bad one. The consequence of this is that it's really hard to get kicked out of Google. The other part (whe…

It's at least good that they call it a philosophy.

For me not being afraid to get kicked out of my workplace was a good thing. Also most of my colleagues were amazing, I miss talking to them, but at the same time I don't miss what the top management has become.

Re: Harder programming questions do a worse job of predicting outcomes

#22

Post by tomp » Mon, Feb 18, 2019, 6:35 PM UTC

drugme wrote: post #4

Because they're designed that way. It all comes down to: * Rejecting far more candidates than you need to -- so you can feel like you're hiring "the top 1 percent" * Giving yourself the feeling that you have an objective hiring process (when really you don't) * Making your own team members feel like they're super brilliant and special when really they're not That's what the modern hiring process is designed to do. An…

> Rejecting far more candidates than you need to

What do you mean by "than you need to"? I'm guessing for many companies (especially the ones with this kinds of interviews), the limit is the number of hires they can do, not the number of candidates that apply... So by definition, you need to reject all but n (the number of open jobs)... Why wouldn't you reject them based on performance on interviews (as opposed to, by their CV or luck or something)?

Re: Harder programming questions do a worse job of predicting outcomes

#23

Post by closeparen » Mon, Feb 18, 2019, 6:40 PM UTC

komali2 wrote: post #14

>how clean their code is, I got bit in the ass by this one as triplebyte itself. They asked me to make a tic tac toe game, and gave me iirc 30 minutes (less?) to do it. Except, it wasn't "build a tic tac to" game, first it was "draw a board to the console," "take user input from the console," etc a bunch of instructions in a convoluted path that perhaps another engineer would do when knowing from the outset that the…

Telling people not to worry about parts of the problem is often a time management strategy. They want you to move on so you have a chance to show strength in other parts of the problem, or at least come away with the positive experience of finishing something, even though it may count against you.

Re: Harder programming questions do a worse job of predicting outcomes

#24

Post by rightbyte » Mon, Feb 18, 2019, 6:40 PM UTC

zinclozenge wrote: post #15

The less talked about absurdity is that successfully passing programming interviews is a skill itself. It's especially absurd because the time I spend developing that skill is less time spent developing skills and knowledge more directly relevant to my job. Yet, programming interview skill is more relevant to progressing my career. edit: now if you'll excuse me, I need to do some dynamic programming problems.

This is kind off strange for a non US resident to grasp. I've been employed as a programmer three times and noone tested my coding abilites what so ever on the interviews. No samples, nothing. Never heard of any collegue doing that either.

Re: Harder programming questions do a worse job of predicting outcomes

#25

Post by davidhyde » Mon, Feb 18, 2019, 6:41 PM UTC

I think that asking a candidate to perform a code review can be an effective method of evaluating quite a few desirable qualities. Can they understand someone else's code? Can they engage in constructive critical discussion? Are they able to effectively refactor something to make it better? Can they spot mistakes and do they have an opinion about how to avoid such mistakes?

Re: Harder programming questions do a worse job of predicting outcomes

#26

Post by antibland » Mon, Feb 18, 2019, 6:42 PM UTC

A few jobs back I was tasked with hiring new developers to bolster a thin front-end team. The job was very CSS/JavaScript heavy, so I asked questions that were pertinent to what the candidate would be doing if hired. Of the five candidates, only one answered all the questions perfectly, and he turned out to be the biggest bust for us.

The other candidates, after answering some of the harder questions incorrectly, seemed very upset with themselves. They knew they were cracking a bit under pressure, but actually showed that they knew the answers when we chatted further. I hired 3/4 of those people because of how well I felt they'd do given the opportunity. All three became leads within a year and a half.

I think personality has a lot to do with outcomes. If you are someone who shows they are hungry to learn and knows how to improve their skills, I will never dismiss you for screwing up a few coding questions.

Re: Harder programming questions do a worse job of predicting outcomes

#27

Post by CoolGuySteve » Mon, Feb 18, 2019, 6:43 PM UTC

drugme wrote: post #4

Because they're designed that way. It all comes down to: * Rejecting far more candidates than you need to -- so you can feel like you're hiring "the top 1 percent" * Giving yourself the feeling that you have an objective hiring process (when really you don't) * Making your own team members feel like they're super brilliant and special when really they're not That's what the modern hiring process is designed to do. An…

Don't forget that they introduce market friction to reduce developer turnover and reduce salaries.

I suspect one of the reasons Google is so open about their process and the need to study is so that everyone follows suit. Thereby forcing people to take days off and do homework for even the most mediocre of positions, causing the switching costs of interviewing anywhere to become higher.

Re: Harder programming questions do a worse job of predicting outcomes

#28

Post by warp_factor » Mon, Feb 18, 2019, 6:44 PM UTC

zinclozenge wrote: post #15

The less talked about absurdity is that successfully passing programming interviews is a skill itself. It's especially absurd because the time I spend developing that skill is less time spent developing skills and knowledge more directly relevant to my job. Yet, programming interview skill is more relevant to progressing my career. edit: now if you'll excuse me, I need to do some dynamic programming problems.

This is why this whole interview thing is so absurd. The amount of days lost by engineers to relearn obscure algorithms and training on leetcode while we could be coding for things that are actually useful.

Re: Harder programming questions do a worse job of predicting outcomes

#29

Post by paul7986 » Mon, Feb 18, 2019, 6:44 PM UTC

One interview of mine asked something i didn't know yet I said there's no doubt I figured it out via Google. The interview pretty much ended there and I'm glad it did! Any place or interviewer that says you shouldn't use Google of OverFlow to get your work done is no place I want to work for.

Re: Harder programming questions do a worse job of predicting outcomes

#30

Post by ensiferum » Mon, Feb 18, 2019, 6:45 PM UTC

cshg wrote: post #5

Specific examples of what classifies as a “hard” or “easy” interview question would be very helpful to have reference points and assess one’s own interview process.

examples of hard (subjective), recursive algorithms, anything that requires dynamic programming, generating permutations/subsets, problems that require a "de facto" memorized algorithm such as tree/graph traversals, coloring of subsets etc.

easy.. anything that is not hard :-)