I'm sorry but it really seems like you are making a mountain out of a molehill here just to be argumentative.
Do you think this accurately reflects the working conditions of a developer?
Who said anything about trying to simulate a normal development day? This is about finding out some of their thought processes and if they can solve an exceedingly simple coding problem.
They may blank, they may freeze and they may just be the type of person that reflects on an issue for a while before the set out to code.
Where did they say you can't reflect on the issue? That's exactly what they want is you reflecting on the problem and describing how you'd go about solving it.
If someone tells you to write a function that takes a number N and prints out 1..N in pseudo code(Which is basically what the pascal problem asks when they provide the formula for a row) and you can't even talk your way through a possible solution you're not going to be able to complete any interview process, no matter how gentle.
I personally would search for the mathematical formula and a text description that I could put on my second monitor as reference.
So you're complaining that you can't search for something that the interviewer is already providing?
I personally never work from verbal descriptions, I document the issue, and place it into a ticket system in which I work the tickets based on priority.
If you are this incapable of listening to a two or three sentence problem description, ask the interviewer to print it out for you and write "ticket #1" on it? I mean is your nitpick really "They told me the problem out loud instead of writing it down?"
This is even ignoring the fact that taking verbal problem descriptions is an incredibly useful skill as a software engineer. I mean I guess I could tell people to file another ticket and I could have the joy of e-mail tag as I have to send off clarifying questions further delaying the task.
I'm sorry but it really seems like you are making a mountain out of a molehill here just to be argumentative
I assure you I am not trying to be argumentative, I am trying to help people understand why I and the author of the article believe that it is a flawed hiring practice. I have raised some good points, you can reflect on them and utilize them or you can discard them as rubbish. But I can tell you this, I have a lot of success in recruiting and I have learned by committing some of the very mistakes that I now advocate against. I used to buy into the Cargo Cult hiring practices, until someone smarter than me taught me how to truly identify talented individuals.
Do you think this accurately reflects the working conditions of a developer?
Who said anything about trying to simulate a normal development day? This is about finding out some of their thought processes and if they can solve an exceedingly simple coding problem.
They may blank, they may freeze and they may just be the type of person that reflects on an issue for a while before the set out to code.
Where did they say you can't reflect on the issue? That's exactly what they want is you reflecting on the problem and describing how you'd go about solving it.
If someone tells you to write a function that takes a number N and prints out 1..N in pseudo code(Which is basically what the pascal problem asks when they provide the formula for a row) and you can't even talk your way through a possible solution you're not going to be able to complete any interview process, no matter how gentle.
I personally would search for the mathematical formula and a text description that I could put on my second monitor as reference.
So you're complaining that you can't search for something that the interviewer is already providing?
I personally never work from verbal descriptions, I document the issue, and place it into a ticket system in which I work the tickets based on priority.
If you are this incapable of listening to a two or three sentence problem description, ask the interviewer to print it out for you and write "ticket #1" on it? I mean is your nitpick really "They told me the problem out loud instead of writing it down?"
This is even ignoring the fact that taking verbal problem descriptions is an incredibly useful skill as a software engineer. I mean I guess I could tell people to file another ticket and I could have the joy of e-mail tag as I have to send off clarifying questions further delaying the task.