3 ms·

> Don’t believe the one-size-fits-all interview process with whiteboarding problems. These serve to grind away your individuality and make you feel like an asse

> Don’t believe the one-size-fits-all interview process with whiteboarding problems. These serve to grind away your individuality and make you feel like an assembly line worker. In my experience, the interview process with whiteboarding problem can go one of two ways. One of them is the "find what we think is the textbook solution to this toy problem" way. The other is the "communicate to us as you attack this toy problem so that we can understand your thought processes, problem-solving approaches, and your experience with these topics" way. Only one of these is really objectionable.

MCRed 11y ago
I think both of them are, because none of the problems are really good for explaining your thought process. In fact, it is a contradiction to try and think about a solution to a problem and to give a dissertation on how you're thinking about the problem. You can do one or the other, and in the latter case you have to have solved the problem previously. What I do is ask people about a problem they have solved and get them to teach me about it. If I learn something then it's a good result. Asking people to solve a trivial problem AND let you into the inner workings of their brain-- normally a non-verbal activity- isn't testing their abilities.
- skybrian 11y ago
  It's not about giving a dissertation. It's about collaborative problem solving. Granted, the interview is rather artificial and considerably more stressful, but you use the same skills when talking about how to solve a tough problem in front of a whiteboard.
- fennecfoxen 11y ago
  So you nest the toy problem inside a toy system. For instance, instead of just asking people to tell you if someone has won tic-tac-toe (a trivial program-yourself-out-of-a-paper-bag exercise to establish confidence) ask them to design the server side of a client-server tic-tac-toe game. Start with the trivial problem, then move on to all the system design questions that you'll want a software engineer to ask in your system and which require serious communication on a team. (API design for the tic-tac-toe server? Application lifecycle? Scalability? Latency? Take your pick.)

MCRed 11y ago

I think both of them are, because none of the problems are really good for explaining your thought process. In fact, it is a contradiction to try and think about a solution to a problem and to give a dissertation on how you're thinking about the problem. You can do one or the other, and in the latter case you have to have solved the problem previously. What I do is ask people about a problem they have solved and get them to teach me about it. If I learn something then it's a good result. Asking people to solve a trivial problem AND let you into the inner workings of their brain-- normally a non-verbal activity- isn't testing their abilities.

skybrian 11y ago
It's not about giving a dissertation. It's about collaborative problem solving. Granted, the interview is rather artificial and considerably more stressful, but you use the same skills when talking about how to solve a tough problem in front of a whiteboard.
fennecfoxen 11y ago
So you nest the toy problem inside a toy system. For instance, instead of just asking people to tell you if someone has won tic-tac-toe (a trivial program-yourself-out-of-a-paper-bag exercise to establish confidence) ask them to design the server side of a client-server tic-tac-toe game. Start with the trivial problem, then move on to all the system design questions that you'll want a software engineer to ask in your system and which require serious communication on a team. (API design for the tic-tac-toe server? Application lifecycle? Scalability? Latency? Take your pick.)