Hacker News Reader

Comment by Harj | Hacker News Reader

When we started Triplebyte, we'd thought there would be pretty much a straight line from being a bad to great programmer and we'd just have to figure out where to put the cut off when deciding whether to work with an engineer. The biggest surprise has been just how much disagreement there is amongst companies on what a "great engineer" actually means.

That's when we realized we were actually working on a mapping problem and the first step was figuring out a universal set of criteria that all companies care about. Then if we could assign the right weight for each attribute to specific companies, we could route engineers only to companies they'll be a strong technical fit for.

It'd be great to get thoughts on the criteria we chose and experiences from engineers who have done a lot of technical interviewing,

View on HN

To make it even more complicated, most companies might not even know what they need. The classic example is algorithms: many companies will say they care about algorithms, but few of them actually need those skills.

"Back-end web understanding" seems oddly specific compared to everything else on that list.

Why that and not something more general which might encompass other kinds of domain-specific knowledge? There are a lot of companies on your list which seem like they might care more about other skills that don't really fit anywhere else. (Experience working with databases for example, for one of the 7 or so database companies.)

I assume the (very broad) criteria listed on the blog are supersets of very specific sub critera. Maybe if you could elaborate on what exactly those sub critera are, it would make things clear.

We have specific guidelines / process that we use to measure each. For example, professional coding is a focus on writing clean code, that is well designed on the micro level (good names, good modularity on the function / class level), and good testing. We measure this using a rubric as we watch each engineer code. Low-level understanding is knowledge of how computers work, under the hood (bits, bytes, character encoding, operating systems, networking, etc). Again, we have a rubric (and these topics are covered at multiple points as each engineer goes through the process). Our measurements are not perfect, but companies really do vary widely in how much they care about different areas (understanding how computers work say, vs. having a great coding process). By mapping this and matching we save everyone pain. No one had tried to do this before, and I am pretty excited about it.

I recall part of the Triplebyte screening process was to implement a solution to a whiteboard-type problem under a time constraint. It occurred to me that not all companies would necessarily place heavy weight on solving whiteboard problems in the interview process, yet Triplebyte seemed to filter applicants right out of the gate based on this measurement. I am curious if the genome project will alter this aspect of the screening process?

I went through the Triplebyte process (to the end) and did not ever implement a solution to a whiteboard problem under a time constraint.

If I recall correctly, I was asked to implement a solution to a combinatorial problem within 1 hour.

I went through the triplebyte process twice; once in the take-home project track and once in the "normal" track.

Their feedback to me on the take-home project track was "we thought you did a great job; very impressive. But you interview so poorly that we decided not to move forward." I don't see anything to do in response to that other than to keep trying to interview, so I tried to do the "normal" track.

It was entirely time-constrained, supervised whiteboard problems.

Reply on news.ycombinator.com