Introduction
First of all, I haven't done much work at different companies so my knowledge is somewhat limited, so don't take this as me claiming to be an expert. However, I have had the privilege of working at two companies which were both great in different ways. As many people seem to be submitting mass applications with the assumption that all software engineering roles are the same, I want to demonstrate that this is simply not the case. So much goes into what your experience will be like as a software engineer, and I hope to provide you with some ideas for questions you can ask to deduce that for yourself. I'm steering clear of giving opinions as much as possible, just questions that you can ask to discover the differences by yourself, and then make an informed choice on your own. Once you start asking these questions, you'll realise how much the roles can vary.
This article is aimed at unviersity students looking for their first graduate job. If you're beyond that stage, this may not be useful to you.
What Isn't Worth Asking?
Questions like this are far too common, but simply aren't that important:
- What will we be working on? It's natural to jump to this question first, and it's definitely nice to know what impact you're having. However, this will only affect your day-to-day experience to the extent that it impacts processes (e.g. medical companies will be more risk-averse than average, slowing the pace of development).
- What language(s) do you use? All mainstream languages are somewhat similar and you'll pick up any language you need to. Whichever language you're using, your day-to-day work will be fairly similar. Unless you really passionately hate the language they're using, in which case I'd give it a miss.
Salary & Benefits
This is about the only thing graduates are really good at looking for! Definitely look at this, but weigh it up against the other things I mention below, depending on how you prioritise different factors.
Releasing Code
Ask yourself questions like:
- What does the journey look like from receiving a task to it reaching production?
- How do code reviews work?
- How often do you release code into production?
- What automated testing is used?
Understanding the processes to produce code on a day-to-day basis is crucial for determining if a company is the right fit. Companies differ a lot in how they work, and there's pros and cons of each approach.
For example, if a company releases to production twice a day that tells me that they've got really strong processes that they're confident in. If a company has a policy of everyone getting code reviewed by 2 or more people, that suggests a lack of trust in the developers. If junior engineers aren't allowed to review PRs from more senior members of the team, that suggests more of a rigid hierarchy although you'll miss out on some of the learning that comes with reviewing PRs. If a company doesn't do unit testing, you'll be able to develop new features much more quickly, although it's easy for new features to then break old ones. If the automated checks to merge a PR take 3 hours, you'll have to keep going backwards and forwards between different tickets, instead of focusing on one task and then finishing it.
Prioritising Work
For example,
- How much customer interaction do developers have?
- To what extent to developers have ownership over which tasks they work on next?
- How much technical debt is in the codebase?
- Does the company make stuff based on a contract, or for customers directly?
Some companies are very developer-led, but most aren't. Often, a project manager or equivalent will be in charge of deciding what work is prioritised. There's a scale of this whereby some companies will force you to take the top ticket on jira and make it pass the acceptance criteria, others will let you take from the top few, but with others the engineers will be making the tickets. This can be great because you can focus on coding as you don't need a wider picture of the company, but it can also remove agency from developers which causes you to lose motivation as you're not as involved in the customer-facing side of the business. If you've not got any agency, it can feel like producing stuff to a contract, versus producing stuff for customers directly. Lots of clarity over what needs doing, but if you think you can solve the customer's problem better than what it says in the contract, then you've got to ignore that and just deliver the contract. It's also important to find out about technical debt, and particularly what the culture is like around prioritising user-facing features only or if maintaining the codebase is seen as worthwhile too. No-one wants to work in a terrible codebase!
Learning & Development
Questions such as:
- How long does the onboarding process take?
- What opportunities are there for learning and development?
- How much feedback is generally given during code reviews?
- How consistent is the skill level among the team?
- How often do you do retros, where you discuss ways of working within the team?
It's also vital to consider how this role will allow you to learn and develop your skills. Some companies contribute hugely in training and budget, whereas other's dont, but there's far more to look at beyond the training. Code reviews are the biggest way that you learn on a day-to-day basis, and if there isn't a culture of giving useful feedback on each others' code, then I'd be wondering how much you'll learn. It's also very common for graduate jobs to have a lot of onboarding time - you might enjoy a slower beginning where you're paid to learn stuff without the pressure of delivering features, or you might find it boring and frustrating as you've got to wait months before you can have an impact. Also, check that a company is going to let you loose on their proper codebase - if they're not, then you won't feel like you're having much of an impact, and their processes probably aren't very good either!
Conclusion
There's many more things to think about, but these are just a few I think are particularly important. Don't be afraid to contact recruiters with your questions beforehand, it's much better to make a few really good applications that you're keen on than to apply for everything and hope for the best.