That's super important in my opinion. I try and write as little as possible on my resume because I don't want to get asked about stuff I don't remember. I keep it to 1 page, write as little as possible and hope that people recognize the default LaTeX font and interview me because my super concise CV makes me look interesting/mysterious.
It's worked well enough for me, but it's a small sample size and luck plays a huge role of course.
If something was a long time ago, just summarize it and keep it short and sweet. Nobody needs to read 8 bullet points on an internship you had 7 gigs ago which has no relevance to the job you're applying for. Contractors are particularly bad offenders here in my experience. No hiring manager will read through a 13 page resume for somebody with 6 years experience. As the TFA mentions, use that valuable space to highlight more recent, relevant experience and put your best foot forward. Everything else is just noise.
The first bullet point for each one of those is:
* Followed the Software Development Lifecycle
The second bullet point is:
* Attended all required meetings and ceremonies for agile scrum
At the end of each contract is two lines of technologies used in the environment (though not necessarily by the candidate). For example, kuberentes will certainly be on that list. When asked about helm or kustomize or kubectl: "Oh, the build put an image out on docker hub and then the operations team did all the work to deploy it."
If you've got a CV hosted somewhere with CMS and you still do CMS stuff and want to get hired to do CMS stuff... leave it on there. If you don't want to do CMS stuff, take it off.
If you are applying to a job that isn't doing CMS stuff, on your resume that you're sending to them don't have more than a single bullet point for that old job about CMS duties.
Personally, I don't put too much emphasis on these numbers because most of them are probably BS. Don't get me wrong, it's still probably in a candidate's best interest to quantify their accomplishments since it's recommended everywhere but don't over do it.
Same applies to resumes. They are impressive to recruiters, HR and often hiring managers themselves.
I'd actually say I'm much more interested in understanding what concretely a person actually did, so I know what kind of experience and capabilities they have, vs what it led to, which has so many external variables and is probably mostly BS anyway.
- moved from Kafka to Flume
- installed Kubernetes and Dockerized our code
- binary serialized our data
Then this is going to happen:
1. I will assume you don't care about the outcomes of what you do, only the task
2. I will assume you don't know how to communicate why something matters
3. I am going to have to pick at random and hope it's interesting
On the other hand, if each one has the outcomes listed, not only is it clear that you know why, but perhaps more importantly, it is a conversation hook that I can use to enter the discussion. Well, why was it important that the size of the data be small? Couldn't you just zstd your JSON instead of binary serializing some processed version? etc. etc. and then you get to show off why and what that thing you made does and I get to enjoy that and we're both happy.
And to be fair to you, almost all management two steps removed from actual coding does not understand how actual software development works. If you are interviewing a PM you should care about the outcome, for engineers focus on quality, timeliness and skill.
That isn't rewarded in all jobs, mind you, but it is something to look for when you have a choice.
So my point is, if leadership and product are bad and ask engineers to produce turds. The engineers don't really have control over the fact that they are producing turds but they have control over the quality, how buggy, and the shinyness of the turds.
> I've been a software engineer at a few highly regarded companies for a decade now, at none of them did I have the ability to make large product or design decisions as a software engineer.
IME, even the highest engineer at the company has little to no ability to make even small product design decisions.
I'm not saying whether I think it's a good thing or a bad thing, but the truth is there's a role at every organisation who's job it is to decide what the product should look like and what it should do. That role decides all the "what" questions.
Engineering is all about "How?"
Even the product design role doesn't have all the power - the "Why?" is decided by someone else.
So put that in the resume. Say how you delivered it better, faster or cheaper than the next candidate in the pile would have.
Does your company put you head to head with another developer to see who can develop the same feature the fastest?
Or maybe you secretly keep tabs on all of your teammates and their delivery speed, so that you can calculate how much faster than your teammates you are at delivering and how many fewer bugs you ship?
Even for product work I've yet to meet the product person who isn't eager to talk about how a new feature was received when a dev asks.
How about we start with you not making 2 massive assumptions off of a sentence in a document that summarizes anywhere from 1-30+ years of someone's work.
Then how about we move away from you thinking that interviews are for your entertainment and the interviewee is a circus animal where 'you get to enjoy that' as they 'show off'.
I don't think people are "circus animals". But I do like to work with people who have done things that they are proud of and who do like talking about those things. And it is important to me that we both enjoy the conversation, yes.
To be honest, why do you even care what the business need was? Maybe it is classified? Maybe it just landed on their desk and they crushed it? You honestly want to read about the business needs of things that are completely irrelevant to you and in the past? Go download a white paper.
Your whole paragraph is a juxtaposition. You are saying that hiring managers are strapped for time to thoroughly review all the resumes(I agree) but then say that a resume should have the business needs and outcomes of any number of projects that a dev has worked on in their career(and we haven't even touched on what they actually DID for those projects).
"Deployed our core application to Kubernetes": Cool you once saw a Dockerfile and Kubernetes YAML.Like every single other applicant. I don't even know from this if you have a basic understanding of Kubernetes. "Deployed our application to Kubernetes for better server utilization and resiliency increasing our uptime by 20% while reducing cutting our server costs by 10%". This person at minimum has some idea of how to configure Kubernetes for application resiliency, knows how to measure and maximize hardware utilization, knows how to measure and minimize downtime, and probably knows enough about Kubernetes to provide advice about when to use it and when not to. Maybe the first person does too, but they did nothing to show it.
> It is not to make wild assumptions about how someone is probably incompetent because they put put 'GIT' or 'JAVA'
No one said wildly incompetent.
> every project they have worked on(good luck getting all that on one page)
Don't put every project on your resume. Pick the most interesting ones for the job your applying for. If you are sufficiently senior that this still doesn't fit one one page, use two.
> It is almost a certainty that someone making snap judgements on what capitalization was used for a specific tech is also making those judgements on things like nationality, origin, sex, etc...
No.
> To be honest, why do you even care what the business need was?
Most hiring managers. Someone who understands WHY they are doing something will make better choices than someone who sees "Move our application to Kubernetes" in the backlog, grabs a yaml template off the internet and calls it day.
> Maybe it is classified?
Government resumes tend to be EVEN MORE outcome focused than private industry. You can write "increased pipeline throughput by 50%" without writing the national secrets in that pipeline.
> Maybe it just landed on their desk and they crushed it?
How can they possibly know they crushed it without understanding why they were doing it in the first place, or anything about what happened after they released it?
> You honestly want to read about the business needs of things that are completely irrelevant to you and in the past? Go download a white paper.
A white paper tells me nothing about the candidate.
> Your whole paragraph is a juxtaposition. You are saying that hiring managers are strapped for time to thoroughly review all the resumes(I agree) but then say that a resume should have the business needs and outcomes of any number of projects that a dev has worked on in their career(and we haven't even touched on what they actually DID for those projects).
You know what takes longer than reading a resume? Interviewing someone. Your right. Resumes are going to get a skim first. Only the most relevant ones are going to actually get read thoroughly. This is exactly why you want numbers and metrics as much as possible. Numbers catch the eye far more easily than sentences. If I see "saved $100,000" on a page, that's going to get caught on my first skim. It's an effective hook. I want to know more. Without it I've just got "Kubernetes, C#, Javascript", I might as well have a computer read the resume and build me a checklist.
Two different hiring managers in this thread have already said this, but in case that's not enough here's another https://www.askamanager.org/2020/02/my-step-by-step-guide-to.... You might even want to spend some time with her whole section on resumes, she answers many of your other questions too https://www.askamanager.org/category/resumes.
For classification I meant that generally a company you have worked at will not be keen on you going around talking about their internal business needs, especially if it is close to the product.
Lastly, as some have mentioned, statements like 'increased this by X' are usually either fudged, or marginally related to what the candidate worked on, conflating factors being in the mix.
"Redesigned the web pages and user satisfaction went up 10%" - but also you hired 5 more customer support agents and a backend engineer improved the slow pages by 30%.
And if the software you write works with money at all, put the amounts in there. Moving around large amounts of money shows trust from your existing company, and attention to detail.
> As engineers we're measuring everything, all the time right?
This is after years of delivering LOB software to clients in banking, manufacturing, and oil & gas industries.
Ha ha ha ha!
Asking questions like "What data do you have to support this?" can often create a lot of enemies - including your manager.
The process is: You're in charge of a thing, it grows, it breaks, you fix it, it grows, it breaks, you refactor it, it grows, it breaks, you fix it, it grows you replace it and shard it into N things, they grow, they break, etc. The metrics matter, but after a while it's just bigger and bigger but gotta work, so you just make it work.
Oh -- obviously I'm not an engineer -- I don't wear a striped hat and drive a train or sign blue prints.
Go a step further.
Only put items in your “skills” cloud that WANT to be asked about and can deep dive. These skills should be things you hope the interviewer will ask you about.
If you can spend the whole interview talking about points in your skills cloud then it should be a slam dunk.
Then follow up with the age-old advice:
Your resume should talk about results. Don't say "Created a new CMS for the company". Say "Created a new CMS for the company in Python that resulted in an ~70% reduction in website update times, from 1 hour to 18 minutes."
My take: I’m actually not convinced anyone cares too much about those numbers in a resume. Great topics to probe in an interview, but not much of a signal on a resume. Reason being: they’re easy to fluff and are almost always inflated bs.
I do agree with all of your other points
Not only that, but how would engineers, for example, know how much money was saved or earned from blah feature or project unless that was explicitly shared with them? Time saved or usage can usually be measured by the engineer, but money is a lot trickier.
Like I'm able to say a speech application I made was used in over a million calls, because I looked at the database and saw that many call records in there. And I'm able to say that I set up an one-click 30 minute devops process for deployment that was previously done over the span of 4-8 hours manually with multiple engineers onhand in case things went wrong (and they often did due to user error), because I was physically present during those manual processes and could directly compare and contrast the time difference.
But I can't say it "saved the company X million dollars" or whatever because I wasn't in management and didn't have those figures shared with me.
At least not honestly. I could make some bullshit up (I don't, but I could), like you said, and how are you going to verify it? Do you think a past employer will confirm or deny those figures if you call? You'd be lucky to get much more than confirmation that I worked for them and what dates at this point, thanks to all the liability around it. Also there's no guarantee that they know (or remember offhand) themselves, maybe they weren't on that project.
So multiple engineers on hand for 8 hours - let's say 5 engineers. That's 5 person days. A deployment a month (cos anything that painful gets done less often) gives 60 person days, at something like 2x daily salary of engineer (assume 500pd for easy maths) and you saved company 60,000 usd a year whilst increasing reliablity and speed.
Nice one
> Like I'm able to say a speech application I made was used in over a million calls, because I looked at the database and saw that many call records in there. And I'm able to say that I set up an one-click 30 minute devops process for deployment that was previously done over the span of 4-8 hours manually with multiple engineers onhand in case things went wrong (and they often did due to user error), because I was physically present during those manual processes and could directly compare and contrast the time difference.
These are both perfect for a resume. They are quantified and measurable and would be interesting to talk about in an interview. For example, I'd probably ask you what tools you used to set up your 30 minute deployment process and what they were using before and how you managed such a huge gain. I would ask you how you built your voice application to scale to a million calls.
These are both great for a resume. They don't all have to involve money.
Like I worked on several games that didn't do well in the market (for various non-technical reasons), so I know I can't brag about saving money or time or usage for the company, but I learned a lot of skills by being on those projects, so I benefitted personally in ways that could help the prospective company out.
In fact I might have gotten more skills from those projects than that speech application, for example, despite that one being used a ton.
So I don't really have anything better I can say there than "did this this and this on the project, lead X number of people, etc", which are basically the 'responsible for...' bullets that everyone advises against including on a resume.
Also in case you're curious, I set up the process by using Octopus Deploy and several custom Powershell scripts after an audit of their existing processes and all the various information for all the servers, firewall settings, windows services, database snapshots and schema migrations, etc (there was a lot, each major system had like 40+ steps to it by the time they were done) etc.
Before the engineering director of the department would lock himself in his office and execute .BAT scripts one by one from a terminal and copy files and other things manually, while everyone else chilled in the main office, waiting (usually around 4-5 people). If anything ever went wrong, and usually it did, it would take several engineers to investigate and help revert things if necessary.
It was a mess. They knew it was a bad process, and had previously had another developer start investigating how to make things better using Octopus Deploy, and he gave up and quit the company and KT'd to me that it was impossible, no one was cooperating with him, he couldn't get the information needed, and well... I didn't have his experience and think he just didn't want to do it.
I had everything working for several processes (and we set up more and more over time after we had things working) in about the same time as he spent accomplishing very little (I started with his setup), and I didn't know anything about Octopus Deploy and barely anything about DevOps beforehand.
Mistakes can be golden.
Should I put this on resume and would it be in poor taste to quantify the results?
He just said:
>> that ended up being used to commit a (arguably) crime against humanity.
What about that makes you think that he knew what it would be used for?
"I'm the civil engineer who designed a large and complicated factory for the mass baking of ceramic products."
...
"I did not know the next government would start a world war and use them to gas Jews."
You seem to assume that everyone has perfect foresight. I assure you, even you don't have perfect foresight.
But if someone told me that they were a senior SRE at MindGeek, I’m inclined to hire them.
And also, as you said, the resume drives the interview, so they are good jumping off points and that's why they are there.
I was instantly put off - because while it might be true there’s just way too many variables to claim a 68% improvement was down to your design system.
But when I’ve been on the opposite side of the table, I’ve always read every word of the resumes of the candidates. I think the hiring process would go better if more people did this.
"resume for a 20-something who travels abroad and knows the rust"
It has many biases and false negatives. But the point is that you should know this going in and adapt accordingly.
I find this very difficult because I think all great results are due to team work, and a bit of luck. Like the software we specialized on happened to become a very fast growing market. And we captured a big chunk of that marked with only a team of 5 people, but we could probably not have done it without each other. All our work was very intertwined.
Correct, but North American hiring culture expects you to sell yourself, in the STAR format. Situation (Your job) -> Task (Your project) -> Action (Your role) -> Result (Numbers go up). So, if you want a job, you have to play the game.
You obviously didn't move mountains all by yourself - you were an employee, not a solo self-contained business unit. If the hiring manager wants more details about what exactly your role was in moving the mountain, they can ask in the interview. Be honest, but don't sell yourself short.
Most of the time it feels like a performance from both sides. We only want to hire the best! We need all 30 of these skills! Oh yes sir I am the best I absolutely know all those things!
Currently hiring Java devs.
what I mean is, a good Java dev will be able to code in Go in under a month.
A developer who knows MySQL will learn postgresql just fine.
I don’t tend to put much weight into specific technologies, more I try to figure out how exposed you've been to paradigms that are important (OOP, RDBMS).
And if you’re not looking at LinkedIn in 2023 you’re probably missing out. My LinkedIn has far more detail than my resume because it’s not page limited and a lot easier for the reader to search and zero in on what they want.
The difference between a good hire and a bad hire is really big, right? So why would you be like, there's no way I am reading 100 resumes?
Suppose it takes you or someone like you (i.e. maybe you can get in a room and do all the resumes with a few people on the team in an hour or two) on average 10 minutes to reasonably critically evaluate a resume, maybe follow and read any interesting links on it. Then the pile of 100 resumes takes about 15 hours to evaluate. Suppose that the person you hire has an expected tenure of 2 years. That means they will be working for about 4000 hours. 15 hours represents 0.5% of their productivity. So can it really be that critically evaluating the resumes doesn't even give you a hire that is 0.5% better in expectation? I would have thought it was like, 50% better, if the resumes are your primary screening tool to decide who to bring in for an interview!
I have been working for like 15 years, and all my coworkers are always just like you -- they don't read the whole resume, they don't go read the candidate's code, they don't read the candidate's blog, etc. But it seems self-evident to me that spending a few hours to try to hire better coworkers has a huge ROI for the team. The time I spend basically always finds stuff out about the candidates that my coworkers find interesting and important, and often prompts further interesting information in the interview.
I always just figure that the explanation is: my coworkers don't enjoy doing hiring stuff, and nobody is making them do it, therefore they don't. Do you think differently?
The "stand out significantly" check doesn't take 10 minutes per resume.
Additionally, doing nothing but reading 100 resumes (no meetings, no development work, no trouble shooting issues, nothing else) is soul crushing.
Going to blogs some HR departments will frown upon as it may introduce biases into the evaluation process that they'll get sued over. "The candidate recently wrote about her experience with pregnancy on her blog that the interviewer had looked at" - and you've got a discrimination suit on your hands.
So it sounds like you're saying that you can do a really fast check with ~no false negatives. That is, you won't skip over the best candidates and fail to interview them.
But are you sure that's really true? Often if you can find any code a candidate wrote, it quickly stands out as "exceptionally bad" (like, you can see bugs at a glance, the formatting is a mess, stuff is copied and pasted everywhere, the project isn't what was advertised) or "exceptionally good" (like, they are making PRs fixing tricky issues with really thoughtful writing and immaculate appearing code.)
There's almost literally nothing on a resume that can stand out that much other than, like, "ICPC winner" or "lead engineer on Chrome" or "famous celebrity I know by name". At first glance, the resume of the guy with the exceptional code will just look like "went to some school, worked at a few companies where they did a few bullet points." How are you so sure you will decide to interview him if you just skim the resumes very fast? What if you have four candidates who went to better schools and companies, and you interview them instead?
I get the "soul crushing" complaint. If I were king I would try to split the labor among engineers as much as possible to mitigate that. Or hire more slowly.
I'm not going to claim that the ones selected are the best or that I'm missing ones that I would give a thumbs up to if I had the time to interview every candidate.
Instead I'm looking for "are they applying to this job? Do they have some of the skills that the job is looking for and have claimed to use those particular skills in a past job or project? Do they have a history that demonstrates that they're likely to stay around after becoming a positive contributor?"
I've got an excel spreadsheet where I am to give a 1 to 5 score for each of the skills (1 is "no claim of the skill being used" to 5 of "specifically claimed to use the skill in a current project or role"). The next column is "average tenure in months" and lastly there is a column for red flags or green flags. You will note that nothing in there asks about past company or school. Considering schools can get into trouble for discrimination if the person went overseas or to a HBCU. If you want to call out something (the candidate spelled JavaScript as 'java script', "JavaScript" and "java Script" (with java lower case and bold)) then that can be put in the red flags.
From that list (and multiple people all fill that out for all resumes), HR then selects the ones to move to the next round of interviews.
If I am looking for code the candidate wrote that can cause problems with discrimination suits at this level of the interview. If we look for any blog posts on them or social media they've written, we open ourselves up to lawsuits and claims of biased hiring.
When it comes to code, we have a take home test that is given to those who are selected. Having the take home up front has been met with "but you aren't paying me to do this" or other forms of refusal to do it... and I'm not going to go through and review 100 submissions - I don't have the time for that.
For that code part of the interview, again, there is a rubric that is set down such that anyone reviewing the code should come to the same conclusion.
And while it seems a bit impersonal, the key is that the same criteria is applied to everyone and if someone else was to watch a recording of the interview (this isn't done, but its the hypothetical goal) that they would come to the same conclusions based on that same rubric for evaluating the candidate.
A false negative costs me very little. A false positive is a massive burden. I'm optimizing to avoid false positives.
Also to be clear, I will read the full resume of a candidate I'm interviewing. And their blog and GitHub and whatever else they tell me about. And I'll take notes so I can ask them about interesting things I find.
The skimming is just for the initial "should we consider this person for an interview" screen.
Ah, the sheer ego size of hiring managers who go around saying stuff like "understanding how candidates think" or "assessing cultural fit"
The brightest minds of psychology - with far, far more resources and time - can't replicate those results if they run the tests this Monday or this Wednesday... and then comes the hiring manager and they say they can do it with a CV, some technical assignment, and an hour of chat. After having spent less time properly studying the topic than highschoolers spend on their homework each week
My CV and LinkedIn profile had links to open source projects for more than 10 years. I am someone who interviews a lot -- I like to move from company to company for diverse experience. Only once in ten years has anyone asked about my open source work. They are generalist libraries (Java and Python) that I "import" at every new job. They give me a real edge over my teammates. My point: Interviewing seems like a total gamble. My best strategy is to figure out what the hiring manager wants and pretend to be that person. In most teams, the hiring manager calls the shots nearly 100%. If they like you, you will be hired. I've had crap tech interviews with the "teammates" and still gotten offers because I transformed (during the interview!) into exactly what the hiring manager wanted. Bizarre.
I sometimes notice people using LinkedIn for something else, but I don't get it. It's mostly a resume-hosting site for me.
You do exactly the thing the author discusses, and without addressing any of the author's (very valid, IMO) criticism of the problems with trying to do this.
That cannot be true, getting through screening is a zero sum game.
Yea. That is called a zero sum situation.
A much more real and honest description would simply be "Upgraded 20 year old wordpress and ensured no data loss or breaking changes took place, which helped improve the editorial experience for our writers"
I was doing the same when I was an inexperienced interviewer, but then I realized this meant I was passing up on highly competent software engineers because they were not highly competent resume writers.
Seems like you're looking for great resume writers. I would reconsider if I were you.
I want someone who will just admit when they don't know something. It's a sign of great intelligence.
I also have 5 years of software engineering in a FAANG working mostly on Java.
But I guess you wouldn't hire me then.
It's fair to ask what level of proficiency the person has and skip the questions you were planning to ask if they answer like me, but it would be stupid to actively try to trap people.
That's the kind of person I'm trying to avoid. Someone who isn't honest about their skills.
It’s all kinda pointless. People do leetcode, system design, and then a (series of) manager interview(s). They don’t often ask me much about stuff directly from my resume - especially for technologies or skill cloud related shit.
meh. I think that's bad advice in 2023 (even in 2018), as a moderate volume resume reviewer with lots of hiring experience -- resulting in 25% fewer remorseful hires.
Well, not quantifiable results as you describe anyway. If you are a VP level with a budget, then ok. Or a very low level IT person with metrics to meet, then ok. But as an average SWE, no one is believing these numbers. Even when true, it feels like a force fit to fit a misguided expectation. Unless you specifically went into the project to improve efficiency, and YOU were the one that identified the problem and INITIATED the project SPECIFICALLY to grind out more widgets, then I'd find some other aspect to crow about.
In the CMS case, then sure if you identified the CMS as a real issue, worth fixing, and led the project, and can describe the size of the team (could be just yourself) to tackle it, and are taking responsibility including if it failed, then ok. If you're just assigned the task and it happens to be more efficient, blah. Maybe the starting point was exceptionally bad, n^2 vs log(n) due to the first version being a hack. This 70% "result" tells me nothing useful, honestly, except that you are a slave to bad, one-size-fits-all, resume guidance.
So many good questions to spawn from that one line.
No one reads resumes. At best they skim them. They look at the shortest lines, which are usually where you worked and the job title. Name recognition makes a difference here, no matter how many people tell you otherwise. This applies to your college as well. But don't let it discourage you, it's more of a "if you have a big name there you get a boost but it's not a negative if you don't".
They skim for key technologies and then read the text around them.
They most likely will read the full text of the most recent job, so make sure that is the most detailed and interesting.
Your resume should talk about results. Don't say "Created a new CMS for the company". Say "Created a new CMS for the company in Python that resulted in an ~70% reduction in website update times, from 1 hour to 18 minutes."
If you do put a "skills cloud" on it, be ready to talk about them all. If someone had a skills cloud I would immediately look for the most esoteric skills and dive deep on it in the interview (after Googling it myself) to see if you were BSing or not. If you really know that skill, you should know more than what I learned in five minutes of searching.
All this applies to your LinkedIn as well, which you should keep up to date, so that if there is a job you want but don't want to spend the time applying, you can just send them your LinkedIn. :)
Edit: Forgot to mention, as pointed out below, that your resume also drives the interview, so while some of what you write won't be read to get the interview, you still want it there as a place to jump off during an interview. Always better if you can drive the conversation towards your most positive qualities, which is easier if they are in your resume and the interviewer asks about them.