4 ms·

While I don't want to say if phone/whiteboard interviews are good or not, I can give you some pointers that worked great for me in the past. 1) Always, ALWAYS

by BSousa 12y ago

While I don't want to say if phone/whiteboard interviews are good or not, I can give you some pointers that worked great for me in the past. 1) Always, ALWAYS before writing a line of code say that you are trying to solve the problem first, by whatever means necessary and only then will you refactor. 2) Solve the problem by any means necessary. O(n*n)? Not freeing up resources? Allocating an array that is 100000 elements long just in case? No problem. Solve the problem. 3) Explain what you did/how you did it 4) Ask (if there is time) to refactor the code to be more idiomatic. Keep explaining that you wanted to solve the problem first, so later you can think of the right way to organize the code, and not the way around. I never had an interviewer complain about solving the problem in that order nor have cut me off (even when it ran out of time) when I suggested to refactor the code in the end. Also solving the problem first, then using idiomatic code takes a bit of the stress off since you don't have to go and write and rewrite each line everytime you see something wrong.

matthewmacleod 12y ago
That's very interesting—I'm much less interested in a candidate solving a problem in that situation, than I am in seeing how they approach it. That includes things like 'Hey, you made an unusable O(n!) algorithm, what gives?' That's always made clear though. I guess it goes to show that there's rarely one approach to this sort of thing.
- BSousa 12y ago
  To be fully honest, that is usually how I solve problems anyway :) I start with the problem, whatever it maybe, then I 'solve' it by whatever means necessary. This lets me iterate very very quickly over various solutions if needed without much concern about pretty code, even if it is a simple api call, parse json, display something in the view. When I have that working, I refactor, sometimes I rewrite, I make the UI nice, I write tests, etc. In an interview, I believe you either want to see if the person can code/create and algorithm or you want to see his thought process on solving problems. If the latter, you don't need a whiteboard and a conversation with someone will work as well. If the first, I would do as I mentioned in the previous post. The O(n!) question for me wouldn't be important. I would probably reply "Yes, I know, let me just finish this part"... "Back to the O(n!), you are right/wrong, but seems to work this way, what we can do is change that for loop into a something/something reducing it to O(2n). And rewrite that part of the code. When I was interviewing people, after a quick phone screening, we would ask someone to come over, we had a quick chat with them (30 minutes maximum) and then had 2 quick exercises for them to do. 1) given a simple piece of code (200 lines or so) we would ask them to refactor it, based on some parameters like future extensibility, not being linked to some implementation, etc. Second one was a written spec, with 3-4 unit test written that would verify the spec, and we would ask for them to write the implementations (max. time 3h, good candidates finished it in 30-45minutes, bad ones couldn't finish it in time). With those two questions we were quite easily 'judge' the competence of the candidate. The ones that did very good would go home with job offers (or would have one when they got home), bad ones were rejected, and intermediate ones, depending on team feedback would be invited back to discuss the code so we could make up our minds. ps: I actually wrote the exercises and everyone already at the company did them as well and passed.
bmj 12y ago
I did a whiteboard-based interview recently. I am very, very bad at these, mostly because I tend to freeze up. Fortunately, there were two parts, and by the second part, I was more comfortable, and did significantly better [0]. Your point about being clear about refactoring and talking through the problem is critical, I think. It also helps if the problem starts small (write a function to reverse a string) and builds in complexity. That allows the interviewee some time to find their sea legs, as it were. [0] During the first part, I completely, totally, forgot about SQL joins. No, really.

by BSousa 12y ago

matthewmacleod 12y ago

That's very interesting—I'm much less interested in a candidate solving a problem in that situation, than I am in seeing how they approach it. That includes things like 'Hey, you made an unusable O(n!) algorithm, what gives?' That's always made clear though. I guess it goes to show that there's rarely one approach to this sort of thing.

BSousa 12y ago
To be fully honest, that is usually how I solve problems anyway :) I start with the problem, whatever it maybe, then I 'solve' it by whatever means necessary. This lets me iterate very very quickly over various solutions if needed without much concern about pretty code, even if it is a simple api call, parse json, display something in the view. When I have that working, I refactor, sometimes I rewrite, I make the UI nice, I write tests, etc. In an interview, I believe you either want to see if the person can code/create and algorithm or you want to see his thought process on solving problems. If the latter, you don't need a whiteboard and a conversation with someone will work as well. If the first, I would do as I mentioned in the previous post. The O(n!) question for me wouldn't be important. I would probably reply "Yes, I know, let me just finish this part"... "Back to the O(n!), you are right/wrong, but seems to work this way, what we can do is change that for loop into a something/something reducing it to O(2n). And rewrite that part of the code. When I was interviewing people, after a quick phone screening, we would ask someone to come over, we had a quick chat with them (30 minutes maximum) and then had 2 quick exercises for them to do. 1) given a simple piece of code (200 lines or so) we would ask them to refactor it, based on some parameters like future extensibility, not being linked to some implementation, etc. Second one was a written spec, with 3-4 unit test written that would verify the spec, and we would ask for them to write the implementations (max. time 3h, good candidates finished it in 30-45minutes, bad ones couldn't finish it in time). With those two questions we were quite easily 'judge' the competence of the candidate. The ones that did very good would go home with job offers (or would have one when they got home), bad ones were rejected, and intermediate ones, depending on team feedback would be invited back to discuss the code so we could make up our minds. ps: I actually wrote the exercises and everyone already at the company did them as well and passed.

bmj 12y ago

I did a whiteboard-based interview recently. I am very, very bad at these, mostly because I tend to freeze up. Fortunately, there were two parts, and by the second part, I was more comfortable, and did significantly better [0]. Your point about being clear about refactoring and talking through the problem is critical, I think. It also helps if the problem starts small (write a function to reverse a string) and builds in complexity. That allows the interviewee some time to find their sea legs, as it were. [0] During the first part, I completely, totally, forgot about SQL joins. No, really.