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

91–100 of 540 posts

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

#91

Post by bitL »

ashelmire wrote: post #86
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. Just fire the bad ones. You're going to get bad ones anyway. At larger companies you might never notice whether someone is good or bad. From the way they structure their interviews, it seems like they'll still get plenty of bad ones - it's just they'll get bad ones that are great at algorithms, with unknown skill a…

> Just fire the bad ones.

That's Facebook. Hire fast, fire fast.

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

#93

Post by gizmo385 »

sigfubar wrote: post #55
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…

You failed your Triplebyte interview because you neglected an extremely important aspect of the job: communication. You made assumptions about the ask which turned out to be grossly out of tune with those of the interviewer. In the real world, engineers are often left holding the bag when other participants of the process leave out important details. It’s our job to ask questions and establish the boundaries of each…

> engineers are often left holding the bag when other participants of the process leave out important details

That sounds like a process problem and not an engineering problem. If I've been given requirements, I'm going to trust that my project managers and stakeholders have done the due diligence to understand their request.

Also you've got to realize that different developers tackle issues in different ways. Not every engineer is going to be super talkative while they're in the mud trying to get something to work until they've hit a wall that they don't feel like they have enough information to overcome. I think expecting an engineer to sit there and talk through every aspect of their reasoning WHILE working is fundamentally counter to the way that most engineers perform their day-to-day jobs.

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

#94

Post by gonehome »

griffinkelly wrote: post #74
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.

I've worked with some folks who were decent engineers who originally didn't get offers from FANG companies because they blew the interview; they later studied their ass off on leetcode and got offers. This did not make them better engineers at all. Ultimately, its just studying for the test, very much like the ACT/SAT in high school. You can be great at taking tests but ultimately a terrible student or vice versa.

It feels very much like that to me which is why it’s strange there isn’t a Kaplan equivalent.

There’s interview cake and leetcode, but I think people would pay $2k for a class that focuses on the questions and in person whiteboard practice.

They could collect information about the interviews at the major companies and then use those to create the program. For payment could also help candidates negotiate and then take a cut of the signing bonus.

If this isn’t part of lambda school already I think it should be.

I already work at a competitive tech company, but I’d sign up for this in a second to help me stay competitive for interviews.

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

#95

Post by FabHK »

griffinkelly wrote: post #74
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.

I've worked with some folks who were decent engineers who originally didn't get offers from FANG companies because they blew the interview; they later studied their ass off on leetcode and got offers. This did not make them better engineers at all. Ultimately, its just studying for the test, very much like the ACT/SAT in high school. You can be great at taking tests but ultimately a terrible student or vice versa.

> This did not make them better engineers at all.

How do you know?

I understand that FANG have themselves come to the conclusion that brain teasers are not necessarily very predictive for engineering performance.

But CS/programming questions for CS/programming roles? That seems sensible.

You can study lots of vocabulary to achieve better results on the verbal section of the GRE or similar tests. But afterwards, you will, in fact, have better vocabulary, I submit.

I am surprised that you categorically deny that they were better engineers after studying CS/programming questions.

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

#96

Post by pixeloution »

ensiferum wrote: post #30
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 :-)

And here's the problem. People don't agree what's hard/easy. If I ask you to find duplicate values in a nested data structure (arrays of arrays) ... that calls for recursion. I think that's easy.

So I'm curious how they define hard/easy.

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

#97

Post by mlthoughts2018 »

castlecrasher2 wrote: post #44
rightbyte wrote: post #24

Earlier quoted context omitted.

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.

>This is kind off strange for a non US resident to grasp. I've worked for two non-technical companies as a software developer and one highly technical company, and interviewed at a few Silicon Valley companies. The difference between the interview processes is staggering; my current job's interview was two hours of conversation, no code tests, just a general assessment of "do you know what you're doing" by the hiring…

> “The SV companies must have a good reason for this”

In fact, no, nobody has a good reason for it.

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

#98

Post by marcinzm »

ashelmire wrote: post #86
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. Just fire the bad ones. You're going to get bad ones anyway. At larger companies you might never notice whether someone is good or bad. From the way they structure their interviews, it seems like they'll still get plenty of bad ones - it's just they'll get bad ones that are great at algorithms, with unknown skill a…

>Just fire the bad ones

Who and what decides what a bad software engineer is (note this is very different than deciding who is a good)? Is it a manager? Managers are single people so shouldn't be the sole deciding point. So you need to gather feedback, aggregate it and decide what constitutes bad. Then have that feedback reviewed by independent people to ensure that no one is being unfair. That takes time and bureaucracy.

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

#99

Post by coryrc »

Afforess wrote: post #64
localcrisis wrote: post #46

Earlier quoted context omitted.

Same experience with the Tic Tac Toe, then again with the rest of the interview. There were a lot of Googlable boilerplate questions (e.g. "what does malloc return?", "what's a bloom filter?") that, as a product engineer, never come up. Then there were the classic Big-O notation queries that for most use cases don't come up until much later stage. It felt like the founders were classically trained in CS and over-opti…

> "what does malloc return?" This is particularly pernicious, because it's a trick question, too. On linux, malloc always returns, it will never return NULL. Even if you ask for 4 petabytes of memory on a 128mb system, malloc will hand you back a valid pointer for the memory. https://scvalex.net/posts/6/

I'm pretty sure it will fail NULL if overcommit is disabled.

(And apparently other conditions: https://stackoverflow.com/questions/2248995/is-there-a-need-... )

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

#100

Post by FabHK »

rightbyte wrote: post #24
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.

I've been in technical positions in the UK and Hong Kong, and in both cases the interviews were very technical. Hours and hours of technical assessment and questions.
Post reply on HN