2 ms·

> Can I have productive discussion with the candidate about designing his solution? Can the candidate converse in a clear and precise language? > Can the candi

> Can I have productive discussion with the candidate about designing his solution? Can the candidate converse in a clear and precise language? > Can the candidate recognize and make use of an advice? I must admit that following those two criteria helped me make the most effective hires. I used to ask a question that was mildly confusing, but only to the kind of people I was trying to screen out. The people who I was trying to hire would usually get the question right away. Basically, in one of my questions I had developers use a lesser-known threading API in C#. The people I hired either got the answer right away, or could quickly adapt with my advice and answer the question. Another interesting anecdote: I used to ask candidates to discuss tradeoffs of the XML APIs built into .Net. The point was to discuss tradeoffs and to demonstrate more than superficial knowledge of serialization. (Most .Net developers have some exposure to its XML APIs at some point.) One candidate quickly hopped into a JSON is better than XML tirade. I ended the interview quickly.

mprovost 5y ago
That candidate probably tells a version of this story where they dodged a bullet by avoiding a job where they would spend all their time serialising XML.
ItsMonkk 5y ago
Please tell me there was more to that last story? Having someone come in and have a strong opinion on a topic, and have the gumption to state so in an interview, is exactly what I would look for. Did you poke them for more? Did you ask how JSON compares to XML? If they only answers "Well, I've never used XML, but I was trained on JSON and won't ever use XML, I don't know any of the downsides of XML", then you were correct to pass on them. But if they responded "Because of reasons X, Y, and Z, JSON is better than XML, and all XML interfaces are equivalent in this way, so I can't really answer your question because while I know enough about XML to know that it's bad, I can't tell you exactly the difference between different interfaces, as I've avoided them." That would be an answer I would accept. > got the answer right away This is the major critique of asking these interview questions. There's a small subset of them, so candidates train on exactly them, and only know how to do these, and when you hire them they won't be able to actually code anything. Using ML terms, they're 'overfit'. Getting it right away is actually a bad thing, but then you get candidates who act like they are going through the process just to look like they are learning on the spot... it's a tough problem.
- gwbas1c 5y ago
  Regarding JSON vs XML, I just pointed out that this is an interview question about discussing engineering trade-offs. The purpose of the question was to ensure that the candidate could understanding and evaluate trade-offs without making snap judgements. The candidate was incapable of doing so. For the threading question, the reason why I chose an unusual API was for your exact reason: You'll never see it on a list of interview study questions.

mprovost 5y ago

That candidate probably tells a version of this story where they dodged a bullet by avoiding a job where they would spend all their time serialising XML.

ItsMonkk 5y ago

Please tell me there was more to that last story? Having someone come in and have a strong opinion on a topic, and have the gumption to state so in an interview, is exactly what I would look for. Did you poke them for more? Did you ask how JSON compares to XML? If they only answers "Well, I've never used XML, but I was trained on JSON and won't ever use XML, I don't know any of the downsides of XML", then you were correct to pass on them. But if they responded "Because of reasons X, Y, and Z, JSON is better than XML, and all XML interfaces are equivalent in this way, so I can't really answer your question because while I know enough about XML to know that it's bad, I can't tell you exactly the difference between different interfaces, as I've avoided them." That would be an answer I would accept. > got the answer right away This is the major critique of asking these interview questions. There's a small subset of them, so candidates train on exactly them, and only know how to do these, and when you hire them they won't be able to actually code anything. Using ML terms, they're 'overfit'. Getting it right away is actually a bad thing, but then you get candidates who act like they are going through the process just to look like they are learning on the spot... it's a tough problem.

gwbas1c 5y ago
Regarding JSON vs XML, I just pointed out that this is an interview question about discussing engineering trade-offs. The purpose of the question was to ensure that the candidate could understanding and evaluate trade-offs without making snap judgements. The candidate was incapable of doing so. For the threading question, the reason why I chose an unusual API was for your exact reason: You'll never see it on a list of interview study questions.