5 ms·

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

by joeld42 11y ago

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 11y ago
> 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 11y ago
  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 11y ago
    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.

by joeld42 11y ago

NhanH 11y ago

> 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 11y ago
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 11y ago
  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.