Our website uses cookies to enhance your browsing experience.
Your message has been sent. We will email you at
If you haven't received our response, please do the following:
check your Spam/Junk folder and click the
"Not Spam" button for our message.
This way, you won't miss messages from our team in the future.
A long time ago, I performed technical interviews on a regular basis — I was recruiting candidates for the position of a programmer in a company. I had a simple, clear, and smart recruitment plan (I did not invent it though). First, folks had a long interview where they answered a bunch of questions. Then they did some programming tasks. They were coding on a piece of paper — just like we did it at the university.
We published and translated this guest article with the copyright holder's permission. The author is Ivan Belokamentsev. The article was originally published on Habr. This is a guest article.
By the way, if you're wondering, in our company — PVS-Studio — we ask candidates to solve a task on a piece of paper after oral interviews. So, this article proves that we should get on with this approach. Or we can ask a candidate to write code on a computer in our presence. However, we are still focused more on candidate's theoretical knowledge. A developer should know the subtleties of programming languages to develop a code analyzer. By the way, why don't you take a look at the following article: How deep the rabbit hole goes, or C++ job interviews at PVS-Studio.
Looking back now, I see that the hiring process really worked well. All those candidates whom we hired became valued experts in the local IT community. More than half of them set up their own IT business ages ago, in a variety of areas — from the 1C software development to the CRM system implementation.
It was this exhilarating experience that clouded my mind. So much so that I decided to change the recruitment plan — I thought it was all about my personal achievement. I am a great technical interviewer!
I made a very simple change — now people were writing code on a computer, not on a sheet of paper. I thought, "Why do they have to sit there and scribble on paper, as if they are writing a manuscript in an ancient monastery?" I myself had forgotten what it was like to code without an IDE, context clues, debugging and other perks of modern development.
So, I gave tasks and a computer to a candidate and left them for half an hour to an hour. When I got back, I saw a ready–made solution. And not just ready–made, but very freaking awesome — the code was beautiful and well-optimized. It blew my mind — the current generation adored technology so much that writing code was like breathing for them!
And so did I hire these folks.
At first, things were going absolutely wonderful. I tracked my new team's productivity and efficiency, and continually marveled at how they were mastering new skills. In the old days, the first months had been challenging for new employees — the newcomers had been able to write code for a learning task, but they could barely cope with work tasks. In my case, I saw no such problem.
They breezed through simple tasks. I threw more complex tasks at them — tasks for those who had a year of experience. What did I get? My team handled these tasks without assistance! I was shocked and excited. What a wonderful generation is growing up!
I thought it would always be like this. I mean, I hoped the productivity would keep growing at its current pace. Aye, you wish!
After 3-6 months, all of them reached a plateau in productivity. Unfortunately, at the same time, they all started working remotely due to the coronavirus. And I was sitting at home and freaking out.
Time went by, month after month, but the productivity never improved. It's like they all could not break through the intern level. There were productivity extrema sometimes, however it was easy to explain: a large number of simple, monotonous, similar tasks. I kept freaking out and yelling in chats.
I thought the remote work was to blame — it made it hard for me to use my charisma. The people could have lacked motivation, live communication, and sometimes...a kick in the butt. In addition, our superiors did me a disservice — they asked me questions like the following: " Has productivity growth stagnated because of remote work?" Of course, I was saying yes. As soon as we return to the office, productivity would skyrocket!
Well, we got back to the office in August. We were sitting there and working. We had plenty to do – just needed to find the time (we had a shortage of tasks when working remotely). I was looking at the performance – it wasn't growing...damn it! I had to roll up the sleeves and dive into the problem myself.
I started with offering my help. Can't solve a problem? Come get me. I will come over, sit on your chair, and finish your task. You'll sit next to me and memorize the way the work should be done.
However, there were lots of them and only one of me. I realized this wasn't going to work. I had to deal with the root of the problem. I decided to go back to the beginning – the technical interview.
I no longer forced people to write code on a piece of paper — I just sat down next to them, gave a task, and the programmer tried to implement it. I had planned to carry out a series of such tests, starting from the basics, gradually raising the difficulty level. But it all ended at the basics.
It turned out that only one out of ten programmers understood how to work with basic entities, types, and knew their properties and methods. Even worse — only 2-3 people worked tolerably well with the built-in help and context completions. The programmers simply could not find properties and methods. Not to mention using them. They couldn't even do an elementary task.
Only one of them dared to ask, "Can I Google it?" That's when I — the idiot — finally got it.
It was like somebody hit me on the head with a sack of flour. It took me about two days to process it. How is it really possible? The beautiful, well-optimized code they showed me at the first interview was from the Internet. The explosive growth of productivity in the first months was due to the solutions that they found on the Internet. Those answers to user questions after the magic "We'll call you back" from these guys — were found on the Internet.
They were coding without understanding the basic constructs. No, they didn't write code — they downloaded it. No, that's not it, either. To download the code is like running "npm i", it's ok. They copy-pasted the code. Without knowing how to write it.
That's what angered me – what the...? Well, I understand when you surf the net to figure out how a new technology works. Or when you need to use some exotic feature and not to bloat your head with unnecessary information. But basic things! How can you copy-paste basic things from the Internet?!
Do you want to know what they said? "What's the big deal?" I was ready to join the monastery out of grief. I took a break, stopped talking to them, retreated into myself, and started thinking. Of course, I realized that it was not about them. I was the problem.
They only followed the laws of their own world. And I was the fool for not seeing these laws — I did not understand them, did not realize their seriousness. The seriousness of superficiality.
On my first day at the university, we were gathered in the lecture hall at the department. An old man who is also a deputy dean and associate professor told us: "The university does not give you knowledge. It teaches you how to get knowledge on your own."
I was lucky — I studied in the early 2000s. I knew about the Internet only from pictures. If you want to understand C++, sit down, and learn — here's C++ for you. If you want to write a term paper on surface roughness measurement, go to the library, read books, and write your term paper. If you want to present a history talk, go read journals. Yeah, you need to read one by one until you find necessary articles.
Unfortunately, "Google" programmers are not that lucky. Any information is available to them, always and everywhere. They've learned how to find this information quickly — whether it's the address of a store with cookies, pants on sale or generating a query.
Books say: the brain forms and, most importantly, precisely strengthens those neural connections which a person use. If you're constantly writing code, you're doing it better and better. If you are constantly looking for information on the Internet, you pump this particular skill. If you copy code from the Internet, you become a great master at that.
However, not all the code is open-source. Here comes the plateau. The productivity of a "Google" programmer is not a measure of writing code, it is a measure of copying it from the Internet. It's like the download speed. About 15 years ago, you could watch a movie only if you downloaded it first. Today only more adult generations do that.
Sometime, probably, "Google" programmers will outrun the ordinary ones. At least, in solving standard tasks. In the meantime, we will painstakingly form new neural connections for the use of basic objects, types and constructs of a programming language.
So that was a pretty bad fuck-up on my side. Shame on me.
P.S. And you know what? Go re-interview your programmers.
After posting this article, we got many unexpected comments here and on other websites. That's why we'd like to clarify that this article is a guest post on our blog. The author is in no way related to PVS-Studio. We translated and posted this article on our blog after getting the author's permission. We found the article interesting and wanted to discuss it with our readers.
And while you are here, we've got yet another provocative article for you: "50 terrible coding tips for a C++ developer".
0
0
0
0