The Mid-Level Software Engineer Resume

    Writing a resume for your second job can potentially be more difficult than the first. For your first you either don’t have any experience, or maybe just an internship, and that’s kind of expected. There are very few requirements on entry level software engineers and passing a code screen and some silly HR teamwork questions is often all you need to land a job. The resume for your second job has to fill a very different role. It must show that you have developed some level of technical expertise, contributed meaningfully to team projects, and that you aspire to do more with your career. That’s a tall order for what is likely a one-page resume. It can be difficult to communicate all this information without being excessively wordy, but you also have to hit the right set of words to get past automated screens and the occasional HR person that might be the first set of eyes on your resume before it even lands on the desk of an engineer.

    Here I’ll share what I think are some good tips and a general format for writing your second resume. Keep in mind, these are only my opinions. I am not a recruiter and not a manager. I’m just a mid-level software engineer with an ego who has looked at some truly crappy resumes belonging to my peers. There’s not a “right way” to write a resume, just a ton of wrong ways. So hopefully this will help you upgrade your resume into something halfway decent.

Part 1: The Header

    Your resume needs a header with the following information:

• name
• phone number
• email address

    Optionally, you can include a title. I would only include that if you have a PhD or something that not every other candidate can also put on their resume.

Part 2: Education

    Here add your alma mater, when you graduated, your GPA, and your major(s) and minor(s). If you have any certifications this can be an “Education and Certifications” section.

Part 3: Employment

    Time for the most important part of your resume, your employment. In this section you will enumerate your places of employment (likely only one or two places) and postions (likely only one or two positions). Start by listing all employment history down to internships (high school jobs or retail jobs are not worth adding after you’ve had your first position for a few years). Add the general time (month + year) that you held the position.

    Under each title list your “accomplishments” while you worked in that position. I air quote accomplishments because this can also be core job responsibilities, just phrased in a way that implies you accomplished something (even if you didn’t). Basically, just state what you did as directly and assertively as possible.

    Here are some example phrases you can use under this section.

• Developed “X” to accomplish “Y” using “Z” technology
• Automated “X” using “Y” to simplify “Z”.
• Managed “X” project to achieve “Y” result.
• Led “X” to accomplish “Y”.
• Maintained “X” system used to process “Y” data to ensure high availabilty.
• Mentored “X” engineers to obtain “Y” skill.

    The list goes on, but you should notice a general format emerging from this. You did some specific that accomplished some specific task using some specific technology or methodology. Each one of these should be a potential talking point in your interview. These statements do simplify the story, but unless questioned on them then it’s fine. If you are questioned about any points in this section you should be able to answer them without missing a beat. Each one of these points should be a story that you have rehearsed in your head and have thought about every possible path a conversation about the topic could go down. That may sound like a lot of work, but it is necessary to be well prepared.

    If writing in this format is difficult, just start by writing down all the things you did at that position, you can work on polishing up later.

Part 4: Technical Skills

    Next up you should list your technical skills. This can include a variety of information from programming lanagues, to frameworks, to technical stacks, or operating system skills. This section should not take up too much space on your resume. If your resume lands on an engineeing manager’s desk and there is a clear mismatch between a candidates purported skills and their job experience this can raise questions.

    Whatever skill you put on this section you should ask yourself, “could I handle an entire interview solely regarding the nuances of this skill?” If the answer is yes, go ahead and put it on there. If not, you may consider omitting it. However, omitting something that shows up in your job responsibilities can be a double edged sword. For instance, if you work in some analytics stack, but don’t have any analytics tech in your skills then that might also be a red flag. If you are in this scenario where you have a job responsibility that you are a little uncomfortable interviewing on this may be a sign that you need to pick up a book prior to your interview so you can speak reasonably well about this skill. Not all interviewers will grill you like this, so depending on where you are interviewing you may or may not embellish this section a bit.

    Here is my “Technical Skills” section from my last resume as an example. I personally put skills that I am most interested in first, even ahead of things I may be better at. The ordering is largely preference, but try to make what you want to catch the most attention come first.

    As with your employment information I would just dump everything you know on this section initially then pare it down after your first draft.

Personal Projects and Extracurriculars:

    Depending on where you are applying it can be useful to talk a little bit about your life outside of work. This can come in various forms, from volunteerism, mentoring, or personal projects. Often when interviewing candiates the interviewer (or in some cases the HR person) is looking for someone who shows their passion for their field via open source work or helps out in their community somehow. This lets them use you for positive PR gimmicks, or at least lets them say “oh, our employees care about the community” or some bullshit like that. All of this is secondary to their bottom line, so your employment and technical skills better be up to snuff, but it can be the cherry on top of your resume.

    If you are advertising personal projects, include the name of the project, the tech stack, and what it does. Unless it is a major open source project then you don’t need to write a ton here, just a sentence or two explaining what it is.

    If you are writing some sort of community involvment thing on your resume (technology related or not), treat it like your employment section. If you organize some sports group, that’s fair game. Point out the scope and responsibilities, just like a job.

No “Objective Statment”?

    You may have noticed that I do not include any “objective” section in this resume. That may have been useful on a entry level software engineer resume, but it has no place after that. The objective statement would likely say what tech you are interested in working on, but that interest should be obvious based on the specific position you are applying to. When applying to mid or senior level positions you are applying for specific teams that have their full responsibilities and desired skill sets listed on the posting. This isnt always true for FAANG jobs, but as a general statement I find that it holds. If you are switching major tech stacks you are working on (like moving from analytics to front end work) then a cover letter becomes nessecary.

    You can think of a cover letter as an extended objective statement. But where the objective statement is only one sentence that likely doesn’t make the case for your interest, the cover letter makes up for that. It gives you the room to make the case for why your skills are transferrable, and lets you talk about what it is that interests you in that realm of technology. I reccomend having a cover letter ready for almost every job you apply for. Once you have one it is a relatively low effort task to adjust it for a given position and it can help set your application apart from someone who has the same experience, but no letter.

Other info and closing thoughts:

    The resume is the first step in your job hunt and it pays to get it right. Have several people review it. Have your teammates review it, an engineering manager (for obvious reasons probably not your current manager), a professional editor, and an engineer on the team you are applying for if you can manage that. Once you have your resume keep a version saved for every position you apply to (so the resume you are looking at is consistent with what the interviewer has in hand), then keep updating a base copy every few months while your experience is fresh in your mind. After you have a good resume write a cover letter. You may not use it with every application but it’s useful to have ready for the ones that you really care about.

    Once all the written material is out of the way start applying. I would start with a job that you don’t care about and know that you won’t take. Getting an interview out of the way can be a big boost to your confidence or show you what you need to improve most on. Also, apply to Google. Even if you don’t want to work there, it will likely be the most difficult coding interview that you have, so preparing for that will help with every other application. Then, I would start applying to one position a night, for about two weeks. With 14 active applications your chances of getting a few calls are not bad (for me the hit rate was just over 40%). While doing all this you probably want to start working on your code interview skills.

    This last though is a gamble, but worth considering. Depending on how serious you are about finding a new position, it may be worth leaving your current job. There are a lot of factors here to consider, but preparing for interviews is almost like a full time job by itself. Often interviews gauge a completely different skillset than what you have in your current position (or stupidly enough, the position you are applying for). Taking the time to solely focus on being ready for the interview process can pay off, and even if you do get an offer joining already burnt out when you start that can also be very tough. Regardless of what you choose to do you need to have a plan. Interviewing can easily burn you out mentally, physically, and emotionally. So be prepared.

    Good luck. Dont die.