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 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.