Why you should never settle for coding interviews

A software engineer interview today often involves some kind of test or programming exercise, and I think this is a very bad thing. That's why.

---

Lazy trails

By asking software engineers to do a specific task, such as writing a factorial generation algorithm (very common) or sorting a singly or doubly linked list that is easy to remember, you will not get any idea about the candidate's skills, other than the ability to cram. You might as well ask the ASCII code of the 'A' character.



Detailed solutions to many problems are easy to find in a variety of reference materials, often in books, which describe algorithmic and specific solutions to all problems common in a programming interview.



I worked for a company and there I talked in detail with a colleague about what the interview with a large hedge fund was like. He carefully memorized all the technical questions from the widely available book of interview questions and answers, which the then employee passed on as the source of all interview questions. 



Fortunately, my colleague is an experienced engineer, but he agreed to go through this blatantly monotonous and mundane exercise to keep his job. He shouldn't have done this - the interview was not only a waste of his precious time, it did nothing for the hiring company to determine his ability. A colleague left after a year, tired of the low technical level in terms of hiring and ineffective management ...

Memory

The same arguments work when you write an algorithm in a particular language. On a real project, no software engineer would write a section of code without some kind of syntax checking tool (for example, built-in code completion in the editor), without reference to some kind of technical documentation, or simply without copying the finished solution, where is it perhaps. There is no point in reinventing the wheel.

I bet most of the code that runs on world systems today originated as a response to Stack Overflow.

For all its practicality, working with the syntax of a specific programming language begins with familiarity and application. The person interviewing you may think that testing your knowledge of the nuances of a particular language is testing your understanding of the language. For example, I can categorically state that although I have been writing in C for almost 30 years, I constantly miss the syntax.



In fact, as my career progressed and I became better acquainted with the languages ​​of interest to me, I was constantly confused about the nuances of syntax, say, C, C ++ and Objective-C. Not because I'm a terrible software engineer (although some may disagree ...), but because only the knowledge that you can hold in your head and recall immediately at any moment is stored in your memory.



A good engineer often doesn't immediately know the answer to a specific question, but he definitely knows where to look for it. Perhaps you want to ask where is the best place to find information about interview questions?

Common tasks

Something I have already touched on: this is a maxim - don't reinvent the wheel. For example, if you are working in C and need a serial port routine, do not write it from scratch unless the situation dictates it. Perhaps you need a JSON parser, a very common requirement - unless you are writing code on an embedded board with a limited resource, for a satellite in geostationary orbit or in Malbolg ; then maybe you should just pull out what you already wrote from the library. Most likely, the code has been used for a long time, it is fully tested and has detailed (and correct) documentation. It is reliable.



It is unlikely that in modern software engineering there will be a common task that has not yet been automated in the library, or whose algorithm is difficult to find.



If you are like me, and above all you work out of love for the subject, then you will actively seek positions where you implement what you have already written before: in search of strange, new worlds, new life, new civilizations ...

In fact, the concept of software engineers in the distant future has more than once been likened to code archaeologists, where engineers basically reuse existing code and spend relatively little time developing and programming new and new algorithms.

Discussion. Discussion. Discussion

I support finding out that the person you are hiring knows their business. But the methods above are completely useless in my opinion. I don't want to offend anyone, I say it as it is.



For example, simply talking about programming paradigms in modern software engineering, whether a language would be a good choice for a specific implementation, or whether a specific software engineering methodology (Agile, I'm looking at you) is a much more useful and relevant topic for discussion.



Lead a discussion to highlight areas of common ground, see how the candidate understands new problems, and possibly new alternative ways to solve old ones. How candidates see the development of things, how they would start to solve something. Stay open, stay away from details and trivialities.



The key here is discussion. I am constantly amazed that many of the companies that are considered "forward looking" and "leaders in their field" still resort to outdated, monotonous and completely predictable hiring methods, because they hardly appreciate the real technical vein.



It is often said that a job seeker should interview a company in the same way a company interviews him. I am totally for it.

Interviewing someone with a list of precise technical questions is always a red flag, especially when people don't want to drag out a discussion on any one issue. This often shows that the interviewee may not fully understand what he is asking about, and any answer that does not exactly match what is written in the script will be considered incorrect.

Let's sum up

Some companies have moved on to more efficient hiring methods, others - well, fall short. This is where I urge you fellow programmers not to get involved with companies that hire in the old way and insist on tests and programming exercises. Especially for long ones!



I've heard stories of companies asking for projects to be completed on a candidate's deadline, often taking days.



Others have generic "aptitude tests" for specific languages, multiple choice tests, where in a limited time, a hint of a fog in your head means you've failed the interview!



If you're a beginner, you might not be in a position to skip an interview, and I totally understand you, but I look at it as a learning experience. Go ahead, build experience, learn as much as possible, and if the job disappoints you, just move on. Moving forward, you will gain more confidence, knowledge and experience. After all, the company benefits from you, so you should benefit equally from the company.



If you, like me, are older and more experienced, just let the hiring company talk to you. We have a lot of experience, we have seen and done a lot, the qualifications are clearly visible in the resume and CV. And I am outraged that I am being guided down the general recruitment pipeline and my ability tested multiple times.



If you think you're a worthy employer and can't figure out why seemingly great candidates leave and leave, take a close look at how you hire people.

---

<>

• Data Scientist Profession
• Data Analyst profession

</>