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

511–520 of 540 posts

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

#511

Post by RichardCA »

sfw1k wrote: post #452
warp_factor wrote: post #309

Earlier quoted context omitted.

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…

some coders that don't get too critical about their job Couldn't be farther from the truth. As someone who works there I've noticed this general trend of animosity towards Google, it seems to be fueled by the fact that people feel a sort of inferiority complex when they don't clear an interview or they feel they wouldn't be able to crack it if they ever gave it a shot, this leads to an overcompensation of attitude in…

I think it's possible for both things to be true at the same time. Yes it's a selective meritocracy, and it's also true that the process unnecessarily alienates people. It comes down to recruiters being given the very difficult task of finding candidates for a process with such a high rejection rate, and the added stress of being given very specific rules about the things you can't be transparent about. The overwhelming majority of job seekers are mature adults who can handle rejection and constructive negative feedback. It's the sense of having wasted one's time that generates the "sour grapes" feeling.

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

#512

Post by PopeDotNinja »

kyralis wrote: post #275
PopeDotNinja wrote: post #110

> However, whether or not a candidate answers a question correctly is not the only source of signal during an interview. You can also evaluate their process by, for example, observing how long it takes them to finish, how clean their code is, and how much they struggle while finding a solution. Our analysis shows that this second source of signal (process) is almost as predictive as the first (correctness). I seem to…

As a frequent interviewer I will say that you are not alone in that: any interviewer that isn't following the above guidelines is unlikely to get a good signal from anyone. To your final point about expectations: One question that we try to ask ourselves about any particular interview question is "how may bits of information are we getting out of this?" Trivia questions are usually less than 1 - you'll find out if th…

I like the idea of extracting as many useful bits of information as possible!

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

#513

Post by [deleted] »

Zelphyr wrote: post #114
joker3 wrote: post #101

There's a problem here. The only thing that Triplebyte can claim based on their data is that easier programming questions are more predictive of performance among candidates who received an offer . Since candidates who get offers are (in theory) different from candidates who don't get offers, we can't necessarily generalize from one population to the other. There's also a question about how to mix question difficulty…

You touch on a very important part of this equation: there are good interviewers and bad interviewers. A good interviewer, in my opinion and experience, will try to get to know the person first. They'll put the candidate at ease. They want to try as much as possible to be talking to the person they're possibly going to be working with, not the anxious candidate that just walked into the room.

[deleted]

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

#514

Post by pedrosorio »

Balgair wrote: post #508
pedrosorio wrote: post #464

Earlier quoted context omitted.

"Ever since I learned that, it's never been that 'wowzers' for me." I am not sure I follow. For people who want to, there is a section where they can find answers even if they have not solved the problems. What was 'wowzers' about HackerRank before you learned that?

Well, some folks would brag about their score (years ago, dunno about now) and use that ranking as an indicator of their coding prowess. When I learned that the whole thing was easy to 'cheat' (whatever that mean in this context), then that rank lost all prestige for me.

Bragging about your rating as a function of solved problems in practice (with solutions available) doesn't seem rational.

HackerRank also used to organize contests where they would have a certain time to tackle a number of new problems (5-10 problems in 1 hour to 1 week, depending on the contest) meaning you have no access to solutions and are competing against other people solving the same problems. They have a rating for performance on those as well.

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

#515

Post by scarface74 »

mooreds wrote: post #498
scarface74 wrote: post #475

Earlier quoted context omitted.

I have no idea whether I could study hard enough to work at Google. What I do know is that I don’t like large companies and I have no desire to move to the west coast.

> What I do know is that I don’t like large companies I think this is a key thing to learn about oneself. Very large companies often have a lot of cachet and can provide opportunities that small companies cannot (scale is scale, after all). But small companies (not even start-ups, just companies with * Interaction with different parts of the business * Opportunity to wear multiple hats * Less likely to be in the Bay…

It is all of that and while after 20+ years developing professionally and developing as a hobbyist since middle school, I’ve never felt burnt out from continuously learning. But,I was burned out by big company politics and bureaucracy after only three when I was worked at a large Fortune 10 (non tech) company.

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

#516

Post by warp_factor »

RichardCA wrote: post #511
sfw1k wrote: post #452

Earlier quoted context omitted.

some coders that don't get too critical about their job Couldn't be farther from the truth. As someone who works there I've noticed this general trend of animosity towards Google, it seems to be fueled by the fact that people feel a sort of inferiority complex when they don't clear an interview or they feel they wouldn't be able to crack it if they ever gave it a shot, this leads to an overcompensation of attitude in…

I think it's possible for both things to be true at the same time. Yes it's a selective meritocracy, and it's also true that the process unnecessarily alienates people. It comes down to recruiters being given the very difficult task of finding candidates for a process with such a high rejection rate, and the added stress of being given very specific rules about the things you can't be transparent about. The overwhelm…

There is also the general attitude of Googlers//Facebookers that brag a bit too much about working at Google//Facebook as if it was the dream that everyone was looking for.

There is nothing more annoying than discussing with a Googler that tries to convince you that you should apply and work for Google.

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

#517

Post by Chyzwar »

ggggtez wrote: post #460
Chyzwar wrote: post #375

Earlier quoted context omitted.

There are more interesting things to do. Coding your side project, contributing to the opensource project, learning a new programming language or even reading random GitHub project code and issue trackers. All of these activities help to improve your programming skills more than leetcode. If I am making max for my local area and I am not willing to relocate, why would I waste time for interview preparation?

I don't know what you are replying to the parent poster at all. If you don't want to interview for a job in a new location, or for more money... then the advice to study isn't meant for you. Like, sure some people find studying fun for it's own sake, but the purpose of studying is for the interview which you just said you don't even want to do .

What I am saying that there are more interesting activities that would actually improve your skills. Leetscode and drilling interview questions are waste of time even if you are looking for a job. There are places that hire based on take-home interview, onsite pair programming or based on your portfolio/recommendation.

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

#518

Post by taylodl »

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…

Based off some of the responses here I just want to clarify some things in order to make this work.

- Yes, you have to have vetted your contracting companies. In our case that's something we'd already done (roughly 20%-30% of our staff are contractors)

- This is contact to hire, which is different than bringing on contractors for staff augmentation. The intent is to hire and the applicant is made aware of that up-front, to the extent that their employee salary is negotiated and employee benefits package is discussed.

- W2 employees jump at the chance to be given an opportunity to prove themselves in a new domain. Younger and older employees are especially attracted to this option.

- You're still doing an interview, but the nature of the interview is different since you know the contracting firm has vetted their basic skills.

- So far we've only had to let one person go, they simply never could "gel" with the team. We've had two others we had to let go as we were scammed - the person that did the interview wasn't the person that showed up to work. Yes, it happens. What we don't have is a "revolving door" situation where people are continually rotating in-and-out.

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

#519

Post by drugme »

chcknsammich wrote: post #332
drugme wrote: post #308

Earlier quoted context omitted.

No, it's called having a life and a sense of proportion. The sooner tech companies learn to embrace and work with this very basic fact, the better.

So the sooner they abandon all of their own priorities and instead adopt only yours, the better?

Let's put it this way:

"Sure, I'll consider abandoning all priorities (i.e. social life) and/or putting off others (kids) -- and maybe even take minor risks on my health -- if you you're able to appropriate compensation."

Guess what, though? In the vast majority of cases -- even when we're talking about the bulge-bracket FAANG salaries occasionally gloated about in these and other parts -- simply don't come anywhere close enough to providing that level of compensation.

All of their pretensions to the contrary.

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

#520

Post by doublekill »

chopin wrote: post #486
doublekill wrote: post #446

Earlier quoted context omitted.

If you have two great engineers in a kitchen, discussing a relevant problem, you want there to be synergy. That synergy is broken when one of the engineers has to Google how to reverse a binary tree. It is also a safe place to work for the really exceptional engineers. They can talk freely about complex computer science, without getting blank stares or having to dumb it down. Otherwise it gets frustrating fast.

One of the most valuable skills for any engineer is to be able to frankly admit the need to look something up.

Admit it to yourself. Then come prepared (to the job interview or inception meeting).
Post reply on HN