So I have been to a number of interviews now where I have had to answer technical questions and do technical tests. The technical questions are of a high standard and can go deep into the principles of object orientated programming. What baffles me is when I ask to look at some of these companies codebases the codebase is a mess, even the interviewers have admitted that their own codebase is a mess occasionally.
I am talking functions with over a hundred lines of code in them, huge code files, code copied from one place to another with just a couple of minor changes, no consistency in naming convensions, if “classes” where used no real thought about true object orientation was attempted and the class was used just as a place to put some code, basically not even an average coding standard level but a below average coding standard level.
Now the company may state they have high standards during the interview process to weed out the candidates who do not do well in the tests. However this makes no sense for a couple of reasons …
- True candidates who do well on the tests will not want to work on such a codebase. Even if the candidate who did well on the tests did want to work with such a codebase how can the candidate who did well on the tests adapt to such a codebase? All the candidates who did well on the tests can do with such a codebase is to follow what is already there for the most part.
- Companies with such a codebase do not want candidates who do well on the tests, the companies may claim they do but when it comes down to it the candidates suggestions for improving the codebase, the candidate will not be taken seriously. Generally with codebases like these a complete re-write of the entire codebase will be required. Companies with codebases like the above suggested do not care whether someone can code the system in a more efficient and effective way, they just want someone who can work with the codebase they currently have, thus adding to the mess.
So why the technical questions and tests in the interview? Who knows? I most certainly do not. None of the principles asked during the interview is applied to the companies codebase so why do candidates need to go through these tests and demonstrate such principles.
The best interview I ever had consisted of having a small conversation about myself and the company followed by a small task. The small task I had to complete was to demonstrate how I would fix a certain bug with one of the features within their current system. No tricks, no catches. I just had to explain how I would fix a fairly ordinary bug that has cropped up in the current system.
I was shown a screen with the bug on it and handed the codebase. I could determine the starting point to look for the bug via the URL of the screen with the bug on it. After starting at the above point and digging deeper into a couple more files I found the best place to implement the fix and determined what the fix would be.
It would be great if all interviews where like the one described above. The task has got to be something small that demonstrates the programmer can dig into the codebase and fix a small problem.
So in conclusion I believe that interviews should be tailored to represent the actual companny. If your company does not need candidates who do well on interview tests then the interview should not be tailored that way. If your company is adament that candidates who do well on interview tests are needed then the companies current practices and codebase should reflect the level of tests they are giving to candidates at the interview.
Please also note that in a lot of the tests companies give to candidates the questions seem more geared to how much you can remember from a standard “programmers handbook” than actual real world scenarios that might actually happen. That is why the above approach involving fixing a bug is a better approach in my opinion.