I know this may sound like an weird question, but I recently applied to work as Elixir Developer for two different companies and they shared an Elixir Coding Challenge with me. Both challenges were quite good to solve and I really liked them.
My Feedback on both was “great”, but they found a “bug” and because of that they decided not to move forward at this time… I am wondering if there’s a project in production completely free of bugs… Is it normal to request challenges 100% free of bugs in Elixir?
I think companies are requesting too much of us developers. We need to know about databases, system design, scalability, algorithms, data structures, Apis, GraphQL, be able to get over Codility / Coderbyte, Technical Interviews, Coding Challenge, understand about Machine Learning / Artificial Intelligence, Elixir, Ruby and sometimes Node.JS JavaScript, React, Mobile applications and last but not least, We need to have good soft skills.
What is happening in our area? Companies think developers are robots or gods…
Not quite what you’re asking, but at Code Mesh 2018 there was a fantastic talk on eradicating exploitable bugs using formal verification. It makes me think that while today our code will have bugs, perhaps in the future we’ll have sufficiently advanced programming languages to make them a rarity. Well worth a watch!
There’s not enough info and context to judge really.
Say they asked you to write some quick code on a white board, and there are a few bugs. I guess that’s ok, it’s just a draft.
Say they ask you to code something and you have no limit on time, or they allocate a lot of time, and you deliver the solution with bugs. That is a bit worrying, no? Sure bugs happen in production, but should be as rare as possible, and you deliver bugs on the first piece of code they ask you to produce.
Yes I totally agree, but actually I am not completely sure they really found “bugs”… RH told me that, but looking at the feedback it looks like it was an interpretation or communication issue. Maybe there are some bugs, maybe not… the context was to read a task and then solve it according to my knowledge, but imagine you chose to use tuples instead of lists, chose decimal instead of floats, chose pagination instead of loading everything into memory… then your recruiter tells you should load everything into memory, use floats, use lists… etc Is this a BUG or you just made something in a different way? This is the problem… I think recruiters should send the task, after you solving it, they should do a code review, then you fix everything they think are wrong and it will give them a complete “overview” on how you work in a normal development process. This is the regular way… I don’t think a regular company asks something and the team solves everything from scratch without code review and 100% free of bugs… this is a weird way to evaluate someone in my opinion.
Well, the worst part is that we don’t know whether you really wrote some bad bug-riddled code, or whether they evaluated your code poorly. I feel for you–I’m pretty sure that at least once I submitted a coding exercise that went WHOOSH right over the reviewer’s head
I just interviewed someone who I was certain was being “too clever” (did a look back instead of a lookahead, which the spec called for) but I couldn’t on the find the error my gut knew existed in their crazy convoluted python code.
To find the error I finally had to write a property test and test it against reference code I had written in elixir (offline, after the interview).
Maybe we can learn from that that any assumptions made must be first verified. First quickly validate the approach you take on the task with the reviewer, prior to coding.
Note that you mentioned clearly “bug” in your initial post, i.e. bugs in production and I do think there should not be bugs if you have enough time to solve the problem (otherwise what does it mean? that someone will need to review any code you produce in the company?) ; but now you rather talk about communication issues with the reviewer, and not bugs…
So that leaves me confused ; maybe the reviewer felt the same way.
I think every single piece of code deserves a “review” before going to production. But this is my opinion. I respect you think different. English is my second language. Maybe I had told something wrong. Sorry for that.
That certainly happens. Just to be clear though, in the case that I was referring to, my code was much simpler than what they had in mind, and much faster. Like I said, WHOOSH
God yes, no code should ever be put into production without being reviewed by another person! (Only exception being outages, after hours, when the code review might have to happen post-deployment.)
Thank you, that is important to know. I also think that the review is then to make sure there are no bugs (there should be none, but it can happen rarely) going to production. For a junior you may expect to see a bug as soon as the FIRST piece of code submitted; but pretty sure the poster is not junior (with a quick look at his profile). While I now agree with you that there should be systematically reviews (and thank you for stressing that out), there should be no bugs found.
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).
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.
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.
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.
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.
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.
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.)
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.
