Over the last year, I’ve reached out to almost 1000 engineers trying to get them to interview for Bolt. I’ve had some success and plenty of failures. But I have learned a lot about how people approach interviews and career development. And I’ve identified seven “anti-patterns” that I think are detrimental to a successful career.

In this article, I want to share these anti-patterns with you. I also want to share my approach to effective “job searches”. I hope these will prove useful to you.

I’m gonna work off some assumptions. You’re a software engineer with some years of experience. You want to get the most out of your career. You’re based somewhere in Europe, the US, LatAm, or so. Life is going OK for you and you want to optimize your long-term career. If this is not you, then you may or may not get something out of all this.

Now it’s no secret that we are living in a golden age for software engineers. Software is eating the world, and demand for devs is far outstripping supply. Developers have their pick of projects, high compensation, and cushy jobs. If you’re looking to have a great career it’s never been easier. But it still requires work, planning, keeping your ear to the ground, avoiding some common mistakes, and even taking a 40-year view of it.

And as some of us know, it wasn’t always like this. The .com crash was a situation opposite to what we have right now. And things have only really gotten good since the 2010s. A reversal to the mean is still within the realm of possibility. That’s why I think it’s important to make the most out of this situation and strike the iron while it’s hot. Avoiding the following anti-patterns is a good start.

My Background Doesn’t Match The Position

I was looking for backend engineers to work on our microservices-based systems. But I cast a wide net when reaching out. I wanted to speak with folks from embedded, security, low level, and kernels. And I was also keen on people working in compilers, networking, or automotive. But I got a lot of pushback and even questioning of my approach.

But “backend” development is different. It’s the place where “business logic” resides. Often, it is not so much about the technology as it is about describing the laws that govern the business. As such, any developer can be a backend dev! There are still notions of architecting and scaling a system that does require expertise. But that’s not a day-to-day thing. And in general, engineers help by solving problems. Not by knowing technologies or being experts in this or that tool. There’s great value in mastering tools, but only as a means to solving problems. Knowledge for its own sake is an anti-pattern too!

At Bolt, we have folks from a classical backend background, of course. But we also have former mobile devs, embedded ones, or ML people. They’re doing great and their previous experience comes in handy often. And they gravitate towards the projects that highlight their strengths.

I’m A Blub Developer And You’re Using Blab

Even when I reached out to backend developers I got way too many “I’m a Java/C#/C++ dev, so I’m not sure I’m what you’re looking for” answers.

The skillset you developed is being able to solve problems, having engineering maturity, and understanding what’s needed in large-scale software projects. That’s why we want to talk to you. That’s what companies value, in the end. Regardless of language or ecosystem, you’re going to need to solve problems. And you’re going to need to build reliable and scalable solutions. Or take part in code reviews, write tests, ensure the quality of your solution, etc.

Again, speaking from experience, very few of our devs have used Node+TypeScript before. Yet they still do their first release in their first or second week of working with us. And pick up the rest and become proficient in a matter of months.

I Have A Fancy Title And I Don’t Wanna Give That Up

This came up a bunch too. Folks had Architect, Staff, or Principal titles. But I was hiring “just” for a Senior Software Engineer. So I got a bunch of quick nopes. And a bunch of longer nopes from folks who wanted to understand a bit more but decided against a “downgrade”.

Titles do matter. But titles are very company-specific too. For example, product companies usually don’t have the Architect position. As a famous example, none of the FAANGs do. Likewise, startups usually don’t have more than “Engineer” or “Senior Engineer”. Even in established product companies, there’s a wide variety of post-senior role structures. There’s alsotitle inflation to consider. And different companies have different expectations. These things become more of a way to express something internal to the company and not some global truth. You’re limiting the kinds of cool companies you can work for by focusing too much on the title.

We’ve had many folks join as regular engineers who were Staff engineers, or Architects, or Tech Leads, or even managers. They’ve all thrived, managed to put their experience to good use, and then “got back” the title in our context too. And of course, even their compensation increased as a result of the move.

There Are Too Many Senior People

This one caught me off guard. Some folks worried that there would be too many other senior people in the engineering teams. And there would not be enough room to get to those limited leadership opportunities.

But this approach is counterproductive. You never want to be the best in the group. You rather want to surround yourself with people you have things to learn from. If it’s a good collective then it’s bound to also have success. And then at least you’ll catch the rising tide that lifts all boats. But most likely the organization will expand, and you’ll get that chance you were looking for, in the end. Being in a higher-performance team will reflect better on you at the end of the day.

At Bolt, there’s no limit to ownership or leadership. It’s more about the things you do, and not the position you are in. The same holds for managers and individual contributors. Case in point, a lot of the critical processes at Bolt are run by folks who took an interest in them. Our hiring pipelines, our coding interview process, etc. are good examples.

I’m Not Good For The Interviews Or For Bolt

Again, this one caught me off guard. Some folks found the position attractive. Yet they didn’t want to apply because they didn’t see themselves as ready or good enough.

This is an insidious anti-pattern. You might be judging yourself harshly, or us too well. You might be viewing the situation through the lens of impostor syndrome. Or of perfectionism. Even if the technical skills aren’t there yet, a company might still see enough potential to make an offer. Or the internal context is such that something can happen. It’s not all black and white, even at bigger companies.

We have folks from very diverse companies. Ex-FAANG engineers as well as 3-person shops. Product companies and outsourcing companies. Competitive programmers and self-taught devs. I’d dare say success is orthogonal to this sort of background.

I’m Looking For An Upward Move

A fair number of folks were looking for an upgrade to their current position. They were junior devs seeking a particular senior title. Or inexperienced managers seeking to transition to a full manager role. Or even folks without any management experience seeking to gain it via a move.

The truth is the scope of your work rarely increases when changing jobs. The salary - sure. Especially in the first part of your career. It’s even expected every job change has a comp increase. The “title” can change too. You can get an upgrade when moving to a startup or smaller company. Or a downgrade when going to a bigger company. But companies tend to be conservative on the experience side. They will look for “demonstrated experience”. And there’s nocompression algorithm for experience.

A common pattern at Bolt is for someone to join and take on more ownership and responsibility. They’re then swiftly promoted. We’ve even done promotions during the probation period for folks who were clearly next-level. It is not just the transition, but the growth that can happen after.

I’m Happy Where I Am / I’m Not Ready For A Change

This one is gonna ruffle some feathers. A fair number of folks didn’t want to talk because they were happy with their current gig. And not looking for a change.

Finding a place with great colleagues, challenging projects, and good compensation is hard. You don’t wanna lose that if you have it. But the number of these employers keeps increasing. Even in the outsourcing-dominated Eastern Europe where I’ve got the most context. And what was great a couple of years ago, might be OKish today.

In the end, leaving a company might not be the irreversible move it’s made out to be. I’ve seen enough folks jump from Company A to Company B and back to Company A. Sometimes in a month.

Conclusion & Next Steps

Thanks for coming to my TED talk. You now know some things to avoid. But the tone so far has been sorta’ negative and I don’t feel good ending it like this. So I want to give a small “job searching” framework you can use as a guide. It consists of three rules to replace the anti-patterns form above.

First, look at the team and project you’ll be working on as well as the wider product you’ll be embedded in. Think about the future growth of the company you’ll be helping out and how that can affect you. Tie all these to whatever career plans you have. Only then consider technology-specific reasons. Especially avoid going for one thing - playing with Scala, or using K8S.

Second, aim to find the highest performing collective that will have you. This is very important in your early career. The dividends it will pay off will more than offset “title deflation”. Once there, take on responsibility and ownership and try to grow as fast as the company at least.

Finally, treat interviews as a skill to practice and as a tool for exploring the “market”. Not as a chore to only do when you’re forced to switch jobs. Rather you should do them even when you’re not “actively” looking. You want to get good at them. And you want to use them to better understand the market.

Anyway, that’s enough from me. Thank you for reading this far! If I’ve managed to get you excited you should know thatBolt is hiring. If you’re an engineer who wants to avoid the career anti-patterns - or know one who does - then come our way at careers.bolt.eu. Or DM me on LinkedIn and I’ll sort things out.

Thanks to Mihnea DB, Mihai S, Radu V, Liviu C, Foti C, Radu S, Tomasz R, Sergey Z, Lauri L, Andreea C, and Nick G for tearing the first draft of this to shreds and forcing me to write a leaner and meaner text.