3 ms·

Going to second the other comment, when you're rushed for time, you don't end up with "beautiful" code (But you should at least solve the problem). I know none

by yoklov 10y ago

Going to second the other comment, when you're rushed for time, you don't end up with "beautiful" code (But you should at least solve the problem). I know none of the code I've ever wrote for a job interview was very good. Often it's total shit, hell, it often has a while (true) loop that I break out of later. (usually I ask if they'd like me to clean it up after I get it working properly). If your interview is designed around trying to see stylistic choices such as these (yes, the distinction between writing a loop and using linq is style), you should refocus it to be about figuring out the candidate's thought process.

gregmac 10y ago
There actually are performance differences between linq and typical for loops (basically anytime you can use deferred execution), but sure, I'll agree it's mostly style. However, if you claim to be an expert in modern C#, you should write modern C#. To use my example, surely between string parsing, time calculations, collection handling and loops there is SOMETHING in there you use on a daily basis and can demonstrate your claimed ability write in a modern way. I picked a small example, I don't actually know if we're moving forward with the candidate or not (I looked at the code but I've otherwise not been involved in the interviewing). For what it's worth, we have gone forward (and even hired) people that did poorly on the coding test, because through talking to them, they clearly know what they're talking about, and they could explain why they did badly. However, I've seen many times where someone can't sufficiently explain what they can do or accurately describe things they know about, can't write code in a coding test (even if allowed to finish without time limit), and don't have any open source profile (eg, code published on github). I don't expect everyone to be able to write SQL JOIN statements, but I do expect people that are "database experts" to be able to. If you claim to have an "expert level understanding of network protocols" you had better be able to explain to me the difference between TCP and UDP (and no, "UDP is more secure, TCP is faster" -- a real answer I got once, from someone with 15 years experience -- is not a good answer, even if it wasn't backwards). How do you hire someone like that? It could be just me and/or my team: none of us can communicate with this person sufficiently, while they'd be okay with another team... but that in itself is probably reason to be a bad hire for us (and them).

by yoklov 10y ago

gregmac 10y ago

There actually are performance differences between linq and typical for loops (basically anytime you can use deferred execution), but sure, I'll agree it's mostly style. However, if you claim to be an expert in modern C#, you should write modern C#. To use my example, surely between string parsing, time calculations, collection handling and loops there is SOMETHING in there you use on a daily basis and can demonstrate your claimed ability write in a modern way. I picked a small example, I don't actually know if we're moving forward with the candidate or not (I looked at the code but I've otherwise not been involved in the interviewing). For what it's worth, we have gone forward (and even hired) people that did poorly on the coding test, because through talking to them, they clearly know what they're talking about, and they could explain why they did badly. However, I've seen many times where someone can't sufficiently explain what they can do or accurately describe things they know about, can't write code in a coding test (even if allowed to finish without time limit), and don't have any open source profile (eg, code published on github). I don't expect everyone to be able to write SQL JOIN statements, but I do expect people that are "database experts" to be able to. If you claim to have an "expert level understanding of network protocols" you had better be able to explain to me the difference between TCP and UDP (and no, "UDP is more secure, TCP is faster" -- a real answer I got once, from someone with 15 years experience -- is not a good answer, even if it wasn't backwards). How do you hire someone like that? It could be just me and/or my team: none of us can communicate with this person sufficiently, while they'd be okay with another team... but that in itself is probably reason to be a bad hire for us (and them).