Live data from Hacker News

Why Triplebyte Failed

otherbranch.com

151–160 of 282 posts

Re: Why Triplebyte Failed

#151
I've been at this business for a few minutes and can say it's not that hard to identify good candidates.

1) a native and active interest in computing 2) good english 3) good (enough) social skills

A good software team is built like a good NBA team:

1) a limited number of exceptional performance contributors, not many of these, by definition. Right tail of the normal curve. 2) Good support players with specific skills and the personality to allow your superstars to maximize their potential.

Everyone seems to be looking for 1) in the interview process because that's the gold, but 2) are extremely important to get 1) in the door and working at optimal.

Finally, you need to avoid

3) frictional team members, i.e. negative work. These are people who inject drama into the team process that does not contribute to outcome. A passionate team member who takes hard stances at times is a good thing, even if they're not always correct, because they can head off a bad outcome early in the process. However, someone who just causes drama and turmoil, or even simply breaks the team flow state, is also a big problem.

A team can easily be spoiled by 3) even when you have the perfect superstar and supporting cast because the focus turns from the product to the emotional drama, which is a huge drain.

This leads to a tangential, but important point, the current hiring mandates for modern practice are potentially catastrophic for software development teams. Inserting people onto a team who become 3) will kill a product and drive away your highest value contributors. Superstars in this field don't want drama, they tend to be introverts who are happiest quietly working on their own.

It then follows that meeting modern day hiring protocols often means pushing the equity component into the soft skills side of the company, which means your hiring pool for marketing, hr, project management is reduced to fulfill various hiring mandates. This leaves a lot of experienced, valuable people, who understand good software development because they've done it, on the sidelines because they have the wrong physical characteristics, e.g. the 60 year old who is pushed out of the tech side because of an outdated skill set would probably make an excellent project manager because they understand the SDLC from a technical and personal perspective. Who better to mentor young developers?

But those roles are often going to young college graduates who don't have that experience and just end up glamourized secretaries because they don't have the formative passion for the field.

The NBA superstar/support model works in software development. It's the only thing that creates high quality, high impact outcomes historically. It's the desire to reconfigure the schema into a social change experiment via mandated hiring that causes the complications.

Re: Why Triplebyte Failed

#152
post #135

Earlier quoted context omitted.

Seriously, if you've never hired before, you have no idea how bad this can get. Here's [1] our practice coding problem. It's quite similar to the one we use on our interview, and not too far from the one Triplebyte used in the past (ours is tuned to be slightly harder at the beginning and slightly easier at the end). The vast majority of candidates, even with some reasonable pre-filtering, do not get past the first s…

that's actually pretty great, but it brings up another issue I have with the state of tech interviewing - it focuses on being able to write code fast . the more senior you get, the more you tend to focus on depth, taking your time to think over the problem and write a good robust solution rather than banging out code fast, so coding up a solution in 25 minutes versus an hour is not really a good test of what the comp…

This is true, and it's part of why this is one section of three.

If you were slow but high-quality on the coding section but crushed the knowledge and system design, we'd probably recommend you - or at least, recommend you to clients that aren't specifically looking for fast coders. Someone we recommended to a client recently had the equivalent of like 1.75 steps on the task linked here, but got consistently high scores everywhere else.

I do wish we could do a more complex, longer coding problem, and one of the things I've been considering is cutting some other stuff to get it up to 45 minutes or something. The current length isn't a principled decision, it's a resource constraint - keeping interviewing costs manageable is essential when you're trying to bootstrap a company in a rough market. Speed matters, but speed over such a short timescale is absolutely artificial (I'd much rather measure speed over a day instead, it's just not practical to conduct a top-of-funnel interview for so long.)

Re: Why Triplebyte Failed

#153

Earlier quoted context omitted.

Seriously, if you've never hired before, you have no idea how bad this can get. Here's [1] our practice coding problem. It's quite similar to the one we use on our interview, and not too far from the one Triplebyte used in the past (ours is tuned to be slightly harder at the beginning and slightly easier at the end). The vast majority of candidates, even with some reasonable pre-filtering, do not get past the first s…

That actually looks pretty good aside from the time limit.. It takes me a while to 'get in the zone' - and especially with you base datastructures you wanna think about it a bit as it has real ramifications on how hard/easy everything else can be. Still, seems better then most of the 'leet code' type stuff I see :-)

Yeah, the time limit is an interviewing constraint, not a principled decision (see my reply in a sibling thread to this one).

Re: Why Triplebyte Failed

#154

Earlier quoted context omitted.

Oooh, this lets me tell a great anecdote that didn't have a place in the post. So it turns out you were not alone. Getting people who did well on the quiz - whose parameters were trained on interview performance, by the way, so "did well on the quiz" was synonymous with "had a good shot at the interview" - to sign up for interviews was a major problem for a while. The solution? We told them the first booking was just…

this is some straight up Ender's Game shit

That made me actually laugh out loud. Maybe we should try for some Last Starfighter growth hacks.

Re: Why Triplebyte Failed

#155

It's interesting to see how much "standardized cross-company interview for software eng" has been consistently a cursed problem in the industry. Unlike airline pilots (or I'm certain many other professions), every company in the valley insists on re-interviewing a candidate in their own custom and unique way, instead of trusting some sort of an industry-wide certificate only achievable through a standardized test. Wo…

The problem is that software development is less like hiring an airline pilot or a structural engineer, and more like hiring an artist. Try making up a "standard exam" that will tell you whether an artist will produce several great unique works for you in the future, so you know which one to hire...

Re: Why Triplebyte Failed

#156
post #103
post #35

Earlier quoted context omitted.

If you create a standardized test it will be gamed. Even with the small modicum of standardization around interview questions that we currently see, people have published books like Cracking The Code Interview, making it easier for people who don’t have the skills for a particular job to pass interviews at any place that uses standard-ish questions. Furthermore, as an avowed enemy of “Clean Code”, I don’t want to see…

Just out of curiosity, what are some of the problems with "Clean Code"? I thought most of it made sense as basic guidelines. It's been a while since I read it though

In my opinion, the only significant contribution Clean Code made was the concept of clean code. The problem is that my definition of clean code is almost completely contradictory to what the author of the book thinks constitutes clean code.

Re: Why Triplebyte Failed

#157
post #100

Earlier quoted context omitted.

I'd say it's the exact opposite. There are hordes of unqualified people applying to every software dev role imaginable regardless of what you put in the job description or requirements. The tests are there because people are good at lying but bad at faking skills.

Seriously, if you've never hired before, you have no idea how bad this can get. Here's [1] our practice coding problem. It's quite similar to the one we use on our interview, and not too far from the one Triplebyte used in the past (ours is tuned to be slightly harder at the beginning and slightly easier at the end). The vast majority of candidates, even with some reasonable pre-filtering, do not get past the first s…

That was a fun coding task. Minor bug in the illustration of Step 4: the mine count in second row should be 8 not 4

Re: Why Triplebyte Failed

#158
post #155

It's interesting to see how much "standardized cross-company interview for software eng" has been consistently a cursed problem in the industry. Unlike airline pilots (or I'm certain many other professions), every company in the valley insists on re-interviewing a candidate in their own custom and unique way, instead of trusting some sort of an industry-wide certificate only achievable through a standardized test. Wo…

The problem is that software development is less like hiring an airline pilot or a structural engineer, and more like hiring an artist. Try making up a "standard exam" that will tell you whether an artist will produce several great unique works for you in the future, so you know which one to hire...

That's an interesting point, but then one wonders that if software eng are ultimately artists, why are we not having them work on their portfolios like the other art disciplines? Is that the fundamental problem?

Re: Why Triplebyte Failed

#159
post #155

Earlier quoted context omitted.

The problem is that software development is less like hiring an airline pilot or a structural engineer, and more like hiring an artist. Try making up a "standard exam" that will tell you whether an artist will produce several great unique works for you in the future, so you know which one to hire...

That's an interesting point, but then one wonders that if software eng are ultimately artists, why are we not having them work on their portfolios like the other art disciplines? Is that the fundamental problem?

> why are we not having them work on their portfolios?

Who is having whom? Having a portfolio of work is a well understood benefit, and a lot of candidates have been doing it for some time.

Re: Why Triplebyte Failed

#160
what I haven't seen mentioned in the comments is that Triplebyte had so much funding to just have a database of 250k users / engineers.

Yeah, at that scale bootstrapping would've been the way to go.

Post reply on HN