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

181–190 of 540 posts

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

#181

Post by hotcrossbunny »

SomeHacker44 wrote: post #107
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.

Knowing the existence of, and understanding the performance characteristics of a broad range of algorithms is, to my mind, a much more useful set of working knowledge than the details of any individual algorithm. The latter can always be looked up. It is harder to find out the former and much better to say “yes, there is an algorithm such-and-such that may be applicable here, let me spend 5 minutes checking that.” In…

Broadly speaking, that used to be how design patterns were often treated in interviews. Could you recognise, describe, code, discuss pros, cons and applicability for pattern X in given circumstance. Pretty easy stuff to cram unfortunately, which may be why they may have fallen out of favour in recent times as proxy measure for brains, but depending on the role in question that sort of material was often more likely to be useful in the job than a similarly broad knowledge of algorithms

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

#182

Post by jorblumesea »

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…

I mean, this is literally how any kind of industry with a test develops.

Do you think the MCATs or the Bar exam are flawed because they have books on how to do well?

Whenever there is any kind of standardization for testing, some ecosystem will evolve around it.

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

#183

Post by chooseaname »

rpm33 wrote: post #144
mlthoughts2018 wrote: post #97

Earlier quoted context omitted.

> “The SV companies must have a good reason for this” In fact, no, nobody has a good reason for it.

Well it started off with Microsoft in the 90's, then Google in 2000's and then it just became common for every company in SV to conduct these programming interviews.

I don't see a "good reason" in your comment.

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

#184

Post by AnimalMuppet »

warp_factor wrote: post #28
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 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.

Exactly. As I said before, in a world where both Google and Knuth exist, they aren't hiring me to be a algorithm reference book.

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

#185

Post by komali2 »

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…

As verbatim as I can remember our interaction:

Me: "I'm going to just put some user input checks here, no guarantees they'll actually input X or O, yea?"

Interviewer: "Oh, don't worry about that, assume for now that you'll get X on X's turn, O on O's turn."

Later:

Me: "Normally I'd extrapolate this to a function, so let me just - "

Interviewer: "For now, just focus on getting the program to response to the next user input."

Me: "Ok... well the fastest way to do that right now is just copy paste this code down here."

Interviewer: "That's fine."

But, it turns out, it was not fine.

I felt I was bamboozled.

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

#186

Post by dilyevsky »

I’d agree but on the condition interviewer actually know ehat they are doing.

As I gained more experience (300 interviews and counting, baby) I realized that I pick up more on candidates skills that are not directly related to their performance on particular question. At this point the question itself is just a conversation starter and so it’s better if it’s simpler and more broad because it leaves lots more avenues for the conversation to go.

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

#187

Post by rajeshmr »

pmiller2 wrote: post #178
rajeshmr wrote: post #149

Earlier quoted context omitted.

Hey, i have had a couple of recruiters who have approached with this idea. Basically, the recruiter says, okay i give you a week or two for this task to be complete ( the call is basically 30 mins or so explaining the problem and getting to know the basics about me ) and then post the time alloted, a sync up to see how you have solved it and to explain the design or solution or something like that. Only a couple of t…

I still wouldn’t do it. Why should I, when I can do the entire interview process with another company with only a day’s worth of time expenditure on my end? If the task itself takes more than an hour or so, I can get to an onsite interview with far less effort than that by doing a recruiter chat and a phone screen.

Sounds fair enough :) Agreed. I have just proposed one of the alternatives which i could imagine / think of from the top of my mind. The problem isn't solved yet - or rather solved well yet. We could always brainstorm on a better alternative. :)

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

#188

Post by dudul »

misiogames wrote: post #153
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.

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.

Most workers in the US are under the "at will" regime: they can be let go at any time in theory. In practice, companies (especially big ones) usually try to "build a case" to justify the move.

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

#189

Post by pmiller2 »

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…

I’m sure it works out well for you in that the candidates that pass can probably do the job. But, you basically have lost me by the time you’re asking for more than a 20 minute recruiter call, 60 minute phone screen, and a ~5 hour onsite.

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

#190

Post by Apocryphon »

tombert wrote: post #125
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.

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…

> Not knowing when to use a hash table instead of a nested-for loop

On the flip side, the O(1) look-up nature of hash tables make them the no-brainer data structure to use, at least for passing programming interviews. Perhaps more interesting test questions would be when not to use hash tables.

Post reply on HN