In your first 30 days, you will take over the operation of our existing internal and customer-facing production systems. Working with product and engineering, you will assess our production operations and build out runbooks for the operation of different systems...
After 3 months...identify new opportunities for automating processes, streamlining delivery, deploying new core functionality, and building great tools. You will help make CockroachDB more friendly by bringing your expertise to our database.
After you apply, you are going to hear back from us, even if we don't seem like a good fit. In fact, throughout the process, we strive to make sure you never go more than seven days without hearing from us.
You see a lot of talk about moneyball, but for some reason people are less excited about...trainingball? Practiceball? Whatever you want to call taking people who aren't “the best” and teaching them how to be “the best”.
Programmers are woefully underutilized at most companies. What's the point of hiring "the best" and then crippling them? You can get better results by hiring undistinguished folks and setting them up for success, and it's a lot cheaper.
Great developers are raised, not hired.
I have fourteen years of experience. I’d be happy to talk about functional programming, distributed systems, consensus, replication, collaborative text editing, CRDTs, parallel architectures, UI frameworks, team processes, product design, user experience. Was I ever asked about any of those? No. What I get is “imagine you have a function that takes a list…” five times in a row.
Interviews are conducted under pretty artificial conditions, and as a result they wind up being most effective at hiring people who are good at interviewing. This is a special breed of parrot, in a way. Interviewing isn't a particularly good predictor of performance, any more than your rank in a coding competition is a predictor of real-world performance. In fact, somewhat depressingly, there's almost no correlation whatsoever.
I’m happy to discuss algorithms there [on a whiteboard]—discussing abstract things is more efficient that way. But writing programs, actual programs, in a notepad? Without even running them? What’s the point? Getting the first draft of the code is barely one-tenth of the whole process, followed by compiling, checking, tuning, testing, reviewing etc. Who are we kidding?...It’s like asking a painter to do a painting of a horse, then stop her halfway during the very first sketch just when you can see four vertical lines for legs and judge that. How much will you learn about her?
Interviewers make up their own interviews. This is crazy.
The gauntlet of tricky technical questions is just the beginning. Driven in part by an oral tradition of how the last 20 years of technical job interviews has resulted in terrible hires, interviewers try to assess for “smart and gets things done”. In other words: “subjective and even more subjective.".
You need to collect data. You need every candidate to get the same interview. You can’t make that happen if your team improvises the interview.
Most companies seem to be flying blind when it comes to their interview process. I've found that it's common for recruiters and hiring managers to not know what their processes are looking for, and almost no one is attempting to iterate on their interview processes.