4 ms·

>>Every engineer says they delivered projects on time with great maintainable code. Unless the project is open source, they often have no way of giving any evid

>>Every engineer says they delivered projects on time with great maintainable code. Unless the project is open source, they often have no way of giving any evidence. Okay, but having them solve coding problems on the whiteboard doesn't provide any evidence of that either. If they say they delivered projects on time with "great maintainable code," ask them what makes code maintainable, have them provide examples (using pseudocode) and talk through each one. Ask them about a time when they had to sacrifice maintainability for time, application performance or user experience. Ask them what they learned from the ordeal. In my opinion you're going to be much more likely to accurately judge their expertise level based on their answers to such questions. The reason is simple: one can memorize whiteboard questions prior to the interview. They can't, however, bullshit their way through questions that are experience-based - and if they do, well, you should hire them immediately because you just found yourself a great salesperson!

joshuamorton 10y ago
I think its just as easy to memorize 'design' questions as 'whiteboard' questions. Not every whiteboard question is "implement a linked list", in fact I'd argue that's very rarely the case (or maybe I'm wrong and I've been insulated from these interviews). Most of my whiteboard interviews have involved a relatively small amount of actual coding (I think I had one question that was more than ~15 loc in python, and I've interviewed a few times). The rest was taking a relatively abstract problem presented in English and understanding it, removing ambiguities, and discussing tradeoffs with the interviewer. After that, a recursive function or a hash map or whatever is really easy.
- NTDF9 10y ago
  As a person who successfully solved a problem but was rejected because of coding style (on a whiteboard, not on IDE), I am respectfully wary of the term "removal of ambiguity".
  - joshuamorton 10y ago
    How do you mean? By "removal of ambiguity", I'm talking about when someone poses a problem like "Write a function to recognize an IP Address". My first thought is then "ipv4 or ipv6", because that problem is underspecified, and I don't want to inadvertently solve the incorrect problem (which is kind of a case of the xy problem)
    - NTDF9 10y ago
      Having solved a problem on whiteboard, the solution looked ugly. Reason it looked ugly is because I used variable names like i, j, k, did not adhere to OO principles and messed up indentations. All these, because I did not have an IDE and wanted to focus on the solution more than translation into code. Rejected. Recruiter told me, "Maybe this is the way you code but the interviewers didn't seem to like it". All I could think of was, "This is not the way I code at all. I just gave a simulated solution to a simulated problem solving environment". If you want to look at my coding style, give me a manageable problem and an IDE and I'll solve the problem with a focus on style. I've not had a problem with phone interviews simply because that is a more natural coding environment. Could I practice whiteboarding and become better? Sure. Is whiteboard coding style a relevant metric of measuring my productivity as a software engineer? Maybe not!

joshuamorton 10y ago

I think its just as easy to memorize 'design' questions as 'whiteboard' questions. Not every whiteboard question is "implement a linked list", in fact I'd argue that's very rarely the case (or maybe I'm wrong and I've been insulated from these interviews). Most of my whiteboard interviews have involved a relatively small amount of actual coding (I think I had one question that was more than ~15 loc in python, and I've interviewed a few times). The rest was taking a relatively abstract problem presented in English and understanding it, removing ambiguities, and discussing tradeoffs with the interviewer. After that, a recursive function or a hash map or whatever is really easy.

NTDF9 10y ago
As a person who successfully solved a problem but was rejected because of coding style (on a whiteboard, not on IDE), I am respectfully wary of the term "removal of ambiguity".
- joshuamorton 10y ago
  How do you mean? By "removal of ambiguity", I'm talking about when someone poses a problem like "Write a function to recognize an IP Address". My first thought is then "ipv4 or ipv6", because that problem is underspecified, and I don't want to inadvertently solve the incorrect problem (which is kind of a case of the xy problem)
  - NTDF9 10y ago
    Having solved a problem on whiteboard, the solution looked ugly. Reason it looked ugly is because I used variable names like i, j, k, did not adhere to OO principles and messed up indentations. All these, because I did not have an IDE and wanted to focus on the solution more than translation into code. Rejected. Recruiter told me, "Maybe this is the way you code but the interviewers didn't seem to like it". All I could think of was, "This is not the way I code at all. I just gave a simulated solution to a simulated problem solving environment". If you want to look at my coding style, give me a manageable problem and an IDE and I'll solve the problem with a focus on style. I've not had a problem with phone interviews simply because that is a more natural coding environment. Could I practice whiteboarding and become better? Sure. Is whiteboard coding style a relevant metric of measuring my productivity as a software engineer? Maybe not!