Comment by Terretta | Hacker News Reader

Comment by Terretta | Hacker News Reader

Parent Full thread

A benefit of Triplebyte to big enterprises not mentioned in Triplebyte’s discussion here: acting as engineering assessment proxy for engineering hiring managers stuck with pathologically risk averse enterprise HR departments.

Often enterprise HR is paranoid of honestly evaluating anyone for anything, to the point that many HR teams tell one another and engineering hiring managers that it’s “illegal” to assess candidate abilities on the way in the door, at all.

If you think about joining a dev team where no one checked if any candidate could FizzBuzz, you can imagine the workplace environment that can end up with.

Triplebyte is able to provide engineering managers with a stack of pre-vetted resumes so an enterprise can interview by its lowest common denominator HR policies, while still having a prayer a team will at least be made of candidates who can code.

The value of this to an enterprise stuck in this position is hard to overstate.

Hopefully along with expanding the talent pool per this post, Triplebyte can figure out a way to get well paid for this ability to help land actual coders on actual dev teams despite enterprise HR.

The need for this is huge.

// I see a comment below from a Triplebyte PM about score matching: https://news.ycombinator.com/item?id=27542621 … That would be slick: land candidates that genuinely raise the bar, but aren’t so far ahead as to be speaking a foreign language to the team. Of course, this would require also assessing the target team, and oops, we’re right back up against that HR policy…

Good point!

There's an old quote: "Nobody ever got fired for buying IBM."

Large companies tend to be more risk-averse, so if there are two companies you can use for a service — $PromisingStartup and IBM — large companies will generally make a decision that's optimal to the specific decision-maker, not optimal to the company.

There are two options if you, as the buyer, choose either $PromisingStartup or IBM: success or failure.

If IBM or the $PromisingStartup succeed, then you've done your job.

If IBM fails, you can tell your manager "Who could've guessed! It's IBM!"

If $PromisingStartup fails, you'll have a harder time explaining your decision, and the fault will be with you.

The "Nobody ever got fired for choosing IBM" idea is useful to look at every decision large companies make, whether it's pivoting, choosing a SaaS product, or hiring.

TripleByte, in its current form, has been beneficial to candidates as well by giving enterprise employees a justifiable signal towards hiring them regardless of pedigree.

> many HR teams tell one another and engineering hiring managers that it’s “illegal” to assess candidate abilities on the way in the door, at all

From the position of a candidate this sounds like a poorly run company I'd have no interest in working for. I wouldn't want to interview with them.

But they'll pay you 4x more than the smaller, better run companies. That's why people still want to interview with them.

> If you think about joining a dev team where no one checked if any candidate could FizzBuzz, you can imagine the workplace environment that can end up with.

That sounds hilarious How could a dev team not be able to write 5 lines?

You would be surprised how many people legitimately can't wrap their heads around a fizz buzz style problem, but also how many people who can yet completely freeze in an interview setting.

This. I think most people devs, including low skill, understand Fizzbuzz, but performing on the spot is just very difficult for many people.

Its the same reason why a top notch, genious writer can turn out to be terrible at giving speeches, even if they're reading from a script.

Performing an interview is a different skill from writing code.

> Performing an interview is a different skill from writing code.

I think this is true for the day-long leetcode interviews, but to succeed as an engineer, even at the entry level, I think you need to be able to talk through how you would solve fizzbuzz. A big part of the job is communicating trade offs with other engineers.

You're not wrong, but the problem is that interviews aren't actually about jobs. The average person interviews because they need the money. So from the start they're not thinking in the programming space. The pressure for them is to make the interviewer believe they are worthy of the job.

I think if I could describe my personal experiences, I'd say that on a subconscious level, I know that how I speak and articulate details will be observed by the interviewer through a cultural lens more often than not. This may be unique to my personal background, so maybe this is different for other groups. But interviewers often get hung up on the use of different language/terminology, the types of jokes/jests that enter the conversation, how I respond to their language. And there's sometimes been an unwillingness to allow different terminology, perhaps because that's all the interviewer themselves knows and understands.

All that to say, a code interview doesn't always come down to the quality of the code.

I'd believe it.

I got shitlisted at one place for being the only dev with the mathematical insight to know that multiplying pesos by a dollars:yen ratio doesn't yield a correct conversion of pesos to yen. They let that one slide without fixing it, but the final straw that got me frogmarched was refactoring an if-else to a switch.

Sounds like a hidden arbitrage opportunity if they accept to honor that conversion rate!

Refactor to switch?? All of those break statements are evil!!

It is hilarious but man, you would be really surprised how people choke on this. It's weird. People with 10+ years writing software can't do this sometimes.

I was once accused of lying about my work experience by a $FORTUNE500 interviewer when I failed to articulate what a CSS flexbox was for a backend dev position.

Such an eye-opening experience! Now that I’m on the other side of the table these days, I understand the importance of making interviewees feel comfortable and asking questions that allow them to start off strong.

Last year I did a project for an org that has a similarly sized team of developers. They could not figure out html and css. Hadn’t heard about git. And worse is that they developed on the production server. I’m not making this shit up.

They saw me as a god for fixing their shit and offered to hire me. No thanks!

I’ve seen this claimed for multiple job pre-vetting sites and am not convinced it does anything than add an extra layer of test interviews.

Reply on news.ycombinator.com