4 ms·
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 "remova
by 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 agoHow 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 agoHaving 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!