So, you’ve passed the Software Engineer interview and are looking at a job offer from a potential future employer. The company has shown you its best side, the remuneration is good, and the benefits are decent. Yet you aren’t quite sure whether you'll be able to reach the next level with this Software Engineering job.
How can you be certain that this should be your next career move?
It often feels that when you are considering an offer from a lesser-known company, it is the luck of the draw that determines if the company is legit and worth working for, or a complete mess, right?
Wrong!
Information online for small and mid-sized companies is usually outdated, sparse, and sometimes nonexistent.
However, this doesn’t mean there is nothing you can do about it.
The recurring theme in this article will be if your future employer answers at all and how they’ll answer. Some of these questions are hard and may reveal problems the company is initially trying to hide.
If possible, talk to a developer from the team you will be working on.
You shouldn’t talk to an HR person. The team lead will suffice, and you are looking for answers related to the position you will be working on.
You want to do this before or after getting an offer—but you should know that you’ve passed the interviews. Don’t bother asking these questions unless they like you for the position, since you will likely have to meet again or at least have a phone interview.
In this post, we’ll discuss some powerful strategies and ways to get information about such companies to help you decide whether working there would be a good career choice for you or whether it would be best to keep looking.
If you are interested in articles on how to pass the actual interview, here are some general tips and some for the often overlooked behavioral interview, or if you prefer books—try this one.
Ask What Open-Source Contributions the Company Has
For one thing, you should expect the developers to have open-source projects or contributions.
For another, everyone uses open-source nowadays. A small percentage of company time can be dedicated to open-source projects.
Alternatively, certain company-built libraries can be open sourced. Most big companies have a variety of open-source projects, and if the company has none, it speaks volumes about its culture.
Don’t get me wrong—I understand that companies exist to make money. But when you are making money on top of open-source languages, frameworks, databases, servers, encryption protocols, etc., it sends a message about poor company culture if all you do is take and don’t add value to the foundations of your business.
Example question: “I see you are using [name of open-source project, e.g., MySQL]. Do you have any open-source projects in the company, or are you donating to it?”
Watch out for: “We are considering it”—99% of the time, it means “we won’t ever do it, but nice try.”
Ask About the Company’s Bug-Fixing Policy
How long do they wait before fixing mid-tier and minor bugs? The more they wait, the more technical debt is likely to exist in their system. Feel free to ask them concretely about what types of bugs they have hanging.
This is one of the questions where they may refuse to give specifics. That isn’t necessarily a red flag since there may be some nondisclosure issues. However, if they do give examples, it speaks volumes about the company’s transparency and their willingness to work with you. Most importantly, it sheds some light on the amount of technical debt the project has.
Example question: “Can you give me an example of an existing bug that is too minor to fix immediately?”
Watch out for: Anything that may become an issue if something in the setup has changed. For example, some padding issues in the mobile version are ugly, but the problem is ignored because the user base may not be mobile. However, using a deprecated function in a library will cause major issues upon upgrading and is the definition of technical debt.
Ask About the Company’s Code Quality Policies
Quality code is relative and ambiguous—though this is to some extent language-specific. What you should be looking for here is something along the lines of:
- Do they have a style guide?
- Do they use linters and validators?
- What are the steps in a code review? (There should always be a code review.)
This is a good time to consider whether things are done as a team or individually—there isn’t a right or wrong answer in terms of that; it depends on what you prefer. If, however, the reply to any of the questions above is “no,” that is a red flag.
The less detailed the code review and the less constraints on what design patterns, algorithms, or programming paradigms to use, the more freedom you have when developing.
Don’t get me wrong; there should be some sort of review, but if you feel you can carry more responsibility, you can opt for a company with a less strict code-review policy.
There is nothing wrong with having more thorough code reviews and sharing the responsibility collectively. The reality is that both types of companies exist, and you should be in a company in which you thrive.
Example question: “What linter do you use, and is your style guide fully implemented in it? Can you give me an example of how a code review is performed?”
Watch out for: “We depend on discipline” and anything that isn’t formally written. This leaves room for interpretation, which wastes time.
Ask How They Validate the Quality and Validity of a Feature
This, in layman terms, means how quality assurance (QA) is done and how the decisions left to the developer are evaluated.
The procedure here is different for every project, depending on scale, delivery type, etc. The details aren’t important, as they are likely to change. Rather, what’s important is that:
- There is a procedure in place.
- People follow this procedure.
There must be a clear QA procedure as to who tests the product and how, as well as when and how (if at all) any automated tests will be done.
Lack of QA is disastrous. Even the most detail-oriented person makes small mistakes every now and then. Although critical bugs should happen very rarely, they will happen. Most of them can be avoided by having another set of eyes look at the validity of the feature.
Although automated tests are almost universally agreed upon, few companies actually have them. A company’s having them reveals it’s dedicated to delivering reliable software.
Example question: “What is the QA procedure? What type of automated tests do you write?”
Watch out for: “Developers do QA. We don’t have automated tests and don’t plan on having any for any foreseeable backlog.”
Ask About the Company’s Deployment Pipeline
Despite having wonderful options and dozens of ways to implement deploys with zero downtime, this is often not the case—and you shouldn’t necessarily look for it.
What you should be looking for is automation. It will be better if they don’t use a homegrown solution, since, as mentioned above, there are already several great options. Homegrown solutions tend to lack documentation and features.
Still, as long as the deploys are robust and automated, the company is on the right track in terms of operations.
Another thing you should look for is whether the deployment can easily be rolled back. Sometimes a critical bug that wasn’t caught during QA does get deployed, and there should be a way to do this without having to change the head of the source code control repository.
As most questions have revealed so far, it’s a matter of company culture. If the operations of the company are done manually, this likely means that most of the development processes will be manual as well. Manual labor is proven to be error-prone, slow, and unreliable when compared to automated tasks.
Example question: “What tools do you use for automatic deployment? Can you rollback a version?”
Watch out for: Anything manual. Anything that can’t be reproduced or isn’t logged.
Bonus Question: Ask If You Can Use a Fraction of Your Working Hours to Study and Improve Your Skills
Although I support the “you are responsible for your own skill set” mentality, it is always nice to be able to do a part of it in the office.
How much of your time you should spend on developing your skills is a long conversation, but you have to do it if you want to easily advance in your career. Companies that invest in their employees are among the best companies with the most engaged workforces.
If there is a dedicated time for you to work on something extra, you can work on the company’s open-source project, take a course, or just read and try out some new tech.
In some of the companies I’ve worked for so far, you had up to one hour per day—five per week; two full days per month—which needed to be scheduled beforehand.
If the employer doesn’t want to invest in the developers, that is perfectly valid. After all, they aren’t paying you to improve yourself. It does, however, beg the question of whether you will progress in your career or not.
Example question: “Does the company have subscriptions to any learning platforms? Is it OK to take a bit of time to learn new things on the job?”
Watch out for: Vague replies, avoidance of the question. Anything that isn’t concrete or that speaks about a point in the unforeseeable future most of the time will mean “Your time here is to work exclusively on our projects.” Another thing to lookout for is when the employer says “I haven’t thought about it.” This is arguably one of the worst things that can be said, since it shows lack of interest on the employer’s side to invest in the developers or shows just the boss' plain ignorance of how software development works.
It’s About Preparation, Not Luck
Before accepting a new job offer, make sure that you know what you are getting yourself into. There is no point in losing time and opportunities to work for a company that doesn’t suit you or your goals.
There is a shortage of skilled developers, so make sure you secure a job with a company you will be happy to work with and feel you can add real value to.