Harder programming questions do a worse job of predicting outcomes

Post by aglavine » Mon, Feb 18, 2019, 7:17 PM UTC

arnvald wrote: post #34

tomp wrote: post #22

Earlier quoted context omitted.

> 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, b…

In many cases companies don't interview all the candidates before making a decision, it's more on a rolling basis. You consider each candidate separately - you interview a candidate and then decide whether to hire him/her or not. In plenty of cases companies reject candidates who later perform successfully at similar roles, and this is the point of the parent comment. However this is kind of a desired effect, because…

Post by aantix » Mon, Feb 18, 2019, 7:18 PM UTC

Post by SilasX » Mon, Feb 18, 2019, 7:19 PM UTC

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.

Post by merb » Mon, Feb 18, 2019, 7:19 PM UTC

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/

Post by pcwalton » Mon, Feb 18, 2019, 7:19 PM UTC

gameswithgo wrote: post #56

warp_factor wrote: post #28

Earlier quoted context omitted.

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.

obscure algorithms are useful. it isn't a perfect system but its better than what most people propose as alternatives, which is to just have an ad hoc conversation. testing whether someone is willing to prepare for a thing is a relevant work skill test too.