Why Software Engineers Should “Always Be Interviewing”
This article was first published by Chuma Okoro on Medium.
This one is for you, fellow engineer. Folks in other career verticals, just observe.
Seeing the recent news about layoffs and hiring freezes at top tech companies like Meta and Twitter; anyone who works in tech must have their eyebrows raised. You did all that struggling to get your job as a software engineer and now the idea of losing that job, due to reasons out of your control, is real.
In most employment contracts, they indicate that you’re an at-will employee meaning you can get fired for any reason. This is why I’m an advocate of the philosophy, “Always be interviewing,” a state of mind where you’re always sharpening your skills and making sure you are marketable. The following are 3 reasons why I believe software engineers should always be interviewing.
Sharpen Interview Skills
Anyone who has gone through the software engineer recruiting process knows that the interview is the most difficult part. This is because it brings you back to the fundamentals of what it takes to be a software engineer. You cover things like core data structures, communication, tradeoff consideration, and nitty gritty system design. When on the job, for a significant amount of time, you might not regularly practice these fundamentals.
An example I thought of that demonstrates this comes from my background playing high school football. When on a sports team, you’ll normally have game day and practice. Game day is the actual test where you have to use the skills you refined throughout the preseason to win a game. With an entire season of real games, this doesn’t mean you abandon practice. In fact during the season, we would practice at least 4 days per week, honing fundamental skills that would come in handy during game day. This included pass rushing, form tackling, and practicing various scenarios that may come up during a game.
In the same way athletes need to practice their fundamentals during the season, software engineers should practice their fundamental skills during the job.
Now do you actually need to go through the whole interview process with several companies like you would if you didn’t have a job? No. Bringing back up the sports comparison, during the preseason you might have something called “hell week”. During this time period, you’re working really hard to prepare for the season. Then during the season, practices are a bit lighter than the preseason practices.
You can employ this same tactic when sharpening your interview skills. You can leverage platforms like Leetcode, Pramp, or even schedule a 1 on 1 with me to practice your interview skills with a mock technical interview. All of these are alternative tools to real interviews that you can use to sharpen your software engineering fundamentals while on the job.
Reaffirm Interest in Current Company
Let’s say we have two people who say their favorite fruits to eat are apples. One of them can afford to buy strawberries, mangoes, and apples whenever they’d like. They dabble in the other fruit categories from time to time, but primarily stick to apples. The other can only afford to buy apples. They eat apples just as much as person one, if not more, because that’s all they can afford. Which person would you say truly likes apples more? I’m in the camp that would say the person who can afford to eat other fruits but sticks with apples truly enjoys apples more.
I liken this example to the job market because it shows the different dynamic between choices made out of preference and choices made out of necessity. I’ve met many software engineers who stick with a company out of necessity. This is often because they decided to stop interviewing and honing their skills after getting that initial job. Now they feel as if it would be extremely difficult to get another job so they choose to stick with the one they have.
The alternative is someone who gets a job and continues to sharpen their software engineering skills. They know they could work elsewhere because they’re confident in their skills and may still receive job offers from other companies. In spite of this, that person chooses to continue working at the company they’re at. This is because they enjoy their job/company and know it’s a better situation than they could get elsewhere.
Knowledge of the Market Helps When Negotiating
It’s performance review time. You had a great year with company X. You know they value you and what you bring to the table. But you’ve been at the company for a long time and you don’t really know what the market is offering for someone as talented as you are. So when you get a high rating on your performance review, you accept a 3–5% raise and you’re happy with that. Then you find out a couple weeks later your friend with fewer years of experience just accepted a job from the same company. You’re happy for them because that’s big news! But then you find out their offer is almost 25% more than what you’re earning.
Maybe this is an exaggerated example, but things like this happen all the time in the technology space. The longer you stay at a company, the more removed you are from what the market actually offers for your skills. When you’re interviewing in the job market, you can get real data on what people are offering for your role. Now, when having a 1 on 1 during performance review time, you can see if it’s possible for the company to give you something more aligned with the true market value of your skillset. Of course, you shouldn’t go into the conversation with entitlement, but you can explain your case with real market numbers to support it.
A lot of these arguments could probably be used for other careers as well. But what do you think of the overall premise? Should software engineers or people working in other careers always be interviewing? Let me know in the comments below! Also make sure to follow and share if you enjoyed this article. If you or someone you know is interested in getting a mock technical interview/career coaching session, check out my Calendly to sign up for a slot. Thank you!
This article was first published by Chuma Okoro on Medium.