These days there are an increasing amount of applications, time constraints, and limited employable spaces at companies. This creates a huge spiral of competitive dilemma for candidates trying to get an employment. It is even harder for ones just starting out as their first job. Technical interviews usually require some level of programming test. However, the more hands on a test is the more pedantic the interviewer will get in process. Even mistakes that an interviewer makes in their own daily lives can seem like an issue to mark against a candidate. For a lot of candidates that get rejected these days their solutions are pretty much perfect in terms of deliverable. What this means is that interviewers look for every corner case possible to mark a candidate off as there are no other ways about filtering them. Interviewers are setting a very unfair target for themselves and screening out perfectly good candidates in process. This can be very frustrating for candidates too. Not to mention if the interviewer does not even bother to check their test and ends up messing them around which means a wasted exercises. Most interviewers can't be bothered for the time and effort that a candidate puts into their application and interview tests. And, in turn, they provide for an aimless feedback that has no real meaning to candidate other than the fact that code was not produced in a similar way as to how the interviewer likes it even though the candidate approach is perfectly logical. With pedantic interviewers, a candidate also has an opportunity to work out how the team is going to be like on a typical work day. Would you really want to work with such a person in your team who just has an issue with everything right down to what you name your variable, spelling, to the approach you followed. There have even been cases in UK where an interviewer has marked a candidate off because they used American English spelling of words in their code. Some senior developers are so strung out on process that they really forget to deliver on quality. Would you rather see a piece of code that was optimized and correct with no issues, compared to a solution that worked in sub-optimal time, had a whole lot of unnecessary tests, and still created issues in production. Tests are essentially there to provide a confidence level to assure the code does what it needs to do, has been properly refractored, and can be applied to a continuous integration for repeatable build tests. Overbearing tests that have little sense are just driving time wasted solutions. After all tests are self-engineered. However, an experienced productive developer can build tests that are minimal, logical, and yet have a better coverage. Again, over engineering on solutions is driving away creativity and innovation and instilling a very rigid and illogical approach to quality assured development practices.
