3 ms·

Hi Richard, To me personally, not requiring on-the-spot coding tests would make me happy. Compare the following two scenarios: Company A: During the interview

by fredwu 15y ago

Hi Richard, To me personally, not requiring on-the-spot coding tests would make me happy. Compare the following two scenarios: Company A: During the interview, I was asked to write a short ruby method to solve a problem on the whiteboard. I didn't really do well because I couldn't remember some APIs. Though in the end I still got the job, so I don't really know how effective the whiteboard coding test was. Company B: During the interview, I was asked to explain the coding logic to solving a problem in Backbone JS on the whiteboard. I was much more comfortable with that, as I didn't have to remember exact APIs or methods to use. During this process, the interviewers got a good sense of my technical ability not just in Backbone JS, but also in JavaScript and MVC in general.

Mavyrk 15y ago
Are both fundamentally not the same thing? I understand that company A may have made you a bit uncomfortable, but perhaps their intent was the same as company B's? That is, to see how you logic out a problem. You did say that you got the job in the end, so clearly the point wasn't to see if you knew some APIs by memory as a make-or-break situation. There's also some benefits that can be gained by company A's method ostensibly over company B's. You get to see their response to the discomfort of not remembering an API. You get to understand their problem solving abilities, not in terms of code, but in terms of interpersonal relationships. In a recent article I read, someone had suggested offering a code prompt and then challenging the applicant to find the bug on completion (even if there wasn't one), simply to see how they respond when faced with that challenge. Naturally it may not be perfect, it's just hard to really quantify which one is "better" if they're arriving at the same end -- a presumably competent engineer being hired. Are companies not interested in hiring people with both interpersonal skills and technical ability, after all?
- fredwu 15y ago
  Fair point. :) However, I would argue that in company A's scenario, the discomfort I got from not remembering the APIs would never happen in real world situations where API documentation and Google/StackOverflow are readily available. Ideally, if one does really well in whiteboard situations then great. But similar to how some engineers give terrible public talks, we can't discount the ones that do get nervous in those situations.

by fredwu 15y ago

Mavyrk 15y ago

Are both fundamentally not the same thing? I understand that company A may have made you a bit uncomfortable, but perhaps their intent was the same as company B's? That is, to see how you logic out a problem. You did say that you got the job in the end, so clearly the point wasn't to see if you knew some APIs by memory as a make-or-break situation. There's also some benefits that can be gained by company A's method ostensibly over company B's. You get to see their response to the discomfort of not remembering an API. You get to understand their problem solving abilities, not in terms of code, but in terms of interpersonal relationships. In a recent article I read, someone had suggested offering a code prompt and then challenging the applicant to find the bug on completion (even if there wasn't one), simply to see how they respond when faced with that challenge. Naturally it may not be perfect, it's just hard to really quantify which one is "better" if they're arriving at the same end -- a presumably competent engineer being hired. Are companies not interested in hiring people with both interpersonal skills and technical ability, after all?

fredwu 15y ago
Fair point. :) However, I would argue that in company A's scenario, the discomfort I got from not remembering the APIs would never happen in real world situations where API documentation and Google/StackOverflow are readily available. Ideally, if one does really well in whiteboard situations then great. But similar to how some engineers give terrible public talks, we can't discount the ones that do get nervous in those situations.