[ammon]

Hey, another Triplebyte founder here. This is something we've talked a lot about. To set a balance, we talk to people about a project that they've worked on in the past, and also have them pick a problem from a list, and work on it with us over screenshare. I'm sorry this did not go well for you (I'm curious to look at our notes from your interview, but I don't know who you are).

We're focusing on being consistent and fair. I understand (and am sorry) that we mess up and miss good people. But looking exclusively at experience creates other opportunities for errors (I believe more opportunities). We don't require perfection on any of the problems. We're looking for process, and try to help people (for example, on both of the problems mentioned, we generally talk about good approaches before the person starts coding). But again, we definitely mess up. Sorry about that. We're trying to do it less as we improve the process.

[RogerL]

How is it fair to ask somebody to program tic tac toe? I promise you you'd shit your pants it you tried to do the programming I am currently doing (matrices with 1/2 million element diagonals, optimal estimation, and more linear algebra goodness), yet I haven't got a clue how to start a tic tac toe problem.

Now I realise it must be something fairly trivially obvious, but it is not coming to mind at the moment. So, I'm screwed. I don't write tic tac toe games at work, I don't write them for fun, and I don't write that sort of thing for the most part. I'd probably try for a backtracking algorithm, but that is easy enough to mess up in an interview situation.

Throw in a 'helpful' comment or two if I seem to be off track and now I'm sitting there trying to figure out if my idea is wrong, if it is right but the interviewer is not looking for that approach or perhaps doesn't understand it, and so on. It just sounds miserable. Of course, if I had just done another interview with tic tac toe, failed, then googled it, I could probably just write it letter perfect for you, but I'd act like I was puzzling it out to impress you. What have you learned from that charade? Or another person just graduated from a boot camp where they programmed nim, towers of hanoi, and other stuff, and quickly scratch out a half working example. That person is going to do better than somebody that can read research papers, implement them, prove the correctness of their implementation, work with hardware, design circuit boards, develop a robust software suite that is testable, extensible, and fast, delivers on time, and doesn't waste time over-engineering things. Who do you want on your team? And who is 'tic tac toe' going to select for?

[RogerL]

Ah, and I googled it. Perhaps it isn't that intrinsically hard, you don't need a decision tree or anything, but here also is a 28 page (28 page!) chapter from a book from a Professor at Berkeley on implementing tic tac toe.

https://www.cs.berkeley.edu/~bh/pdf/v1ch06.pdf

Well now I can pass your interview. Did I become a different person in 30 minutes?

[devplusplus]

Just for your notes, I did not get a "good approaches" discussion. We just jumped straight into it. So much for consistency?

I don't really want to go any further in public. I already sent you my feedback (and received no response, for whatever that's worth). Good luck in your future endeavors, and thanks for your reply.