5 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 evide

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. I'm not saying whiteboard interviews are the right way to interview, but in my experience you can't trust people's judgment about themselves and their skills. You need an interview that is equally fair to the person that will exaggerate their past successes to the people that are more reserved or the people that don't have much experience yet.

techterrier 10y ago
In other engineering disciplines there's accreditation and references for this sort of thing. No CEng for software engineers sadly.
falcolas 10y ago
Like a pair coding project on a computer with access to their internet resources? Can find out a lot about a person in a one/two hour pair coding interview.
brandon272 10y ago
> Unless the project is open source, they often have no way of giving any evidence. Isn't this is the case for every job applicant in every industry? You look at the evidence available of someone's work history and make a judgment call.
enraged_camel 10y ago
>>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!
mtberatwork 10y ago
> you can't trust people's judgment about themselves and their skills. Unless the candidate is fresh out of uni, any qualified candidate with experience should be able to provide at least several solid contacts at previous employers from which to obtain this information.
- dpark 10y ago
  References from co-workers aren't really that valuable. Many people have no qualms about giving glowing reviews for friends, even if those friends don't really deserve glowing reviews.
- deleted 10y ago
  [deleted]

techterrier 10y ago

In other engineering disciplines there's accreditation and references for this sort of thing. No CEng for software engineers sadly.

falcolas 10y ago

Like a pair coding project on a computer with access to their internet resources? Can find out a lot about a person in a one/two hour pair coding interview.

brandon272 10y ago

> Unless the project is open source, they often have no way of giving any evidence. Isn't this is the case for every job applicant in every industry? You look at the evidence available of someone's work history and make a judgment call.

enraged_camel 10y ago

>>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!

mtberatwork 10y ago

> you can't trust people's judgment about themselves and their skills. Unless the candidate is fresh out of uni, any qualified candidate with experience should be able to provide at least several solid contacts at previous employers from which to obtain this information.

dpark 10y ago
References from co-workers aren't really that valuable. Many people have no qualms about giving glowing reviews for friends, even if those friends don't really deserve glowing reviews.
deleted 10y ago
[deleted]