4 More Red Flags of Terrible Developer

Run away from these people.

The first part of this article went viral. More than 10k people read it in a week. So I decided to continue the theme about red flags on tech interviews.

A great developer gives you value and improves overall team performance. An awful one — kills team productivity. It’s better not to hire a great specialist than hire a terrible one. The price of a mistake is too high. You can’t allow it to yourself.

It isn’t an easy task to interview a person in 1 hour. You can’t ask all the tech questions you want. Not enough time to check all soft and hard skills. But here are 4 more red flags that you should pay attention to.

No Live Code

It’s OK when the developer refuses to perform a test task. Usually, they are unnecessarily complicated and time-consuming. A candidate can’t allow himself to spend 3–5 hours “test coding” for each company. Appreciate your and his time.

But it’s super weird when someone refuses to do a short live coding session. It doesn’t take more than 10–20 minutes. Less if the candidate is excellent.

Live coding should be a mandatory part of any technical interview. Actually, this is the only efficient way to check coding skills.

It isn’t complex for an experienced engineer to write a simple algorithm. Reverse array, play with collections, or draw some specific sequence in the console. At LeetCode it would be an “easy”-level challenge. But you can observe and then discuss the candidate’s actions and code.

Trying to avoid live coding is a very suspicious sign.

Bad English

It may sound strange for native English speakers. But a lot of people in the IT-sphere have poor English. Out-source and out-staff companies in different countries conquer the market. The developer has to explain tech topics to the non-technical part of the team in English, of course.

If your vocabulary is too poor, you can’t explain to PO why some idea is technically impossible. You can’t propose and then defend in a dispute a better solution. You can’t give helpful testing tips to QA specialists.

You can’t even write a good quality code. Because surprise-surprise you write code in English. Names for your functions and classes should be clear and precise. Relations between them should be explicit too.

Maintainable code — readable code.

Switcher

This one applies more to Junior developers. It would be fun to imagine a Senior developer with 5 years of experience as a switcher. Even that is possible too.

Switcher — a person who wants to completely change the field of work. For example, move from teaching Spanish grammar, riding a cab, or plumbing the tapes to the software development area.

There is nothing wrong with such a desire. But usually, switchers lack solid background knowledge. I don’t force anyone to get a bachelor’s degree in Computer Science. But if you have one — it gives you many times better foundation than a developer without it.

Sometimes switches are super motivated, which compensates for everything. Then it’s a worthy addition to your team.

Salesman

This one is easy to detect. The salesman won’t talk about the code or technical part of the job. He gonna try to sell him. Using an arsenal of tricks. Here are only the most popular ones.

• Mentions a big tech company, maybe even FAANG he is applying now.
• Tells you about a couple of offers he got already.
• Points out that he is not really interested in the position and has 20 similar to choose from.
• Engages you into selling a company to him, not contra verse.

Seeing these tricks, instead of required knowledge is a signal to stop the interview.

P.S. If you liked this thing, follow me and clap a couple of times. Good luck!