Lately I’ve been having some thoughts about programming as a profession. One observation I've made here concerns ubiquitous hiring practices in the industry. Here is something to be said indeed.
What is that special something that sets the hiring practices in the software industry from those in any other field apart?
There should go something around the matters of intellectual work and creativity that is supposed to yield programmers a dignifying position in the eyes of a hiring manager. Sadly that is almost never the case. Quite the opposite actually. Like in no other profession programmers get every their word said or written on their resume checked, double checked and put under suspicion. For some reason the hiring people feel the burning need to check people’s skills at the face-to-face interview. I mean right now and preferably all of them at once. A thorough check of that experience and skills that took years to acquire. Every answer is being carefully listened to and critically analyzed. Sometimes there are several hiring people attending the interview including a psychologist. They watch your every move, take notes and then discuss your candidacy after the show.
Sounds familiar?
If not I'll help you. It is exactly how investigators work. A couple of guys visit a suspect, talk to him, ask him some tricky questions, take notes, watch his mimics and gestures and then exchange opinions afterwards. Sometimes they summon a person to a police station to question him there. They ask difficult questions and sometimes invite another suspect to make a confrontation.
Again, sounds familiar?
It is exactly the situation when some team lead joins the interview, pulls out a test task and watches as the suspect programmer advances through it. Sometimes the guy throws a helping advice. Sometimes he makes a suggestion that would lead the programmer astray.
Is all this really necessary?
No wait, a better question is how has it come to that in the first place?
This writing was actually triggered by this question recently asked on StackOverflow:
How to handle people who lie on their resume
Update: this question is now deleted but here's the Google's cache of it:
Cached: How to handle people who lie on their resume
It makes me sad to see this sort of attitude again.
Quoting the author:
"I was discussing this issue with the hire-ups, and they wanted me to go down a person's resume line-by-line to see if their skillset checked out. They even wanted me to intimidate people by asking them to cross off anything on their resume which "may have been inflated"."
This is just sick. Seriously, why do you want to check if people have exactly 100% of the skills they state on their resume? How does it alter that person from being a suitable candidate for you to the one who is suddenly not? Some of those skills may be of no relevance to you. Some may even be beyond your level of competence. And tomorrow in your daily work you may come across something that nobody in you present team (including yourself) is qualified to deal with. Will that make all of you unfit for the job?
Now to that level of competence. How do you evaluate whether the candidate "knows" some technology X? By asking some general questions about it? That is easy to pick up in a few days. By asking some tricky questions? They are easy to miss even after many years of hardcore engagement with that technology. Different people and different projects make different experience. You know one trick he knows the other. Who is better qualified? Who knows better that technology X?
This is childish. Anybody worth his salt will tell you that you can never master any technology no matter time and effort. Unless you've created it. But then you're not likely to be sitting in an interrogation job interview striving to convince the hiring guy you do have it in grasp.
It is also well known that your brain only stores the recently used information in fine details. In most cases you're only using a small subset of any technology, periodically venturing into one or the other of its other rooms, doing what's necessary then going back to your routine. After a while the knowledge of what you've experienced in that room is faded. If you're suddenly asked about it at an interview, you won't remember it. So what's the point of asking? If only to check what recent information somebody's brain cache contains? How's that relevant to determining the skills and knowledge of that person? He did it once, he can do it again. But he cannot permanently hold in memory every little detail of that technology.
Besides, any technology (except for COBOL probably) is always on its course of continuous change and development. Even if you both (you the interviewer and your victim) know some technology to 100% (whatever that means) right now on this day at this hour, you both will drop out at some time unless you stay on course and continue learning every day. So your knowledge may differ today but that can change tomorrow. Depends who is running faster.
Hiring people also practice asking candidates CS theory. Data structures, algorithms, graph theory, probability theory. I'm not sure whether this is wise. Most programming jobs don't have anything to do with that. In their daily practice most programmers have no application for the knowledge they obtained in the university. If they attended a university. Those who did have likely lost this knowledge over the course of the years. I admit this is sad. But it's a fact of the life. Only general knowledge of data structures and operational complexity is retained. This one is important to write efficient code. But the rest is gone. Everyone knows it. What's the point of asking those questions then? I'd say only three categories of people will be able to answer theoretical questions without extensive preparation. Researchers who work with the theory on the daily basis, students who just went through an examination and… well, the hiring people. You know why? Because they ask those questions during interviews all the time! Not because they need the theory in their work. Others will need an extensive preparation. Long months of refreshing that old theory only to forget it again in the blink of an eye. Pointless.
I hold a strong opinion that you can refresh any knowledge you had when you need it again. Or obtain that knowledge if you really want to. It's that easy.
It’s not the immediate knowledge (basically a brain memory dump) that matters but the ability and willingness to learn and educate oneself every new day. That should be looked for in candidate people. Sadly this is generally not attributed any value. Wrong.
It gets especially funny if you mentally try to apply this screening approach to other professions. When you're getting a carpenter, do you ask him whether he knows to hit nails with a hammer? What about demonstrating it? Seriously, I give you a piece of wood, a nail and a hammer. Please demonstrate how you would hit the nail. Yep, you passed. But what about screws? Can you tighten screws with a screwdriver? No, with an electric one it is easy. With a hand screwdriver please. And can you saw wood? Please show. And wait a minute. We forgot the theory. Do you know how to prepare wood for work? How would you plant and grow trees for them to become the right work material?
Or you might be in the need of a painter. You arrange a meeting with her and ask her basics about the painting art. Let's check whether she can paint at all. Please paint a red circle. Now a green square. If you had red, blue and green tints, how would you paint a magenta line? I see, you know it. But you can't be possibly a good painter without the theory. How is this brown paint manufactured? From what components? Can you write down a chemical formula please? How would you synthesize this color from the stuff normally found in a household? You don't know. Sorry you're not a good painter. Get lost.
Maybe it's not your business checking those elementary things which may not even be needed? Do you want the carpenter to build you a closet or just hit a pile of nails? Do you want the painter to make a scenery image or just paint lines and circles? Do you want your programmer to create software or get buried with algorithms and data structures?
Knowledge of basic elements and ability to accomplish elementary things is by no way a guarantee or even a sign that one is able to develop software, create efficient design and write quality code. Simply no correlation. Many students shine at university when writing sorting algorithms, designing perverse data structures and providing theoretical backup for the math involved. Still, many of those students are just hopeless for any practical software development. While a guy who never attended a university can suddenly develop amazing things. Against all your odds.
Besides, coding in not really the ultimate goal. We're not here to write the breathtaking code. We're not here to explore all of the hidden gems of some technology. We're not here to design a perfect bullet-proof architecture to accommodate for any future requirements in the next 50 (better 70) years. We've gathered together to develop software, to create a product, to solve specific problems and satisfy customers. Today, in this century, in this life. It is important to remember what we're doing and why while we're programming. One has to be able to simultaneously exist in several dimensions. In code when we're programming. In the needs and requirements we're programming for. In the mind of the users whose requirements we're putting in code. And also think of many other social, marketing and organizational aspects. Beyond code there are business processes, certain user experience. Don't forget usability. One has to see the big picture to excel. That special skill is however very difficult to check for when interviewing a candidate but it may happen to be even more important than coding skills or the advanced all-penetrating knowledge of the technology in use. If you focus on only technical skills you may only be getting techno-freaks. Terrific programmers when left alone coding but quite useless outside of the field. Would you really profit from that choice?
I understand the hiring people seriously wish to learn everything about the candidate during a short interview including his skills, abilities, potential, thought patterns and everything else. Don't be stupid. This is simply not possible. No sort of interview questions, test tasks and role games at assessment centers ever going to provide you with a certified feedback on that person. The only option is to run the horse on a track. Meaning, joint work on a real project will open the cards. There is a common practice of probation period. Use it. That is what it's meant for.
The reason for that extensive check of candidates may lie with fear of getting incapable people. I don't know. I've been hearing many opinions about programmers applying for jobs while they cannot in fact program. This one, for instance:
The Non-Programming Programmer
I'm not yet ready to believe that. Personally I think this is one more meme or a myth spread around the web. Why would anyone with no aptitude or even interest for programming apply for a programming position? They'd be forced to program the whole time if they passed! Who would want this self-torture?
But let us return back to that wonderful citation. So they wanted to "intimidate" people by making them feel liars.
What is wrong with you? Why do you want to humiliate people who may be coming to work with you side by side?
Do you want them to lose their confidence and belief in themselves even before the show begins? Do you want them to feel uncertain und repressed in their new habitat? Do you want them to keep quiet and never make any objections or valuable proposals? Do you want to cut off their career growth so that you're secure in your leading role? Do you want to devalue their skill set and beat them down to accepting a lower salary? Or is it the sad fact that you need to assert yourself and the only way you can accomplish this is by making the other people low? Especially when there are your colleagues around to watch and remember your "victory".
By the way, where is the presumption of innocence in this case? Programmers are considered guilty of lying until they prove otherwise? It’s time we appeared for an interview with a lawyer.
Exposed to such an unhealthy experience I would likely stay clear of the place even if I somehow passed the interview. Quite probably I would have stopped it in the middle to avoid further "embarrassment" if I came to the conclusion I didn't like the personalities in the club.
And let us talk about personalities. Very likely you wish to hire a programmer to join your existing team and work in a collective. Naturally. But don't you think it may also make sense to select people not only matching perfectly your technology requirements but suiting the team personally? I mean there is so much more going on in real work besides coding. There is exchange of opinions about all aspects of the development process. Different views about application design and architecture, coding style, refactoring, interface design, testing approach, quality assurance, rollout strategy. People will have different opinions about technology choice, its weak and strong sides, what tools to use in what situation. And even the working style alone can be a source of friction. Fixed of flexible working hours, need for quiet environment, eating and drinking habits, treatment of other colleagues with dignity or disrespect, need for a room for own decisions or working under strict supervision and many other aspects which may prove crucial to the success of this individual in a team. Dozens of things to match. If one of them doesn't check, the whole may fail. And you're wasting time during interviews to extensively check for one specific thing – technology knowledge – while this one is neither required nor sufficient for the chemistry to match. You're not using your time efficiently. And even if you were, the probation period is unavoidable.
I'd very much like the hiring people to stop that nonsense, to grow and start putting more intelligence in conducting a job interview. Pay attention to many other things besides programming skills. Think of what is important for your team to accept a new member and let him unveil his potential then look for the signs of a good match.
If you firmly believe you cannot avoid extensive skill check and will continue to load people with tricky questions, test tasks and long technology tests without thinking of other aspects, then don't be surprised about low match ratio and high turnover.
Maybe you're just not the right person to do the hiring? Step aside and let someone else do it.
