Navigating the path to becoming a top-tier Software Engineer demands a diverse basket of skills and knowledge, which you usually accumulate through experience. However, if I had this software engineer skills list earlier when I was starting out - I would’ve focused on the right things from the beginning. And, as a result, would’ve saved enormous time for myself.
Some concepts here are very straightforward that everyone would expect a software engineer to know, both technical (hard) and more inter-personal (soft). And some, for the longest time I wasn’t even aware of until I found myself needing them, in a pinch, during project work. Nevertheless, I believe all of the items you find here are critical enough to be aware of, regardless of the type of work you do as a software engineer.
Also, including couple of these in the resume wouldn’t hurt! My thoughts on swe resumes.
Top Skills Needed For Software Engineer
This section contains key skills for software developers. These are skills that are acquired right from the start and engineers are expected to have in all work situations.
1. Programming Language Jedi
We all know that to do software engineering work, you need to know programming languages. A programming language to an engineer, is what a brush is to a painter. It all starts from that single language you spend most of your time working in. And that’s the language you would learn all the ins and outs of, from syntactic sugars to accompanying standard libraries. This foundational experience with a single programming language, ends up helping you read and understand code in many other languages as well, as things tend to follow the same pattern.
2. Domain Expert - Front End or Back End?
The more time you spend building software, the more there is to know. There’s a lot of work that goes into making the apps we use every day. And several technologies have to be combined end-to-end - front end, server, data storage.
Initially, you start by developing an in-depth expertise in a single domain like front end or back end first. You would need to know all the appropriate programming languages, frameworks, the process of how code changes get shipped, how builds/compilations work, and anything else required to make that area of the product work in production.
3. Debugging Skills
A lot of times when you’re building software systems, especially complicated ones, things fall through the cracks. So you end up dealing with bugs, servers going down, crashes, running out of memory, regressions, etc. Aside from writing code, a big part of the job is reading code, digging into the behavior and understanding what exactly caused the issues. Its a combination of interpreting code behavior. Using internal tools, profilers, and loggers. And poking at individual system components, until the smallest unit at fault is identified.
4. Work Stream Execution
This is all about your execution to deliver on the work steam you own and signed up for. So that in the end everything works end-to-end as designed. It’s a mindset of taking full responsibility and feeling accountable towards your commitments to your team and steak holders. Issues always pop up from the unknown, it’s important to embrace flexibility and take ownership of figuring out how to work around obstacles. Whether it be bringing in additional resources, or doing a PM’s work.
Technical Skills For Software Engineer
This section contains hard skills that a lot of software engineers become familiar with first hand.
5. Write Your Tests
We all know the classic test driven development! It’s important, especially on complex products, to write and have a suite of tests comprehensively cover the code base. As a result, engineers feel more confident making changes, code is designed in a more modular way, bugs and regressions are caught early.
6. Code Review and Code Standards
Reviewing code helps your whole team to unblock and move faster with quality. Here’s why it’s important: You provide feedback that the author can use to improve their code. You can catch potential disasters early. And additionally, code reviews enforce coding standards for the team, so that comprehensiveness, cleanliness, performance, and modularity is maintained.
This also leaves behind a paper trail of context that engineers in the future can find.
7. Migrations
Many software developers at some point have to handle migrations. In a general sense, it’s taking a system in its current state and moving it into a new one. This could be in the context of data storage, or tech stack, or server infrastructure. Quick tip, there’s a ton of knowledge online on how to approach migrations with different perspectives. Doing a little bit of research goes far, no need to reinvent the wheel.
8. Refactoring
Developing software is an iterative process. Nothing gets built in its final form right from the beginning. Same thing applies to code. Sometimes it’s rushed, or it’s an early new feature experiment that’s not yet state of the art. Afterwards, it’s on us to think through how to redesign our code to meet the needs of the future situation, as well as keeping everything extendable.
Something that would’ve helped me do better early on, is to have confidence in my own intuition. If a piece of code is hard to read or an architecture is complicated. Don’t stop there. The problem is not you, it’s the solution. Take it further, and think about how it would look like if this was easy to understand and was intuitive. You’ll get ideas of gold.
9. Feature Flags and Gating
When you are building new features or products, you have to isolate it from the entire system as you’re making progress on it. Feature flags are your tool for the job. What’s more, they will come super handy for setting up the rules of who gets exposure to your new changes during launch.
10. Distributed Systems
To build scalable systems, it’s important to know how to design distributed systems. I think that even for specific types of engineers that, for example, spend most of their time on the client, would serve greatly to know the fundamental concepts. Because they do come up in interviews, or in situations requiring to talk to the server infrastructure, or thinking through the product behavior. An awesome book, Designing Data-Intensive Applications, comes to mind.
11. Data Bases and Pipelines
Similar to distributed systems, data bases will appear everywhere. It’s one of the core things. It houses all the data and is the source of truth for any system. And where there is data, there’s the need to move them around - the art of writing pipelines.
There’s a ton of information online on types of data bases from sql to no-sql. On frameworks that leverage distributed systems to make pipelines work at scale. On data model design best practices. Research goes a long way.
12. APIs
servers-to-servers, components-to-components, servers-to-clients, talk with each other via a standardized protocol - apis - that you play a role in defining for your specific system. The concept of logic or business logic also go into this. It’s the series of steps the computer follows after getting that first communication established via api. All software engineers go through the experience of writing countless of apis and business logic code.
Advanced Skills For Software Engineer
This section of developer skills are more subtle. They’re things you start to think about further on in your engineering career. Especially, when the question of why build the thing, rather than how, starts to take prevalence.
13. Data Analysis and Metric Reading
Correctness is nice and all. But knowing if the system you built, brings you closer to the goal is crucial. After all, all products and features we ship are at the root - guesses. So it’s important to check, afterwards, whether the guess was right or wrong. This is done by establishing metrics with the idea that it’ll show whether you’re closer or further from the goal.
To feel the pulse of the product, as a doctor would a patient, it’s required to set up logging for data collection, aggregating this data, and finally interpreting from a single place what the data means.
14. Experimentation Setup and A/B Tests
On the topic of metrics and data, experimentations/ab tests fall into the same camp of arming you with evidence of whether your product is bringing you and your team closer to the goal or not.
Simply speaking, experimentation is the process of identifying an audience, providing the default (control) experience to one half, and the experience containing your changes (test) to the other half. Then, we log what people do in both groups and compare how the behavior differs.
This is one of the more exact-science based tools that brings to light the impact of your product’s changes compared to other approaches. So it’s important to really become familiar with how to setup experiments and interpret them.
Since this falls into Statistics territory. There’s a substantial amount of theory that you need to cover, all available online of course. Some things to look out for: statistical significance, p values, power analysis, sample sizes, dilution, over/under/imbalanced exposures, exposure logging, holdouts, backtests, etc.
15. Architecture Design
This is pretty straightforward and a core practice for many software engineers. In-between jumping into coding and aligning on the problem that needs to be addressed. We start off by kicking off an investigation to understand more in-depth the scope of changes required to build the system. All the while, taking notes and jotting down potential hurdles in an eng document. Finally, compiling everything into an outline of the high level approach, how data will flow, what apis there will be, the data model, etc. All-in-all the architecture of the system.
16. Product Led Growth
This falls mostly in the PM camp, but many engineers build products for a living, me included. For us, I think it’s a priority to work on our product sense. While a lot comes just from experience, my personal view on this has been making sure I’m making the time to feel the pulse of the product. i.e. Look at behavior logs and aggregated metrics, read experimentation results and user research reports. I think these are “ammo” for building the next iteration of the product in a data driven way, such that at the end of the work stream, the chance to hit a home run, which metrics should reflect, is maximized.
Overall, I really believe in the product led growth strategy and constantly look to nudge the flywheel. Where making data driven improvements to the product drives user delight, which drives more user advocacy, which drives more new users, and on and on.
17. Managing Technical Risks
During project development, there’s always options for different approaches, there’s always hidden issues that pop up, scope creep, delays. Yet, often we end up having strict timelines with downstream dependencies depending on the launch date.
There’s an art to risk managing a project. It involves consistently going through the exercise of de-risking it from possible derailments. And the approaches vary widely case by case. But some classic ones are - throwing more people at the problem, maximally parallelizing each work item, bring down the scope, setting up contingency plans.
Software Engineer Soft Skills / Leadership
We should all be on the same page that communication trumps all. And effective communication is a powerful tool for getting work done. Here are a list of some soft skills that I consistently observe highly impactful engineers to have.
18. Driving Alignment
As an engineer, you keep in mind a bunch of different factors that affect the project. Because often times, you are the one who exists on the interdisciplinary plane and have to consider both the technical and non-technical details. And understand whether they are fitting together nicely. As a result, you often find yourself in situations where there’s multiple point of views that make a lot of sense in the context of their own product area, but it requires skill to understand each view point and put together a holistic path forward that everyone can agree on.
19. Personal Conviction
Everyone expects the person in the driver’s seat of a project to have a personal perspective on multiple aspects of the project. Having an opinion and sharing it provides value to the team and the project. While there’s a balance to be had, especially with making sure that listening is also being taken into account. Over time, it is more and more important to be willing to share your point of view.
20. Project Tracking
Driving a project with any level of complexity requires tracking. So as a result, gaps are not missed, and major details don’t fall through. Even with extensive tracking, surprises happen. Without it, it’d be a mess. Also, having a way to track a project, acts as a medium letting you align with everyone on the project on what their part of the responsibility is. As a result, keeping everyone on the same page throughout the entire development process.
21. Working with Steak Holders
Software engineers work in teams. Which means also working with non software engineering partners - Design, Data, PM, etc. The success of the product does not only depend on getting the thing built. So it’s important to involve other functional partners closely, especially in product decisions. I’ve observed effective engineers be able to communicate clearly technical challenges in a non technical way, bringing every function to alignment. Resulting in an end-to-end solution spanning engineering, design, and product.
22. Defining and Setting Up Product Launches
Part of project development is to align with your team on what the launch looks like. There’s a number of factors to consider. Who’s going to get this update? How extensive the rollout will be, does it have to work correctly with every other system out the door? Is this alpha, beta, or general launch? How will external communication look like? Will the launch plan result in getting the data needed to make a call on whether there was success vs not? As the one driving the product, it’s on you to cover this and keep everyone on the same page.
Did I Miss Anything? Comment!
Cheers! ☕
Top comments (0)