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

411–420 of 540 posts

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

#411

Post by oneepic »

warp_factor wrote: post #309
drblast wrote: post #273

Google recruiters call me a lot. I think I'd do a good if not stellar job working there. I've passed multiple FAANG interviews and been very successful as a senior developer. In my email I have an "interview prep packet" from them that essentially tells me to brush up on algorithms and read Cracking the Coding Interview to prepare for their interview process. I'm fairly happy in my job. If they offered more money or…

You wouldn't be a good fit for Google. With their algorithmic interviews that require college-grad level of studying, they filter for people that are ready to follow orders without complaining. That's who they want to hire at the end of the day: some coders that don't get too critical about their job and do what they are asked to do, even if it is repetitive, stupid and doesn't really make sense (such as re-studying…

[citation needed]

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

#412

Post by neilv »

glangdale wrote: post #266
on_and_off wrote: post #161

Earlier quoted context omitted.

It is a perverse effect on the profession as a whole. In the silicon valley I have a fair amount of colleagues that expect of any dev to spend a fair amount of their free time grinding on even more dev. No surprise that there is a lack of diversity in the profession as a result.

I'm pretty sure it's age discrimination plain and simple. The only time in my life I would have been in great shape for the standard interview process without a good deal of study was a couple years in early graduate school, where nearly all of this "breadth" stuff was fresh in my mind. The relentless scepticism about people's achievements is to some extent understandable (we've all run into the senior person who can…

By accident or design, the "coding tests" seem to discriminate in favor of new grads (with CS 101 fresh in mind, and also willing to grind yet more artificial test-taking prep), and also have a component of hazing/negging, especially when administered to experienced people. (Asserting an imbalanced power dynamic from the start, and perhaps also exploiting a psych weakness, like "I'm jumping through hoops for this, so this must be worth jumping through hoops for." I'm sure most individual interviewers are of goodwill, and don't intend this, but that doesn't mean it's not present.)

Lately, I decline to interview with any company that requires new-grad coding tests for experienced people (especially if they require it even when the person has open source code and community participation that the company can look at). I usually do well, but even then, it leaves a bad taste.

Of course, I'm very happy to talk each other's ears off in energetic collegial discussions about engineering problems and technologies, including whiteboard brainstorming of approaches/algorithms, perhaps much like would be a part of everyday work. If anyone ever then interrupted, "Hold on, can you put in all the semicolons, so I can type it in, and make sure you know how to code," you might wonder how that's not already obvious to them, and where they're coming from.

This aversion to "coding tests" for experienced people seems to be more acceptable to small companies/startups (or small autonomous units in large orgs), than it is to less-flexible/agile large companies. Recently, after discussing my latest background with a nice FAANG recruiter, we had a good discussion about the company's practice of putting experienced people through what seemed like a new-grad vetting/hazing process, and why that's been a turn-off. They soon sent a followup email, including a quote from an engineer there saying "... I need to know whether you can code in a language," along with attachments on how to prep for their new-grad coding tests. :) For whatever reason the company insists on that process, it seemed like it probably wasn't on track to a professional relationship that I'd want.

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

#413

Post by musicale »

drblast wrote: post #273

Google recruiters call me a lot. I think I'd do a good if not stellar job working there. I've passed multiple FAANG interviews and been very successful as a senior developer. In my email I have an "interview prep packet" from them that essentially tells me to brush up on algorithms and read Cracking the Coding Interview to prepare for their interview process. I'm fairly happy in my job. If they offered more money or…

"I've made a career fixing a ton of horribly shitty, inefficient code that's been produced exclusively by people who pass these interviews."

Well, the interviews are marginally effective at identifying new CS grads (who also are cheap and have few outside commitments - companies love this!) but not much else. You're exactly right to view it as an algorithms final exam or an algorithm puzzle contest, but Cracking the Coding Interview is an embarrassingly bad book, in spite of (?) its ostensible purpose of helping people study for algorithm puzzle interviews at Google, Facebook, etc..

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

#414

Post by kappi »

Another use of these kind of interviews is age discrimination to filter out of older candidates who don't have time or motivation to prepare for this BS. This is just another fad.. In late 90s there was fad for MSFT style puzzle interviews..then it went out of fashion.. this will also go out of trend.. just wait for couple of more years.

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

#415

Post by kyralis »

pcwalton wrote: post #392
kyralis wrote: post #260

Earlier quoted context omitted.

If you're trying to find a situation where that exact solution is going to be useful, you're not thinking about the problem from the right perspective. Handled correctly, a problem like this answers several questions: 1) Can you correctly break down a problem like this into its components parts? 2) Can you recognize the overall class of problems that this falls into? 3) Can you transform this specific problem into th…

If it's true that this type of problem is relevant (I doubt it), then why not ask about a specific problem you've actually had to solve? I don't do many interviews anymore, but I used to, and I had no short supply of problems that I actually had to solve in the course of my work that I could ask about. I don't think whiteboard interviewing is great in general, but if you're going to do it you can at least try to keep…

Setting up the same problem in terms of trait matching for Rust is quite a bit more difficult than this toy problem when you're in a limited-duration interview setting. All of the time that you spend laying out the problem is time the candidate doesn't spend solving it, and time you spend not getting a signal. The simpler the problem setup the better, in my experience.

I've done the "ask a real problem that I've solved before" thing, and I find that it usually gets hung up on details and context around the problem to the detriment of actually solving the problem at hand. That's not to say that such a conversation isn't itself very valuable, but that's a different interview conversation, at least on my team. We find it important to maintain some level of focus just to ensure that we're covering the various signals that we'd like to get from the candidate.

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

#416

Post by vkou »

riskneutral wrote: post #353
tombert wrote: post #125

Earlier quoted context omitted.

I go back and forth about how I feel about doing heavy algorithm/data-structure stuff in interviews. On the one hand, I have never once written any kind of sort algorithm or LRU cache by hand for a production system, because why would I? Pretty much every language's standard library has a fairly-optimized sort and caching thing built in, and if they don't then there's still probably a million outside libraries to do…

> On the other hand, I genuinely do feel theory is really important. While not knowing the minutia of a tim-sort doesn't indicate that you'll be a bad engineer, not knowing the runtime efficiency of a sort can lead to some really awful code. OK but why don’t these interviewers ever ask “internals” questions? How does a CPU works, or what the different levels of memory hierarchy are, what an interrupt request is, what…

> In my experience, no interviewer has ever asked me these questions

Because not everyone writing Java code has had a background that exposes them to compiler internals or grammars and parsers.

But everyone writing Java code should at least be a little bit arsed to figure out what common data structures do - or how to write two for loops that print out "1 2 fizz 4 buzz"...

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

#417

Post by kragen »

mlthoughts2018 wrote: post #372
kragen wrote: post #358

Earlier quoted context omitted.

Are you talking about TripleByte exams from experience, or are you speculating that they are similar to other software interviewing processes? The questions they asked me covered what I think of as a staggeringly wide range of knowledge, including sysadmin stuff, detailed knowledge of four or five programming languages, POSIX semantics, high-level scalable systems architecture, and so on. It seemed to me that it woul…

Maybe we just see it differently, but I’d consider everything you’ve listed as exactly the sort of stuff that just gets memorized. I don’t even think the breadth of what you listed is that bad actually. Especially for recent grad brogrammer types with no serious life obligation time commitments, memorizing an entire program of study like that is probably only an investment of ~1 month of time, and has practically no…

I agree that any one of the questions could have been memorized, but it seems to me like it would take a year or two of constant memorization, like more than 8 hours a day, to get all of it, even assuming there was a place that had the relevant information conveniently formatted for memorization — which, as far as I know, there isn't. But maybe I'm just bad at memorizing things?

I note that you didn't answer my question. Have you taken the TripleByte exam or not?

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

#418

Post by thedufer »

1000units wrote: post #72
gameswithgo wrote: post #56

Earlier quoted context omitted.

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.

The elephant in the room is that it's a surrogate for an IQ test, since those are illegal.

It is not illegal to use IQ tests as part of a job screening (in the US). It is illegal to screen in a way that is both discriminatory and not proven to correlate with job performance, but that applies equally to both IQ tests and algorithms questions.

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

#419

Post by fancyfish »

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.

What's more, it's funny reading that Google sends out prep packets saying to learn/relearn these algorithms. So they don't expect their recruits to know them, just be able to memorize them for the interview.

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

#420

Post by pcwalton »

kyralis wrote: post #415
pcwalton wrote: post #392

Earlier quoted context omitted.

If it's true that this type of problem is relevant (I doubt it), then why not ask about a specific problem you've actually had to solve? I don't do many interviews anymore, but I used to, and I had no short supply of problems that I actually had to solve in the course of my work that I could ask about. I don't think whiteboard interviewing is great in general, but if you're going to do it you can at least try to keep…

Setting up the same problem in terms of trait matching for Rust is quite a bit more difficult than this toy problem when you're in a limited-duration interview setting. All of the time that you spend laying out the problem is time the candidate doesn't spend solving it, and time you spend not getting a signal. The simpler the problem setup the better, in my experience. I've done the "ask a real problem that I've solv…

I am not at all confident that I would be able to answer Knights on a Keypad to your satisfaction, due to some combination of nervousness and time pressure. I probably could if I did many hours of interviewing practice, though. Absent that, I think there would be a good chance you would reject me on the grounds that I don't know how to do memoized graph traversals, despite the fact that I'm in a small minority of programmers that have shipped memoized graph traversals to production (and in fact a few teams at Google rely on my implementation of memoized graph traversals, ironically enough).

My view is that Google's interview process seems to work because Google gets so many applicants that they can afford to randomly reject most of them. It's not because it's a good process.

Post reply on HN