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

151–160 of 540 posts

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

#151

Post by paul7986 »

darpa_escapee wrote: post #115
paul7986 wrote: post #29

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.

What, you couldn't derive a solution in a vacuum from first principles? I bet you think referring to API documentation isn't cheating, too!

Hmmm hard decipher your comment.

But, that interviewer is the type of developer I don't want to work with. A know it all who only acts like he knows it all and uses Google secretly. Who puts others down to make themselves look good. AKA an insecure P word I want nothing to do with.

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

#152

Post by rajeshmr »

thoman23 wrote: post #136
rajeshmr wrote: post #128

You realize that this approach is flawed the moment there are blogposts / books ( e.g. Cracking the coding interview ) on how to crack it. The how to crack 'x' becomes a field altogether ( coaching / youtube videos / blogs / books etc ). Also, platforms like hackerrank are adding fuel to fire. I read the CEO write somewhere that he wished the below "were taught in schools : 1) Communicating complex ideas with clarity…

> "A couple of weeks of work with a task being assigned" lol, OK

Sorry that didn't resonate with you. But i have replied to another comment explaining the idea further, do read it. Thanks for your reply.

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

#153

Post by misiogames »

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.

true that, and I wonder, based on the little info I've about employment in the US, it's so expensive to fire someone once you realize they are not a good fit? Even in my country (Arg), that has huge amounts of protections to workers, the first 3 months are consider trial, so you can fire someone without additional cost of the payed salaries.

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

#154

Post by Waterluvian »

The thing that bothers me about these questions is that there isn't a shortage of practical questions to ask that will test if the candidate can truely contribute to the real problems you're trying to solve.

"Right now our roboticists use a hacked together QT based GUI to manage customer robot fleet data. It takes 1-10 minutes to load on a slow network and is hard to add more features to. I know you have far less information than you'd want but walk through your thought process for how you'd replace this system over the next 12 months. We can make assumptions."

And then the next 15 mins can be an organic conversation about the problem space. You can direct the conversation into corners most relevant to their potential role: "you mentioned using web tech because we discussed how all usage is across the internet. Can you talk about the merits of Http vs. websocket?" "How would you ensure that we don't accidentally take every single customer offline if we centralised our data store?" "What kinds of UI technology would lend itself to robot mapping? Can we just use Google Maps?"

If you really need to dig deeper into technical prowess, find something relevant in your conversation and dig deep into it. "We talked about saving changes to floor layout. Can you whiteboard/laptop how you might implement undo/redo for floor elements?"

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

#155

Post by bunderbunder »

nybblesio wrote: post #117
Zelphyr wrote: post #76

I see one aspect of this trend of asking programming questions that require a lot of memorization: We have had for the past ~10-15 years people in the workforce (and thus acting as interviewers) who went through a public education system where heavy emphasis was placed on passing tests that required a lot of memorization. I'd be interested to know how many of these interviewers actually think they're able to identify…

So much this. I've been programming for 30+ years. My brain only has so much cache space and it dumps frequently. Asking me questions that clearly are testing my ability to hold large amounts of data in my meat computer isn't testing my ability to design and write computer programs. Sure, I'd love to have a "mind palace" like Sherlock. Alas, I do not. I often admit this as early in the interview process as possible t…

If anything, it's testing your ability to misdesign computer programs.

I hate working on software that was written to be read by an audience with perfect recall, because, as a human, I just don't have that. Give me code that assumes I have the memory of a goldfish, and can't keep track of anything that isn't right in front of my face.

I'm pretty sure that's what half of Dijkstra's papers were trying to say, weren't they?

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

#156

Post by seanmcdirmid »

high_derivative wrote: post #147
seanmcdirmid wrote: post #138

Earlier quoted context omitted.

Many interview processes generally paint the company in a grimmer picture than it actually is. So I would do additional research than turning down an offer because of a bad interviewing experience. Of course, you are completely in your right to do so, but it might not be the most optimal behavior. Usually, interviewers are just bad at interviewing and aren't really aware of what proper behavior is. It actually isn't…

Oh I won't turn down the offer, as said, I have no choice and it would be an irrational career move to do so. The ultra-negative interviewing experience just completely changed the mindset with which I will go into that job. This then got me thinking about the hidden cost of a negative interviewing process.

Sure, but in general all of the big company interviewing processes will convey the similar amounts of dread these days. They are so worried about false positives and have so little concern about false negatives that they push many candidates away simply by not focusing enough on the "why should I work here" part of the interview.

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

#157

Post by austenallred »

gonehome wrote: post #94
griffinkelly wrote: post #74

Earlier quoted context omitted.

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…

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

It’s part of classes for our existing students, but it isn’t a single offering. One day.

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

#159

Post by [deleted] »

wiremine wrote: post #132

At my consultancy we recently streamlined our interview process: 1. Phone screen which takes 15 or 20 minutes. 2. The candidate fills out an essay, including showing us some code they're proud of. 3. If the essay ticks the boxes we conduct a 1 hour on site interview. We use the same a set of questions for every candidate, so the investment is easy to manage, and our team has a shared set of expectations on what is go…

[deleted]

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

#160

Post by acb1990 »

gonehome wrote: post #94
griffinkelly wrote: post #74

Earlier quoted context omitted.

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…

App Academy was working on something like this, last time I checked. I believe it's more focused on people who've already been through their program working on getting the next-step-up job from their first so I don't know if it's generally advertised/ available
Post reply on HN