5 ms·
> I'm tired of companies asking me to code at their interviews. I have 10 years experience I just saw some code a candidate wrote (offline) who also had nearly
by gregmac 10y ago
> I'm tired of companies asking me to code at their interviews. I have 10 years experience
I just saw some code a candidate wrote (offline) who also had nearly this much experience in C#, and who apparently explicitly called out using C#6 and being a C#/.NET expert etc, etc.
Their code was written like it was 10 years old. Used array allocation (rather than collections). Time calculations like Convert.ToDouble(Convert.ToInt32(hourStr)/60)+Convet.ToInt32(minStr). Giant for loops where a simple LINQ query would do. It also failed to solve the problem.
10 years but hasn't learned anything new doesn't count for 10 years experience, in my opinion. That's why even "experienced" developers get coding questions.
(Btw, If the candidate hadn't explicitly called out their supposed expertise their use of old coding style could be overlooked; but since they had this on their resume, it either meant they were completely clueless about it, or simply lying. Either way, not a good start.)
- cosmolev 10y agoDisclaimer: I've never written any C# code, I write Java code. "Convert.ToDouble(Convert.ToInt32(hourStr)/60)+Convet.ToInt32(minStr)" - while nobody writes code in this way in production this is exactly the way of coding endorsed by Codility-like programming challenges when you have 30 minutes to come up with a solution.
- winsome 10y agoMaybe for someone with no experience in the desired language and minimal access to docs, but for someone that professes a knowledge of C# 6 they ought to at least know about the `TimeSpan` class. For anyone with the knowledge the person claimed to have, that code should boil down to something more like TimeSpan.Parse($"{hourStr}:{minStr}").TotalMinutes;
- yoklov 10y agoGoing 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 agoThere 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).