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

Harder programming questions do a worse job of predicting outcomes

triplebyte.com

Post reply on HN
Print view View original

11–20 of 540 posts

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

#11

Post by drugme »

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…

The philosophy at Google is that it's better to filter out 3 good engineers than to let in a bad one.

Corollary: "If I follow (what I've heard to be) Google's hiring practices (despite not having their brand recognition or candidate pool or a comparable engineering environment to offer) -- then my company is on the way to becoming another Google!"

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

#14

Post by komali2 »

>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 goal was to build a tic tac toe game in 30 minutes, but not me.

So we'd get to a portion where I'd be writing a quick test on user input, or extrapolating something to a function, and the interviewer would say "don't worry about that, just worry about {getting the grid to print to console or whatever}."

Later on I got my feedback and they said they were disappointed with my user input tests and repeated, extractable code in the tic tac toe portion.

Triplebyte is trying to do good things in the interview space but I think they're still learning. All in all my interview with them was about as positive an experience as a harried and bad interview could be, from my perspective.

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

#15

Post by zinclozenge »

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.

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

#16

Post by xiphias2 »

drugme wrote: post #11
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…

The philosophy at Google is that it's better to filter out 3 good engineers than to let in a bad one. Corollary: "If I follow (what I've heard to be) Google's hiring practices (despite not having their brand recognition or candidate pool or a comparable engineering environment to offer) -- then my company is on the way to becoming another Google!"

Sure, it's something not to be copied by a small company. But it's important to understand for good developers that they can be great and still fail the process (they just have to prepare again adn reapply)

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

#17

Post by gammateam »

I don't give questions like this primarily because:

- Workers are going to be around for 15 months or less and they have domain expertise on 1 stack already and I don't need to screen for how they would hypothetically function across all stacks

- Worker's process and resource finding skills are more indicative of the time they will spend on a task

- Worker's process includes collaborate use of version control and code reviews, if they pass the screening but can't really integrate on these things then thats what will get them booted from the team

It isn't always more expensive to have a not great developer. Look in your organization and see if what I experience is true for you, and you'll save everyone a lot of time.

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

#18

Post by harryf »

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…

Think it’s more a by-product than by-design. At the risk of making a blanket statement, think it’s fair to say most software engineers have average-to-poor people skills, leading them to the fallacy that “logic tests” are a good way to evaluate people. That in turn leads to a bias you describe “did you see how badly the candidate failed the test!?!”

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

#20

Post by pps43 »

akhilcacharya wrote: post #9
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.

Easy - reverse a string, determine if a string is a palindrome, reverse the digits of an integer, determine if one string is an anagram of another. Hard - implement a subset of regex match in optimal time+space, find the operations required to turn 1 word into another word given a list of transitory words, find the median of 2 sorted arrays in optimal time, find the next permuted value.

That's more like small/large than easy/hard.
Post reply on HN