How I Looked for a Job, or How Not to Conduct Interviews
A web developer recounts his experience attending 17 job interviews in a single week and shares lessons about what companies do wrong when hiring programmers.
So, the decision had been brewing for a long time, and one overcast Saint Petersburg morning, I told my boss that, unfortunately, our paths were diverging. A resume was drafted, more or less describing ten years of experience in web development. A salary figure was decided upon — slightly above the Saint Petersburg average, but far from top-tier (I'm no guru yet). I paid for a service to bump my resume to the top every four hours, installed an app to record all incoming calls (so I wouldn't forget anything), and sat down to wait. It was actually a Friday evening, so I had to wait until Monday — but Monday is when all hell broke loose.
There were a lot of calls. Over the next week, I attended 17 interviews, 3-4 per day. By Thursday, I had already stopped accepting new interview requests, but the calls kept coming and coming.
This isn't one of those "look how everyone wants me, I'm amazing" articles. I simply want to point out that right now there is a shortage of IT specialists in Russia, and when a suitable candidate walks into your company, what matters is not only whether you like them, but also whether they like you — because the competition, it seems to me, is more on your side, the employers' side, than on the programmers' side. I should note upfront that I'm not talking about companies like Yandex, VKontakte, or Mail.ru — things are clear with them. I'm talking about second-tier companies, the level just below.
The IT Lead
Different companies call this position different things, but essentially it means the lead developer. Attractive girls from the HR department are nice and all, but for me, the face of the company is the chief technical specialist. It's usually this person who handles the technical part of the interview. Take the selection of this person seriously. I judge the company's level by them.
For example, at one company I was asked how closely I had worked with "Code Injector." My puzzled look provoked a disapproving "hmm..." and a reference to the line "CodeIgniter" in my resume. "Come on, Vladimir, you wrote that you worked with it."
Another very trendy question these days is "Have you worked with MVC?" I always want to respond with "Do you even know what MVC is?" I've gotten the impression that most people think this pattern is just another framework. It's always interesting to see whether there are follow-up questions after my brief "Yes" — and if there are, that's a big plus for the employer.
Why is this so important to me? I'm still young, and I want to grow at work. Like it or not, the tasks solved at a company more or less correspond to the team lead's level, and those tasks shouldn't be noticeably below mine.
HR Managers
How much time I wasted because of these people. Several times I showed up for interviews only to discover, to my surprise, that the company had absolutely no projects related to my specialization. And on the phone, they had assured me otherwise.
The hit of the season was confusing Java with JavaScript — that's how I ended up at three interviews with mobile app developers.
Part of the blame is mine — I should have asked the managers more detailed questions during phone calls. But more often than not, they simply don't have enough knowledge to answer my technical questions, and the conversation boils down to them saying my resume fits, and they have free meals, a break room with foosball. Perhaps HR managers justify their existence in other fields, but in IT, hiring specialists should be handled by someone knowledgeable. Or at the very least, the HR manager should be in close contact with the technical specialist.
Salary
Oh, the most painful topic. When you dial my number, you should understand that the figure listed in my resume is not the limit of my dreams — it's the minimum threshold at which I'll agree to work for you.
I really loved this line: "Well, for the three-month probation period, you'll receive one and a half times less, and after that, we'll try to bring it up to..." First of all, I'm not thrilled about struggling for three months. Second, I don't quite understand the word "try"... It feels as though I came begging them for a job, I have nowhere else to go, and they're doing me a favor by hiring me — but they can't promise anything.
There was one very strange case when I was invited to an interview at a company after they listed their projects over the phone — projects that genuinely impressed me. In a fancy business center, I was seated in a very comfortable chair. They asked many questions, clarified my answers, and then, almost in passing, mentioned that they were having some financial difficulties and that I wouldn't receive my first paycheck for three months. When I looked at them in surprise, they said it was no big deal — I could just take out a loan to get by in the meantime.
The Test Assignment
I'm all for test assignments. After all, a future employer needs some way to assess my level. For some, a conversation during the interview is enough — a detailed account of what I did at previous companies, what technologies I used. Others hand over a sheet of paper with questions I must answer in writing. Some send a spec before the interview or give it as homework afterward.
The first method is the most convenient for me — just talking about what tasks I solved, how I solved them, what problems came up. It's not that hard and doesn't take much time.
The second is the hardest. First, it's very unusual and uncomfortable to write code on a piece of paper. Second, it feels a lot like an exam — something that probably every young person has a deep subconscious aversion to. And third, an interview is stressful, which distracts somewhat from programming.
The third option, in my view, is the most optimal. It lets the programmer tackle the spec in a calm, home environment, maybe with a cup of tea or coffee, using familiar tools.
But it's important not to go overboard. For example, one company sent me a spec that would take about two days of work. I understand that from my implementation of a reasonably large task, you can learn a lot about me — but please understand my side, too: I'm running around to interviews all day, and I simply don't have time to sit down at a computer for two days straight. Large specs are only relevant if you're the company I really want to work at and I'm not considering other offers. If I got an assignment like that from Google, I'd obviously do it — but let's be honest: are you Google?
Speaking of Google. There was one very odd interview at a small advertising agency where they didn't ask me a single technical question but instead gave me a list of Google interview questions. And while Google splits that list by role, they gave me all of them at once. I should note they never called me back. Apparently, I won't be working at Google.
Organizing the Interview
If any managers or HR people are reading this — I'd like to address you: please approach the organization of interviews more seriously. Consider not only your own interests, but also those of the candidate.
The first thing that's really annoying is the quest called "Find Our Office." Nowadays most company offices are in business centers. Finding the business center itself isn't a problem — worst case, I have GPS on my phone. But finding the actual office is quite a challenge: "Take the escalator to the second floor, go to the left wing, then take the elevator to the fourth floor, there are two doors — ours is the right one, walk to office 435, then go left until you see a red phone. Dial 163 on it and say you need..." If you're hard to find in a business center — don't draw a treasure map; just come down and meet me.
Also very trendy right now is the "series of interviews" approach. First an interview with HR, then with the direct manager, then with the director. And all on different days. Often even in different weeks. Again, this works if I've set my sights on joining specifically your company. But if I'm actively job hunting and you're not offering anything that sets you apart from other openings — I won't wait.
At one company, I first met with the HR manager, then a few days later I was invited to meet the head of HR. And a few more days later, the CEO. I declined the last one. The first two meetings were completely identical — the same questions and, accordingly, the same answers. They didn't touch on anything technical at all. I suspect the third interview would have been more of the same. Note: three interviews, and not one with a technical specialist.
The worst thing you can come up with is a group interview. Three candidates on one side, one employer on the other. It was simultaneously awkward and stupid. It looked like some kind of reality show. I don't know, maybe it was some psychological test...
Conclusion
The thing is that programmers are in a special position right now — we get to choose. This isn't luck (how many times I've heard the phrase: "You're lucky you're a programmer") — it's the result of hard work. While most of our peers spent their nights at clubs, we were sitting with books and keyboards. While most of our friends watch comedy shows with a bottle of beer after work — we're still sitting with books and keyboards. Our profession demands total dedication, and it's only natural that we can say "no" to a company that didn't make a positive impression on us. If you want to hire an experienced programmer capable of not just solving tasks but doing so competently — approach the organization of your interview process a bit more seriously.
FAQ
What is this article about in one sentence?
This article explains the core idea in practical terms and focuses on what you can apply in real work.
Who is this article for?
It is written for engineers, technical leaders, and curious readers who want a clear, implementation-focused explanation.
What should I read next?
Use the related articles below to continue with closely connected topics and concrete examples.