The Work Experience in a Software Engineer Resume

Convincing a company to hire you is done by answering one question: “How can you contribute value to the company to make more money?”. The best argument you have in your hand most likely are your projects that made money since it will tell them that you know how to create value. But most people do not have projects that make money. So you can reference them to your past work positions on how you contributed value to these companies. So the basic question you have to answer is: How did my contribution impact the money flow?

Where to list work experience?

The work experience section is probably the most important one on your resume. It will describe how you contributed to the companies success. When reading this part as a recruiter or hiring manager, the hiring manager will look exactly for these facts. So overall the work experience, if relevant should be always listed on top of the resume. Before your education and also before your projects. If you do not have any work experience leave it off and create some projects and put these into the resume. Expand that section instead of filling out the work experience section. I will expand on this a little bit later in this article.

What to list?

The work experience should be a list of all your past positions that existed in a professional environment. What this means: You did a job and got regular payments. That could be freelancing activities, normal full-time positions but anything similar as well. So what should be included in one work experience? That is easy:

• Company Name
• City/Country
• The period you have worked at the company
• Title of position
• A bullet list of achievements

The first three bullet points can be clearly described. The last two bullet points are where most people struggle with. If you read this article you are probably looking for software engineering positions. If that is the case, then make your title sound like you worked as a software engineer. Do not change it too much but changing from software analyst to software engineer is ok. If the position is somehow related to software engineering like “Quality Assurance” then write down in the achievements what got done on the software side to ensure quality and what reduced complexity of writing tests.

An important part is that positions somehow match the position you are applying for. If your positions currently do not match at all, leave them off. This is especially true for smaller mini-jobs like bartending or mini-jobs at Starbucks for example. Leave them off and rather focus on your project descriptions.

Ideally, the list of work experience is sorted chronologically with the newest jobs first.

Work Backwards and Description

An important principle at Amazon is to work backward from a problem. It sounds weird initially but will make more sense the more we think about it. It can be applied to nearly every problem we face. A simple example would be a problem that simply needs to be solved, in our case let us think about a product feature. How would we normally think about the problem? We would try to find a solution to the problem. As software engineers, this problem-solving is done via programming most of the time. But working backward will give you a different approach. They will focus first on the other side of the process. We are thinking of solutions to something already without looking at the problem first. Is the problem explained well? Are all edge cases covered and can we go overboard with the initial problem statement to find problems that might be related to that. Then slowly working towards the solution. Just taking a step back.

We can apply the same principle to writing our description of the work experience. Let us think about what you might have done:

If you read it, it looks great. The problem here is perspective. Who will read your resume? Probably a recruiter or a hiring manager and they will say: “Great, what was achieved with that?”. People at the company want to see how you can contribute value to them. In the end, they will pay you to generate profit for them. So rather make sure this is enlisted in your resume. So let us work backward from the problem we mentioned earlier. The first question an interview will have: What product problem did it solve? If you have worked at bigger companies you can list the product name for example. Everyone knows what the Facebook newsfeed or the uber app personal settings are. But for most of us, working on products no one has ever heard about, you need to be a bit more clever about it. Write down:

• The main problem you have solved by doing the task
• For whom and
• by how much (Measure)
• Then explain how (normally a sentence that starts with by)

With these simple rules, you will probably nail the work experience descriptions.

Listing internships

A lot of people that start into their career ask themself where to put internships. Just put them into the work experience section. Internships are the most worthy experience you can get as a graduate if you have not worked full-time yet in your field. They should be highlighted and on top of your resume because it will tell companies that you know how to navigate in a corporate environment and how to work professionally with a group of people. Otherwise here you can handle the description similar to the structure above. Work backward and focus on the problem first before you dive into how you solved the problem.

How to handle promotions

Promotions during a job are a difficult topic to handle. You probably want to sell yourself first, so write the most recent position in the headline of the job. At the end of the description simply add a new point writing down your path as a software engineer in the company and mention that you got mainly promoted for key things during your time that you have mentioned before. This will help to strengthen the feeling of the hiring manager or recruiter that you are worth hiring. If they see promotions they will see that the company is listed on your resume even though that you are providing a lot of value. These days people tend to switch companies a lot and promotions will show that there is at least some effort to grow quicker than the company is doing. If you want to get promoted you can also check out my side project getworkrecognized.com that will help you to keep a work diary and create performance reviews, that focus on metrics.

What should I put on my resume for little work experience?

One of the most difficult things to deal with is no work experience. The reasons for that might have various reasons. But an important thing now is to learn how you can convince companies to hire you. There are a lot of things that some can do. But probably the best alternatives to real work experience are own projects and case studies.

Software engineering is a wide field with many jobs like:

• DevOps Engineer
• Backend Engineer
• Frontend Engineer
• Full-Stack Engineer

For each of these competencies, you could do different small projects that would help you to get jobs. Target them to the company you are applying to, and the company will actually like you already more because you personalized your application to the specific company. They will feel that you care already enough to improve their business and generate profit for them. Ideas for case studies and projects will be presented in the next sub-chapters.

In general, though, projects out of the main job will bring you forward. And even if you get rejected at a job, you will still have the case study/blog article for some next job. It will help you in the long-term to build your portfolio and proficiency.

Case studies and Projects for DevOps Engineers

DevOps engineers will be asked more often about system design. Their task in companies is to make building and deploying software to customers simple and fast. Other developers in the company should be able to deliver their code in outstanding times without any problems. Technologies like Terraform, CloudFormation, and Jenkins are essential to this role. But also how to scale traffic and load balancers within an application. To learn this type of technique I can recommend using the repository system-design-primer. It is a guide to learn how big systems can be designed for high traffic. But what can you do with it?

If you apply to a company, they most likely have a product. Imagine what part needs to be the most scalable because they receive the most traffic. Focus on these parts. Make it distinguishable between Read- and Write-traffic. Both of these need a different solution on how to architect the system. Create a blog or case study first on how you would build up the system or part of the product and then implement the architecture with Terraform or AWS CloudFormation. For AWS CloudFormation you could use the excellent solution localstack that will enable you to run AWS-like services on your local machine with docker. An incredible tool to run an AWS environment on your local machine. The most important bits of any scaling system are likely to be queues and caches like Redis. Both are easily imitated with localstack (AWS SQS, a queue system) and Redis within Docker. Build the simple architecture of part of the product and document it within a case study that can be a simple google doc you link in your resume or a blog article.

Case studies and Projects for Backend Engineers

Backend engineers are more specified than DevOps engineers. Nevertheless, they have to focus more on the backend side of things. This also means scaling databases, creating caches, and implementing queues. So I would suggest focusing on system design as DevOps engineers are doing but with a special focus on databases. Saving and reading data is an essential part of this job. It must be made sure that data can be saved by the customer, external or internal, reliably. This depends on the data. Analytical data might be not as important as a financial transaction, but that’s what the backend engineer understands and builds a system for. Of course, they will be able to scale the system design but also focus on the actual implementation. Which framework to use for which use case and which abstraction to take in the whole view of the company is an important choice. The same as what kind of database to choose. Do you have consistent and transactional data? Use SQL. Do you have a lot of unstructured and inconsistent data? Use NoSQL. Know the tradeoffs and the implementation detail. Showcasing your knowledge can be easy. Just choose an endpoint of the company you are talking with and implement it with your favorite or fitting framework and database. Make sure queues and memory caches are used in the right places and write about it. As in the DevOps role, write a blog article about it or a simple Google document that gets attached to your resume.

Case studies and Projects for Frontend Engineers

Frontend engineers probably have the easiest job to showcase something. Frontend development can be JavaScript-heavy but it involves a lot of CSS and styling most of the time. An idea for example projects is redesigns of the company’s product you want to apply for. For example, you could build a SoundCloud clone that looks similar but with differences. But you can also build examples based on landing pages and publish the components as an open-source package so other people can reuse them.

If you are more interested in the engineering side of frontend engineers, do some architecture overviews on how you structure apps, manage state, and many more. You can do case studies on how an app’s state should look like. For example choose SoundCloud, Spotify, or Airbnb and explain where you would put which data as an example.

Case studies and Projects for Full-Stack Engineer

Full-Stack engineers most likely have the most difficult job to prove their proficiency. They need to do the frontend, the backend, deploying the application but also design everything. I can just recommend creating a project, ideally software as a service, that is helping yourself or someone in your family. With that, you prove that you can program a full application. If it is integrating the APIs from the company you are applying for it is perfect. But most of the time these projects are kind of big already, so focus on the business logic itself.

Examples

In this chapter, I will now present some good examples of work experience sections from different experiences. So you can see what is done well and how good resumes look like.

In this resume, you can see that the author focused a lot on the product quality. Really well described so that everyone understands it.

This example of a resume is also quite good. The thing that is missing here is the measuring of the achievements. Otherwise, it is quite impressive for a recent graduate. As you can see the person had internships and positions within the university already which helps you with finding the first job.