Blog of Otherbranch, a technical hiring service started by former Triplebyte staff, about interviewing and hiring software engineers.
HN discusses it in threads about engineering hiring, where commenters recommend it as a Triplebyte replacement and compare it to similar recruiting businesses.
1. Use a TripleByte replacement (e.g. https://www.otherbranch.com/) to filter out obviously bad applicants. Basically, job-seekers do a long set of interviews, and if they pass, are considered generally competent.
2. If you get a lot of generally-competent employees after applying reasonable filters (e.g. matching skillset, expected salary), don't give them a long automated test, pick a smaller set randomly. All of them have demonstrated competence, and the likelihood that the test will give you more the more competent employees is offset by the likelihood that they'll move forward with applications more respectful of their time.
3. Do final-stage (human) interviews with the small set of employees, where you test specific skills relevant to the job. Here you can also throw a couple general-skill questions to ensure the applicant really is generally competent; it's not disrespecting their time, because it's part of the interview time and you're spending it as well (maybe it is if the entire interview is especially long, but then you're wasting also your own time).
The important part is 1). Otherbranch may not be good or popular, but at least if/when employee supply falls below demand, "mass interview" seems like something employers will need to filter out bad applicants without wasting good applicants' time.
I've been thinking about how we assess software engineering skills, and I'm curious about others' thoughts on using open source contributions as a primary metric.
My hypothesis is that real-world collaboration and communication skills, as demonstrated through open source work, are more indicative of a developer's capabilities than typical coding quizzes. (I tried OtherBranch's sample coding problem mentioned at their post, https://www.otherbranch.com/practice-coding-problem, and got this opinion.) With the rise of AI tools, I believe the ability to effectively use these to enhance one's contributions is becoming increasingly valuable.
For those who hire or work with other developers:
1. How much weight do you give to a candidate's open source contributions?
2. Do you find that strong open source contributors tend to be better collaborators?
3. How do you balance assessing technical skills vs. communication/collaboration abilities?
I'm working on a platform to facilitate this new assessment with personalized LLM support. So I'd love to hear your experiences and thoughts!
> [1] https://www.otherbranch.com/shared/practice-coding-problem
Minesweeper?
Huh.
No wonder the PhD candidate who was supervising us was surprised I did that as a fun little side project in my first or second year at university.
Still, I'm not absolutely sure I'd have gotten to the end of step 5 (correctly working flood-fill) within 25 minutes despite having implemented the whole game in Java, REALBasic, and JavaScript over the years.
On the other hand, that's probably good. 25 minute coding challenge where you're not even expected to get to the end as per the instructions* is much better than "take this, do it over the next week, might take you 8 hours, we'll spend an hour talking about it" as I've been seeing.
* "Very few people will finish the full problem. You do not need to complete every step to pass our interview."
Not sure if anyone from Otherbranch will see this but there's a tiny error in the description part of the coding problem on this page:
https://www.otherbranch.com/practice-coding-problem
Under step 2, the description says:
> If the selection is not a mine, > but has adjacent mines in one of the squares next to it (including diagonally), > change that square to display the number of mines adjacent to it. However, the example output alongside it shows a square that is changed to the value zero. That square has no adjacent mines, so if the description were correct it would not have changed value.
So either the "but has adjacent mines" clause should be deleted from the description, or an additional "otherwise change that square to display zero" clause should be added, or the example output should be changed.
Location: Melbourne, Australia
Remote: Yes
Willing to relocate: Yes (mainly Berlin or London, others possible)
Technologies: Rust, TypeScript, SQL, C++, C, assembly (x86/amd64), Linux (userspace and kernel), Windows (Win32)
Résumé/CV: https://docs.google.com/document/d/1ORFmNslCPkyc7marEIWJVTRwr0MhByTUDyrlayQuxaM/edit?usp=sharing
Email: mak.andrlon@gmail.com
I'm an ex-Google software engineer with a PhD in computer science. I excel at technical challenges. Experience all the way up and down the stack, from bare metal, to kernel, to userspace, to desktop apps, to web dev.
Experienced with working in distributed teams.
Looking for full-time, part-time or contract work.
LinkedIn: https://www.linkedin.com/in/mak-andrlon/ Otherbranch interview report: https://www.otherbranch.com/open-candidates/lojkq
I don't know anything about the story of Otherbranch's business (they launched ~about a year ago†), but Patrick, Erin & I briefly worked on a firm with similar business dynamics (Starfighter, a contingency recruiter based on CTF qualifiers). The prospect of eventually writing posts like this is part of why that business got wound down.
I think the points in this post are mostly all well taken, but I also think a hiring manager looks at this and says "yes, this a vendor talking their book". Most of the relationship between a recruiting firm and a tech company is a disagreement about what the threshold for a viable candidate is!
† https://www.otherbranch.com/shared/blog/rebooting-something-like-triplebyte