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 conventions, 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.
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 may 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 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.
Please note, I am not saying there is anything wrong with having different standards of code. I can adapt to different codebases and different standards of code infact adapting to what is there already is probably the best way of working with the codebase. I am merely wondering …
Why the high level 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.
Earlier in the writing of this article you may have thought I was being harsh and judgemental when I was talking about the mess codebase. Like I say I am not bothered about the mess codebase if the mess codebase is already there and that is what the company has.
Sometimes codebases can become a mess if multiple people have worked on the project and there is no one there to really hold the architecture of the project together. I am not being judgemental in a harsh way, what I am argueing is why hold employees to high standards in interviews when it is obvious the codebase is a mess anyway.
It is like expecting 1 employee to do everything to a high standard on a project that has no standards. So that 1 employees contribution to the whole big project has to be to high standards whilst the rest of project can have no standards at all. Laying the burden on the 1 employee whilst the rest have not done anything to any reasonable standards anyway.
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.