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

61–70 of 540 posts

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

#61

Post by pmiller2 »

taylodl wrote: post #31

Another solution to this problem is contract to hire. I realize this is kicking the can down the road to the contracting firm but hear me out: that's the business the contracting firm is in. They can get really good at their hiring practice since that's their core business. That's not our core business. We've been doing this for the past two years and it's worked out great. Now you can see how well people do the actu…

Why would I leave my W2 job for your contract to hire position? All I can see here is a company that doesn’t want to fire people who aren’t working out, possibly to save on benefits and unemployment insurance premiums. And why do you have so many people not working out that you have to do this? None of this inspires any confidence.

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

#62

Post by majormajor »

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.

There seems to be an assumption in these discussions that everyone has to prepare for these things in equal amount. But that's not the case.

(The counter to that is that if people can relatively-easily (single-digit days) cram for your interview, you're still not going to be effectively screening for at-hand pre-existing familiarity/knowledge.)

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

#63

Post by [deleted] »

systematical wrote: post #8

I've never been giving given a practical programming test. Nearly all are useless algorithms. Create a function that takes a integer greater than 0. Build an array equal in size to the argument. Fill the array with numbers that when summed together equal zero. It was worded far worse than that. What exactly is that telling you about the engineer? On the flip side I'm asked to code full fledged applications but not to…

[deleted]

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

#64

Post by Afforess »

localcrisis wrote: post #46
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…

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/

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

#65

Post by SpicyLemonZest »

taylodl wrote: post #31

Another solution to this problem is contract to hire. I realize this is kicking the can down the road to the contracting firm but hear me out: that's the business the contracting firm is in. They can get really good at their hiring practice since that's their core business. That's not our core business. We've been doing this for the past two years and it's worked out great. Now you can see how well people do the actu…

I'm glad it works out for you. But I would not want to work at a company where a significant number of my coworkers only last a couple months, and I think I'm far from alone in that perspective.

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

#66

Post by pmiller2 »

pps43 wrote: post #20
akhilcacharya wrote: post #9

Earlier quoted context omitted.

Easy - reverse a string, determine if a string is a palindrome, reverse the digits of an integer, determine if one string is an anagram of another. Hard - implement a subset of regex match in optimal time+space, find the operations required to turn 1 word into another word given a list of transitory words, find the median of 2 sorted arrays in optimal time, find the next permuted value.

That's more like small/large than easy/hard.

The key word here is “optimal.” These aren’t difficult tasks if you can just write down the straightforward code to do them.

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

#68

Post by bdavisx »

xiphias2 wrote: post #21
maxerickson wrote: post #10

Earlier quoted context omitted.

It's at least good that they call it a philosophy.

For me not being afraid to get kicked out of my workplace was a good thing. Also most of my colleagues were amazing, I miss talking to them, but at the same time I don't miss what the top management has become.

What has it become?

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

#69

Post by auston »

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…

I had the same tic-tac-toe q, I felt that the instructions were pretty clear: “Accomplish this one thing, as simple as possible, then generalize to actually work.” To me it felt like I was getting specs to write a class and that’s what I did.

I had a pretty great experience and would recommend TripleByte.

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

#70

Post by pmiller2 »

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.

There’s a vast difference between, say, preparing for a school exam and preparing for a job interview. In the former, you know in advance what material will be tested. Job interviews are more like PhD comprehensive exams, or professional licensing exams. I know a lot of working professionals who are good at their jobs, yet admit they wouldn’t be able to pass the license exam today.
Post reply on HN