Technical Interviews have evolved a lot since I transitioned from being a Software Engineer to an Engineering Manager. Particularly in the post-Covid era, there's been a greater emphasis on the person*,* which I think is an important and welcome change.
Over a decade of interviewing hundreds of coders, I've also had the pleasure of working with various boot camps, colleges, and hundreds of individual job seekers on LinkedIn. Across all the changes over the past years, across the various locations and mediums, something remained consistent throughout The questions I get asked.
With that in mind, I thought - why not make a FAQ from my perspective as a hiring manager?
While this is my perspective, it's based on years of observation and supporting data. But that being said, advice is not fact. You may disagree with certain points, and that's OK. Opinions we disagree with allow us to better understand our own views. At best, I hope these responses help you land your dream job. At worst, I hope they'll help you form your own ideas on how to approach your career.
In this part, I’ll focus on the questions I’ve received about resumes.
On Resumes
-
How should I build my resume?
There's a lot to cover on this one topic, which I've covered in a few other resources; I'll list them below. But in the interest of brevity, here's my tl;dr:
Build the resume for a busy hiring manager. The resume isn't your life story. It's a pamphlet that lists your skills but also expresses your unique value and thinking. It should highlight your accomplishments and outcomes rather than tell a chronological biography. Build it with the knowledge that hiring managers will only spend 2-3 minutes looking at it. Try to keep it to 1-2 pages. Prioritize the information around relevancy:
- Your name
- Email & Phone
- List your tech stacks, and languages, along with your years' experience (don't rate your skills.)
- Summarize any other relevant areas of experience: Agile, Team Lead, etc.
- Professional experience (if it exists). List the technologies used, and list your impact & outcomes.
- Projects (take the same approach as Professional Experience.)
- Education (if you specialized in any specific areas like ML, Data Science, call out some of your courses)
- References (only if there's someone particularly notable - a former manager, a team lead, etc.)
Ditch the headshots, the professional summaries, the career objectives, buzzwords, and two-column resumes (those just de-prioritize information by breaking up the hierarchy.)
For more, check out my:
-
Let's Talk Resumes slideshow
-
Analysis of responses I'd given to a number of hiring managers
-
Should I have a Career Summary/Objective?
Yes and no - they can be redundant and take up a lot of room. Plus, they're often filled with fluff. That being said, I have a Summary at the top of my resume - however, I've removed the jargon/buzz-word fluff. Instead, I use my Summary as an actual summary. I do all the heavy lifting: I do the math and state the length of my career, and then I break it down into the key areas that have defined my career.
As an example, pulled straight from my resume:
10+ years in leadership, with 5 years managing multiple 20-person teams with an additional 9 offshore, augmented with additional consultants. Owned 7 enterprise products including multiple $10M+/year SaaS solutions delivered to >100 clients.
Of course, if you're starting off, it could look a little more like:
Built 5 projects, including 3 full-stack projects and 4 cloud-based applications. 2+ years experience leading and training a team of 5.
That last statement may be about your time at the local pizza place - but the challenges of leadership and managing are universal. It's still relevant experience.
Lastly, when it comes to your objectives/goals, that's something you should think through in anticipation of being asked in an interview.
-
What should I list in my professional experience?
Beyond just the company name, your title, and the dates you were there, it's helpful to cover any tech stacks and methodologies you used in the role. That way, in an interview, the interviewer can ask you relevant questions about your projects.
After that, it's about outcomes & impact. That's what you want to communicate. It's not worth stating the obvious aspects of your role. Most people will assume you did the basics. If you were there to code, you likely coded and you likely fixed bugs. Dig deeper than that and, importantly, keep it relevant to the role you're pursuing. If you're shifting into more of an Architect role, focus on your architectural contributions - no matter how minimal.
Some will suggest including a brief statement about what the company/business unit did, so you can set the context. That's good advice if you have the space. Alternatively, you can work it into your outcome statements.
Point form over full statements. It may sound pointed, and less personal - but remember to think of your resume as a pamphlet, not a biography.
Lastly: Quantify things. Numbers help keep your impact statements factual instead of subjective. They are measurable, they are meaningful. Go with the numbers that are objectively the best (dollars, timeframes, users, etc.) but if those are hard to determine, go with benchmarks: lead time, cycle time, performance time, speed/memory usage/disk usage, etc.|
For example:
Encom International Jr. Web Developer Jan 2020-Oct 2021
Technologies & Methodologies: React, MySQL, Kanban
- Delivered 8 major features on enterprise level Master Control product for large enterprise corporation.
- Worked with a 5-person team for products with over 1,000 companies.
- Owned 1 experimental feature, delivered prototype, and presented to Product Manager.
- Averaged 20 major bugs per month, with an average lead time of 10 days and cycle time of 8 days.
-
I don't have relevant professional experience, should I list non-relevant experience?
It can be trickier when you don't have any relevant experience - and you'll face this when you're starting out. In these cases, reprioritize your information: List your projects first, and follow it with your non-relevant professional experience. However, as you do this, make the effort to generalize your experience and tie it back to what you're pursuing.
For example, maybe you spent 3 years as a team lead at a pizza place. Just because it's not "relevant experience" doesn't mean it's irrelevant. You've dealt with customers, aggressive timelines, resourcing, training, and more. Focus on those aspects, but don't sell it too hard either. It's important to strike the right balance.
-
Should I list projects?
Yes! Projects are always great to see - especially in the case where you're light on relevant professional experience. Projects are a valuable form of experience, especially if you can speak to them as if they were professional projects: How did you manage timelines, what were the challenges, and what impact did it have?
If you have too many projects to list and you're struggling to think of what projects to go with, I'd prioritize as follows:
-
Large open-source projects to which you are an active contributor
-
Personal projects that could stand alone as products
-
Smaller projects that let you experiment and stretch your skills
-
Small-to-medium projects (open-source or otherwise) for which you are a contributor
-
Course/School projects
Course-work should be the very last thing you should consider. Assignments are designed for you - and while they challenge you around specific areas, they also don't represent work you've done of your own volition. Hiring managers like getting acquainted with job candidates through the projects they pursue. If you've not pursued projects beyond what was assigned, it doesn't look very promising.
In other words: If all you have is course work, it may be worth considering building some projects over listing course work in your resume.
-
-
What should I include when listing projects?
Take the same approach as with professional experience: list the tech stack, and methodologies, followed by a bulleted point-form list of impact and outcome statements focused on quantifiable and measurable impacts.
Provide a link if it's live, to the AppStore, or to the GitHub.
Lastly, hit on any role you took on beyond just writing the code. Did you project manage? Did you serve as Product Manager? Did you market it? Produce videos? Share it!
-
What if I don't have any projects?
Projects are proportional to experience. If you have plenty of experience then only list projects that were particularly notable, and only if they demonstrate a skillset you can't easily highlight in your professional experience.
However, if you have no experience, then projects really matter. Without experience and projects, you're relying on the hiring manager to make a huge leap of faith. When it comes to a decision between you and someone else who has a few projects, the hiring manager will likely go with someone who is showcasing their projects.
Build a small project first - there are lots of resources & ideas out there. Alternatively, partner up with an established project and contribute. Once you've made enough progress, list it on your resume and start your job search (knowing you probably won't get a ton of attention.)
As you complete more projects; and make greater contributions, add those to your resume.
Eventually, you'll hit an inflection point where you have enough projects listed to gain the confidence of a hiring manager. I wouldn't give up on the projects though - keep at it until you've landed your 3rd role, or you're at the 3-4 year mark of your career.
-
What should I list under my education?
Depending on where you are and what you've done, you can go with very little to a similar approach to your Professional Experience. If you have a few years of relevant professional experience it's already begun to outweigh your education - whether it's a Bootcamp, or Comp Sci degree from MIT. Experience trumps all - but in the absence of experience, education is valuable.
If you don't have much professional experience, list your degree/certification along with your major/focus. Next, list notable projects/assignments and again focus on the impact: what challenges did you encounter? what contributions did you make? Did you take an agile approach to those projects? Were you the scrum master? That's worth listing.
Don't bother with the GPA, credits, hours, or course codes - but list other majors or minors.
-
What if my degree/certification has nothing to do with coding?
The honest answer is a CS degree is the preferred option - but it's not the end of the world if you don't have one. My own degree was a double major in Physics & Philosophy, with a Math minor. I faced challenges I probably wouldn't have had I had a CS degree. Over the years, a CS degree has been less of a hard-requirement - and Bootcamps have proven the value of their certifications. But there's still no denying depth of understanding someone with a CS degree will have.
But if you don't have a CS degree, it's still worth listing what you pursued. There's still a lot of value in any kind of degree or certification and that hard work is worth touting. The key is, as always, to highlight the right things: Outcomes and impact.
Regardless of your path, you know what it means to handle multiple priorities. You've likely managed multiple deliverables and had to deliver them on time. You've probably dealt with ambiguous requirements. Maybe you worked in team settings and had to work around those challenges. Maybe you even worked a job or two while pursuing your degree.
Lastly, if you don't have a CS degree - and still don't have professional experience - your Projects are all the more important to list.
-
Should I list my GPA?
No. Even if it's a 4.0, I wouldn't suggest it.
The online application may ask for it. Your interviewer may ask what you had. Those are the appropriate times to share.
As much as I stress providing outcomes and impact, your GPA is a strange one. Having witnessed certain schools that will hand out 4.0s and straight As, I've put less stock in it. Even in the best cases, it has the tinge of being somewhat braggartly.
You should be proud of your academic achievements - and the GPA is an academic score. The GPA doesn't measure professional impact. Instead of focusing on the 4.0, focus on those outcomes and impacts that got you the 4.0 - quantify those statements.
For example, instead of:
BSc in Computer Sciences from the University of Smartness - 4.0
Try something like:
BSc in Computer Sciences from the University of Smartness
Senior Project optimized computer vision library to accurately identify models beyond 90% baseline. Results were published in the department's academic journal.
That's a contrived example, I'll admit. And what if you weren't some genius that completely redefined the world of Computer Science? Here's another example:
BA in Fine Arts from the College of Creatives
Created 5 new and unique sculptures for Senior Project that were put on display at a local gallery, including one 20+ person project I lead. The project was constrained by budget, I marketed the project and recruited participants in 3 weeks to complete the project under budget and on time.
I can't stress it enough:outcomes, and impacts.
-
Should I list my references, or state "References available upon request?"
I wouldn't bother*(and I don't bother on my own.)*If references are needed, they'll be requested of you. Save the space.
The exception is if you have a meaningful reference. Not a professor, not a friend, or even a former colleague. Only people who were hierarchically above you: a former team lead, a former manager, a former director.
Not only are those people valuable references, but it also shows you're not the bridge-burning type. -
Why do I need to quantify things on my resume? What does that mean? How can I "quantify things" if I don't know the numbers?
If you're reading this in order, you'll have read that I earlier wrote:Quantify things.
Numbers help keep your impact statements factual instead of subjective. They are measurable, they are meaningful. Go with the numbers that are objectively the best (dollars, timeframes, users, etc.) but if those are hard to determine, go with benchmarks: lead time, cycle time, performance time, speed/memory usage/disk usage, etc.
Sometimes numbers are a part of the work we do: We're optimizing an area of the code base, and we want to know how well we've done - so we benchmark; Those are impactful numbers.
But what if we don't know the numbers? - what if we can't easily say how much revenue was earned because of our bug fix? What if we only have anecdotal evidence?
In the professional world, you'll run into these types of problems every day. For example, what if you're trying to make a case about building a feature for a subset of users for whom you have no real data? You'd need to make inferences. These types of problems are known asFermi Problemsand it's a skill worth developing. Get better at measuring the unmeasurable.
Make inferences: Maybe your company won't share revenue with you, and maybe you can't share confidential information - but you can find public information: Google Play will tell you that the $1.99 app you've worked on has had 500,000 downloads. Your feature may only be used by 10% of those users - so you've had a $100k impact.
If you can't make inferences, look to measure your impact in other ways. Maybe the bug fix you released last week has resulted in an average of 30 fewer Service Desk tickets last week.
Or, extrapolate meaningful numbers from less meaningful numbers: Maybe you cut build times by 10 seconds. And your team of 20 builds 100 times each week. Maybe you can guess everyone's salary to be an average of $100,000/year. Knowing all that, you can now roughly quantify your impact.
The point is that the numbers are out there. Providing them not only shows the impact of your work but, importantly, that you'rethinking about the impact of your work.
Coders love accuracy, and while you should try to be as accurate as possible, that's not the goal. You're giving a scale, a sense of magnitude, a measure. Even if the number is seemingly low, it's still valuable because you're turning a subjective statement ("I made things faster") into an objective one ("I increased speeds by 2%").
Numbers matter.
-
How many pages should my resume have?
My personal opinion? 1 page. The general consensus I've had after surveying many other hiring managers? 1-2. The reality? 3 is probably fine too.
My resume has ranged from 1-3 pages, and while I think 1 page will stand out the most and really help you distill your message, it's totally fine if you have more than 1 page.
Whether you have 1 page, 2, or 3, the key isfocus.When you're limited to 1 page EVERY. WORD. MATTERS. You'll be forced to summarize and cut out extra words. What you end up having is a surprisingly concise but very focused message.
-
Can I have more than one resume?
OK - so this is not a question I've ever been asked. I've added it as a rhetorical question because no one says you must just have one. It's a good reminder - to have multiple resumes tailored to different pursuits and companies. You can have as many as it takes - just make sure you track and organize them well, so you always apply with the most suitable resume. -
What links should I include on my resume, and should I have the URL or actual linked text?
You should have your LinkedIn URL, GitHub, and your Portfolio (assuming you have one, and you should... see below for more on portfolios...).
I didn't really see the importance of including LinkedIn on resumes and never included it on mine. After surveying a bunch of hiring managers, I realized it was an oversight and I should include it going forward. It's a digital footprint and people like to see it.
But instead of listing it as a hyperlink, provide the URL. People still print resumes. People still pass them around. People will sometimes load them into their own software and the link doesn't get parsed correctly. You don't need the full URL*(skip the "https://www")*and do your best to make the links as human-friendly as possible. -
Should I go with a modern design or a traditional one? One or 2 columns? Colors or B&W?
While the general consensus is no one is going to fault you for your resume design, there's a preference for B&W traditional designs with 1 column.
1 column is linear and, as I mentioned earlier, it prioritizes information in a hierarchical way. 2 columns ask the hiring manager to jump around - from the left column to the right. It's harder to track and retain.
Colors aren't terrible, but make sure it can be printed in B&W and still be legible.
My personal opinion: Go with an elegant and traditional black and white layout, but then showcase your personality with your LinkedIn, GitHub, and Portfolio. -
Do I need to build an ATS-compliant resume?
This one is a tricky one. Some places will have you believe that you100%, absolutely, no doubt about it,need to have an ATS-compliant resume.
I think it really comes down to a few things:- Where are you applying?
- How are you applying?
- What stage of your career are you in?
If you're entry-level and having to blindly apply to hundreds of places, then having an ATS-compliant resume will probably help your odds of getting seen. But if you're being tactical about where and how you apply, you probably don't need to worry about it.
It's true that a single entry-level coding job will get more than 200+ applicants - and that's at small companies. Bigger companies can be in the thousands. Sadly, the odds are not in your favor, and being ATS compliant will only increase those odds by so much.
If you have the time, then it's worth making it compliant - but it's also not something to stress out about. In fact, I think there are better approaches to increasing your odds of getting seen.
It's worth noting, that all these responses are my own subjective views that I've generalized across small and large companies. They reflect my personal style, but I'll also happily submit they're not 100% right either. It's what's worked for me - but I love getting input and thoughts from others.
Hit me up in the comments or get in touch. Good luck!
Also published here.
