Five crazy software developer interview failures

Five crazy software developer interview failures

Interviewing for a software developer can be both; fun and frustrating at the same time. Regardless of years of experience, I have to admit; there will always be a stumbling block, a question that will bring you down from the mountains of expertise to the ground level, basically a situation that will make you humble and set on a new learning path. 

To make more sense; I am talking about tricky questions. Ones, created to see if a candidate fits a combination of tech stack and organisational culture. 

Let’s smash all five interview failures;

  1. Funny acronyms. Can you tell me what SPA stands for? Well, according to Wikipedias disambiguation page https://en.m.wikipedia.org/wiki/SPA, the software part offers four different versions. Even, if you are interviewing for an Angular/React developer role, all options may be correct. Is it secure password authentication or a single page application, what on earth do you expect? 
  2. Headline conflicts. Can you tell me what JWT stands for? Well, back in 2009/10/11 when java web tool kit was on top of the programming language trends, to be honest, if being interviewed, I would have said exactly like that.  Java Web Tool is a web GUI library in pure Java https://www.webtoolkit.eu/jwt/features developed by a Belgian software company https://www.emweb.be/. Image a situation; the person you are interviewing has just worked inside the organisation adopting Java Web toolkit as their technology stack. Guess what would be the answer? However, this can also mean JSON web tokens - cryptographic security solution for single-page apps. The cold truth is; both can be correct on a single larger-scale project. What do you expect?
  3. Seldom used definitions. Can you tell me what ACID means? One with a good sense of humour may follow up asking: “Do you intend to harm somebody?”. I presume the answer expected is: Atomicity, Consistency, Isolation, Durability; a set of properties of database transactions intended to guarantee validity in the event of errors, power failures, etc. I am curious about what you are trying to evaluate; dev ops skills (more relevant task to take care of), seniority level or something else. I am not 100% sure if that term will ever come up once the person commences work.
  4. Ambiguous expectations. Can you explain to us how do you go about testing, do you use a set of specific methods or something else? According to this post https://blog.bitsrc.io/top-javascript-testing-frameworks-in-demand-for-2019-90c76e7777e9 potentially there are ten equally correct answers. I am curious about what do you expect; jest, Jasmin or mocha? Jest is a built-in testing framework for ReacJS and frankly speaking over the busy startup environment one will likely ignore that. Rather than spending time on researching various testing frameworks, the developer will carry on with the allocated tasks.
  5. Incomprehensible seniority evaluation. When was the last time you used javascript, do you like HTML?  Let’s get back to our sense of humour: “When, hmm, just this morning, had to help a colleague.”. Yes, usually people laugh on the other end of the line table.  What do you want to find out; experience, language or markup skills, something else? 

Are these the only software developer interview failures, good question. I am convinced list can go and go on.

All five failures are the most recent patterns I have spotted, ambiguous technical questions that tell us nothing about the interviewee; we receive zero impression on the type of personality we are about to onboard.  

Often these accompany job specifications asking for high problem-solving skills and creativity but do they provide us with relevant answers?