A review is a not a way to correct someone’s code, but to validate the code. And the first code asked to be produced appeared not to be valid (if there was a bug as the initial post mentioned).
thojanssens1
tiagodavi
I think the best aproach would be making a code review and ask to fix any mistake or communication issue, after that, recruiter could decide if move forward or not. But the case is they are expecting for the best developer who understands everything super fast and produces everything before deadline without any bugs.
I think even “Seniors” may produce bugs. I’ve been working on this area for 13 years, but I consider myself a beginner, always learning from my mistakes. I am here just to understand other developers think about this kind of situation.
Thank you all for sharing your thoughts.
2
tfwright
I feel strongly that any approach to application development or project management based primarily around “avoiding bugs” is bad, because yes, bugs are inevitable and not necessarily the best indicator of code quality. Is a beautifully elegant design with a syntax error lower value than spaghetti code that runs fine? Obviously not.
But in the specific context of hiring, bugs in a code sample say something about the applicant’s pride in their work and attention to detail. If they submit something much more elegant than everyone else, but it has an edge case bug, who cares? If the app, elegant as it is, doesn’t run at all, then maybe that’s a problem.
I wouldn’t consider any working implementation a bug just because it is not optimized for performance, or maximally concise, or DRY or whatever else. The most valuable part of the interview is the discussion about those issues. If a candidate has no idea that a convenience method, or library for that matter, exists that does exactly what they’ve re-implemented, then that speaks to their level of familiarity with the language and framework. But if they are aware and can give a well-thought out reason for why they didn’t use it, then that’s a plus, not a negative.
Any interviewing person or company that uses “we wouldn’t have done it that way” as an evaluation of an applicant’s work fails my standards as an interviewee.
1
Qqwy
TypeCheck Core Team
I know that there are some mathematically-verified applications out there. One notable example that comes to mind is the SLE4 microkernel that is used to run unmanned aerial vehicles like drones.
Still, even in that case, while the kernel might be mathematically secure, neither the hardware nor the user-land software layers have undergone the same verification process, so some bugs might still happen.
EDIT: but in more general terms, there is a great article called ‘why are we so bad at software engineering’ which talks about what methodology and stability guarantees we ought to shoot for in our projects, and what the consequences of that are.
0
sribe
YES! Come to it with an open mind and discuss it. Maybe it turns out that the candidate is not up to your standards, or maybe it turns out the candidate teaches you something useful.
1
dimitarvp
I feel that you (@tiagodavi) might have been hit by an insecurity attack after an interview with people that you described as rather close-minded. This is fine and can happen to everyone. Let it pass and think about it again in several days, when you will be calmer.
As others said, we don’t have the details so we can’t give an informed opinion. But I absolutely agree that your ability to discuss and offer thoughts and alternatives and ideas should matter much more than if you were able to respond perfectly in a short time frame.
Let me share a very recent story:
I had another [similar] problem this Wednesday: in my eyes, I did a really good job on a homework assignment but I feel the interviewers with which I spoke afterwards expected me to have written another algorithm (mine was definitely very simple and plain but I wasn’t given the expanded requirements which I was told about during the interview after I handed the homework; in the boundaries of the initial given parameters I am convinced that I did well though!). Can’t say I panicked during the algorithms interview but I definitely got a bit nervous and insecure and I fear this might put the interviewers off but oh well, such things can happen and is best not to lose your sleep over it.
I’m offering that company my experience, my eternal curiosity and a good balance of pragmatism vs. well-crafted software. The fact that (for a part of the interview) I failed at keeping a calm composure and confidence might turn out to be a deal-breaker for them.
But you know what? That’s okay, mate. If you get rejected, it means that both sides are definitely not a good match and the fact that you are not going to work with them is actually a good thing. Who wants a workplace they’ll dislike in a month anyway?
Assuming that you gave us the precise picture then I’d say it’s their loss. It’s more important to hire creative, productive and curious people, and not those who can recite the “How To Beat The Coding Interview 101” book.
1
sribe
Yes, this.
Again, seconded. My earlier posts about 1 specific experience might give an impression that I’m negative about interviews. That’s not accurate. I admit I get tired of the code exercises to prove that I can code, but having been on the other side I truly understand why they’re needed. I’ve interviewed a lot, and in all those times I’ve dealt with 3 rejections on idiotic bases (actually, 1 idiot didn’t even make it to an interview), while the rest were on rational basis of doubts about the fit. And that’s fine–it’s good to be selective, and there’s lots of reasons that a job night not be quite a good enough fit.
So don’t get discouraged, keep at it, always examine your code after a rejection for whether there were bugs or there might have been a better solution. And on the other hand, although you might figure out that a reviewer had a narrow-minded specific solution in mind, don’t ever try to give less than your best to satisfy such.
(Aside: the one that didn’t make it to an interview, that I called an idiot. In 2016 I had Elixir & Rust mentioned in my resume, and the hiring manager had the nerve to send the recruiter a really nasty email chewing him out for wasting his time with a candidate whose resume was all out-of-date technologies and obviously hadn’t bothered keeping up with the industry. So when I say “idiot”, I’m not exaggerating ;-), but the point is, neither you nor I want to work for somebody like that, so don’t take it personally, and carry on. I read and re-read the email that the recruiter kindly forwarded me, and changed some ordering & emphasis in my resume. I obviously didn’t care that I didn’t get THAT particular opportunity, but I tried to understand the idiot’s confusion well enough to make my resume easier to understand for competent hiring managers.)
1
tiagodavi
Thanks, but I think it’s not exactly the case. I am just tired of those kind of processes and I like talking about it to understand better.
0
madlep
Are there any non-trivial apps in production without bugs? Unlikely.
Are there non-trivial apps without fatal or severe or extremely common bugs? Yes.
It’s all a matter of context. If a candidate sent me a solution, and it had a minor bug on an edge case - I’d use that as a talking point in the follow up interview where we discuss the code submission.
If it had a major bug and the code doesn’t even run - that’s a fail.
Somewhere in between - “it depends”.
4