[joeld42]

I ask whiteboard coding questions not because I care if the applicant can do some trivial task, but basically to gauge familiarity. Someone who writes code in a language every day for their current job should not have any trouble expressing a simple algorithm on a whiteboard. It's a screening question, and for someone who knows what they're doing, it shouldn't take more than 5-10 minutes. Once that's out of the way, I talk about their body of work, problems they've solved, etc.

The problem is there are a lot of people who didn't do the work but were around for it. They went to all the meetings, they can tell the war stories, they know the jargon, but they just didn't write the actual code.

As for your question about github profile, the problem is that you can't really tell how much work someone did themselves. I'm sure you wouldn't misrepresent your work on github, but people do. People outright lie. They are probably not even being malicious about it, they just don't have a good sense of their own coding ability and feel like if they just post something that they "could have" written.

One applicant who I really liked really struggled writing code on a whiteboard. He described some projects that he had built himself for university, and that sounded really interesting and reasonably complicated. So I took a look through those, hoping that he was just having a bad whiteboard day. But unfortunately it just confirmed, he was smart, creative but just didn't have a lot of practice writing programs. The code was a mess, it did bizarre and roundabout extra steps to do simple things, and from the timestamps, represented months of work for things that should have taken days. I did admire that he was tenacious and didn't give up, and in the end he build something cool but just didn't have enough practice to write production code without supervision. I would have wanted to hire him for an internship, but that wasn't was we were looking for.

[NhanH]

> I ask whiteboard coding questions not because I care if the applicant can do some trivial task, but basically to gauge familiarity. Someone who writes code in a language every day for their current job should not have any trouble expressing a simple algorithm on a whiteboard. It's a screening question, and for someone who knows what they're doing, it shouldn't take more than 5-10 minutes.

It's not that simple for people who really can't interview. I am one.

Last week, I did an interview with Triplebyte, and I got to pick essentially an AI for Tic-tac-toe game. I know that I can brute force the game state with a recursion. I know how to write a recursive function: an exit condition, a loop for recursive along with rollback and retry. The problem is when I'm actually writing the code, my mind blank out on any and all details: I know there is an "if" there, what it should check out, but I can't put the actual condition in my mind (is it "x == y" or "x!=y" or "x==1"). So I'm screwed

I know I can write the actual code, because I was able to do that right after the interview is done.

[devplusplus]

The ASCII spiral one was from Triplebyte as well.

The problem with the task is that you can demonstrate decrementing counters, recursive functions, and familiarity with the language, but if you don't solve the specified problem in a constrained timeframe, you fail. (My feedback was basically "You clearly know how to code, but you didn't solve the problem.")

One of the problems with the Tic-Tac-Toe AI scenario is that you have to figure out an algorithm to win at Tic-Tac-Toe. (If I recall correctly, one of the requirements is that it beats you.) I know how to play -- but to win every time? I'd have to formalize an algorithm, then convert it into working code, within a strict time limit with someone watching over my shoulder. I can do it, but probably not in 30 minutes. It'd take me 30 minutes to set up my 2D array and accept input to populate the board.

That's not how my day job works. That's not how any programming job works.

When I get a problem at my day job, I know the entire domain. I know who my customers are, I know the problems they have. If my day job were Tic-Tac-Toe, I'd know everything there is to know about how to play and win, and then it's a formality to convert that into code.

If you really want to go with the coding exercise thing, you can't focus on the "right answer." Whether their tic-tac-toe program wins every time is irrelevant. What's relevant is that they jump straight to the notion of a 2D array, that they know how to do recursion or for-loops. What's relevant is that they can write code without too many syntax errors, that they're comfortable, and that they make progress throughout the time alotted. Whether they actually cross the finish line is irrelevant at best. It's a red herring.

In the end, do you want to know if I can code, or do you want to know if I can write a winning Tic-Tac-Toe algorithm in 30 minutes? Those are two different answers -- just because I can't do the latter doesn't mean I'm not qualified. I just means I didn't pass your test.

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

[Harj]

Thanks for interviewing with us. We know interviews are stressful and we try and account for that by offering a selection of different problems. Also, if we think someone is freezing from nerves, we’ll offer them a problem to do on their own time after the interview before making a decision. We know we can continue doing more and want to run more experiments around this for our next batch of applicants.

What's interesting to us in this specific case is that you actually did great during the interview. We've done hundreds of them in the past few weeks and we're really excited to talk with you again for the second round.

[NhanH]

Just to be clear, I think that interviewing with Triplebyte was the best experience in interview I've done so far, and I would definitely recommend Triplebyte impromptu for anyone looking for job. I vow to never interview with Google again, and I'd definitely try again with you guys if I bombed the interview.

The questions, despite certain drawbacks, are quite reasonable in term of scope and requirement. And I guess the biggest difference is in the interviewer attitude: "finding strengtha rather than weaknesses" and actually care about the interview itself. I don't know if it will translate into successful hire, but certainly leave a much better impression on the candiates.