I've read a lot of resumes in my time, and here is my advice:
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.
> 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.
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.
Couldn't agree more. Not even just in the skills cloud section, don't put anything on your resume that you're not ready to talk about in an interview. It's baffling the amount of candidates that answer questions about their resumes with "Oh it was so long ago I don't remember" or "Oh it was just a quick 2 week R&D spike that was never shipped".
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.
> 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.
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."
Maybe I should reduce some of my earlier entries. I've still got my entire work history on my CV. I worked on a specific CMS from 2004-2008, and I still get asked for gigs related to that CMS (even if the version I worked on is nothing like the current version). I worked on a PHP problem for 3 days once, and put it in mostly as an example that I can quickly adapt to new languages, but some people actually want to hire me for a pure PHP project.
The "this is everything that I've worked on, if this interests you, contact me" is different than a "this is the information relevant to the job that I am applying for."
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.
>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
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.
They are absolutely BS because 99% of programming is unquantifiable. There are too many variables. I added 5 features this quarter and sales went up 5%. Is it because of the features, or better sales techniques, or dumb luck?
"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%.
"Created a new CMS in python (Based on the old CMS) (With a team of 2 others and one guru who did the design but I wrote his code) resulting in 70% reduction in update times (after we ran it in a cluster with twice the resources but I never could understand clustering so guess it was my coding)" "And didn't have time to write tests, and that project was canned because it took too long actually"
As engineers we're measuring everything, all the time right? The point is 'wrote a web api' is worse than saying 'wrote a web api that handled 1M tx/hour' or some such. Even if the number in this case was exaggerated, it stands out and we have something to discuss in the interview phase.
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?
Is this mostly a joke? I've written plenty of APIs, but I have never load-tested them in isolation, never had to respond to underperforming latency or throughput metrics, or even face any feedback on software performance. In most cases, I don't know who uses the code I wrote, and no metrics from them ever make it back to me personally. For exactly 95.2% of what I've delivered, I couldn't tell you that I improved Foo by Bar units even if you held a gun to my head.
This is after years of delivering LOB software to clients in banking, manufacturing, and oil & gas industries.
I think it depends on work culture. We recently merged with an american corporate and their engineers are obsessed with measuring, pilots, ab testing, RFCs etc. It's so slow to work with them even on the smallest features. Poor 10% of users who miss out on awesome features for 4 months because we "need" a control group.
I think that the point of the parent poster is that often even when the work culture is obsessed with measuring, the people doing the A/B testing and careful study of the benefit to the company are quite separate from the people implementing the change; the information will be used in some decisions and flow to various layers of management, but the developer who built that feature won't necessarily even get a message when it eventually got chosen for widespread deployment or got abandoned after 4 months of being shown to a control group, much less getting the data on what the estimates of financial impact showed.
I'm not so sure about this. I support things and I've supported them over absurd growth periods for years. I've lost track of how many zeros are on the number of things per thing; it doesn't matter.
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.
They might be, but they are a good jumping off point for a discussion during an interview. But also if you say something interesting, it will pique my interest enough that I at least want to talk to you about it in an interview.
Was going to say this. You need your resume to cover both types of people who will be looking at it. HR/Managers for initial screening and then developers for the real interview. For a startup where I know the dev or founder are seeing my resume right away, I wouldn't include those types of quantifications. If I'm applying at ${bigcorp} then it helps get you through round 1.
The value is as a hook in a conversation. e.g. if you have:
- 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.
Most developers don't have agency to choose what they work on within a company. Expecting the developer to have any influence on the outcome of what they produce other than the implementation quality shows a lack of understanding in how actual software development works.
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.
Have you considered... Asking? Asking why you are doing something? All of these changes are going to have a purpose behind them, and at least in these examples those reasons are likely to be things a dev is in a position to metric the results of themselves. How much throughput did you add by switching to Flume? How much did you reduce bandwidth with that binary format? Even if you don't have access to the production metrics (and most places you will) you could estimate based on synthetic data.
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.
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?
As a manager, that's half true. We have business needs, but I am hiring for the ability to think past "what is being asked of me" and into "What do we really need, and how can we deliver it?"
That isn't rewarded in all jobs, mind you, but it is something to look for when you have a choice.
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. I was able to suggest things, I was able to call out issues in the design and I was able to propose ideas but I was never able to unilaterally make any decisions and a lot of the time any ideas I had were put on the backlog because the company was in focus mode on one specific goal (and I'm not criticizing this idea of having focus).
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.
There's three questions for every product - "Why?", "What?" and "How?"
> 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.
Key point: quantify the shinyness of the turds, so that HR screen likes the look of the CV, and be prepared to talk about turd shinyness and why it would matter.
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'.
This is a weirdly aggressive response to what is literally the core purpose of collecting resumes. Like it or not a hiring manager likely has hundreds of resumes they are looking at and nowhere near enough time to review them all. Making judgement calls on limited information is necessary. Maybe the hypothetical engineer with this resume does understand the goals and outcomes of these tasks, but they have failed to demonstrate it in this resume. Given another engineer who gives me details about the business need they were meeting and the outcome, why would I interview the first instead of the second?
The core purpose of collecting resumes is gauging the likelihood that a candidate may have the skillsets to align with what the job is, and then bringing them further into the process to dive deeper into their experiences. It is not to make wild assumptions about how someone is probably incompetent because they put put 'GIT' or 'JAVA' or omitted the business need and outcome on every project they have worked on(good luck getting all that on one page). 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...
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).
The core purpose of collecting resumes is to determine which candidates are most worth bringing in for an interview. A candidate who understands the business purpose of what they are doing and is capable of calibrating their task to best meet that need and gauging the outcomes of how well it did so is infinitely more valuable than one who just blindly does whatever task with no knowledge or understanding. Skillsets are more than just a list of technologies you've worked with.
"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.
I appreciate the thorough response. I guess we disagree about the purpose of a resume, I just think it is wrong to assess someone's worth off a one-pager(two pager max). There is obviously a lot of grey area between what a perfect resume and an atrocious one looks like, and that will vary even between each job application. Matching the expectations of candidates with those of the hiring managers is extremely difficult, dating can be thought of as a similar problem that has not found a great solution(and in no way am I saying dating is like interviewing).
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.
Isn't it preferable to you that I continue to be like this so overtly? Since you dislike how I am and you may well dislike working with me, you can instantly reject me and my org. This is good for both of us.
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.
I agree. I know it's the conventional wisdom to phrase things in that way. Having hired a lot of people and read a lot of resumes I personally either ignore these statements or have a chuckle over them when they are silly. In no world would someone capturing the "impact" of what they did make me more likely to hire them.
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.
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.
> Reason being: they’re easy to fluff and are almost always inflated bs.
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.
> 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.
Yeah, they are both bullet points on my resume, actually. But there are several jobs where I can't quite say this.
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.
Great anecdote that, a real classic - previous experienced engineer couldn't get the cooperation and information he knew he needed to do it properly so barely started. Newer inexperienced engineer wasn't quite sure what was needed but built something to get several processes working and used that to convince everyone to provide the support to complete it.
I've closed $100k worth of consulting by opening with "My name is Zwayhowder and I've spent years making every cloud transformation mistake possible so you don't have to".
I'm not sure why you'd be willing to work on such a project but then be concerned about putting it on a CV. Assuming something I don't understand, you could talk about the impact it had on your employer without going into details of what it allowed them to do.
Woah there Betsy, I wasn't accusing anyone of anything, I literally didn't understand the comment as well as you apparently did.
So the second part of my comment stands. In the case of such a civil engineer, I'd focus on "Designed factory and rolled out process allowing organisation to achieve strategic objective to increase rate of baking ceramic products by 25%".
You can come up with decent figures. And i think it is worth it not just for a resume but monthly lookbacks
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.
Getting the numbers in the first place is one challenge, but if you do metrics and measurement, you get hundreds of numbers and improvements, different each week. It's not like you're working on a single goal and target, and then wave goodbye when you're done. Who remembers all those numbers and improvements? What did they come down to cumulatively over the years? No one can know.
But crucially, one also works in teams. There's no way one person can claim credit on one measured improvement unless it's something very trivial and isolated, a single-person project.
There are many people saying that they read negative things between the lines about people who don't put quantifiable metrics to their CV items. I don't mind missing metrics, it's much better than having some fudged up bullshit metrics in there.
The CV is there to establish trust between two people who don't know each other. Don't fill it up with stuff which shines with fabrication and misrepresentation.
I recently saw a CV with a very specific claim about developer efficiency improvements brought about by their introduction of a design system to the product.
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.
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.
> I find this very difficult because I think all great results are due to team work, and a bit of luck.
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.
I've heard this sort of meme description style proselytized over and over, and have tried it, but I can't think of a single time I've ever genuinely been in a position in which I had literally any control over either the decision that was made to do it, or insight into the outcome if it existed, and probably wouldn't believe anyone who told me differently. These stories seem to me like just being in a unique fantasy position in some startup where you happen to be given more autonomy and individually refactor some core thing end-to-end with analysis that ties your lucky results directly to sales.
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"
Because the pool of applicants is so vast, you are far more likely to get passed over because there are so many other candidates to interview rather than being passed over because you don't hit the lowest bar acceptable for the interview.
I’ve been hiring for 15 years maybe and always read resumes. The skills bubble is critical for me personally - they need to have some stuff in there that matches what tech we use. I also don’t look at LinkedIn - doesn’t add anything to me not already on the resume.
You must not get a lot of applicants if you have time to read all the applications. But there’s no way I’m reading 100 resumes for one job. I’m skimming them at best.
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.
jedberg, I know you are a smart guy, so I wonder if you can explain this thing that has always mystified me.
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 less than 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?
I like this comment. At the end you wrote: <<my coworkers don't enjoy doing hiring stuff>> Can you clarify something for me? Are you a hiring manager? If yes, the "ROI" comment makes a lot of sense. And do "co-workers" mean other hiring managers... or non-managers? As a non-manager, putting effort into hiring doesn't have good ROI for me personally.
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.
An alternative explanation: even if they did spend more time on the resumes they wouldn't be selecting better, because they don't know what to look for
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
It isn't "critically evaluate" but rather "in this stack of 100 resumes, find four that stand out sufficiently to bring in for interviews."
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.
> It isn't "critically evaluate" but rather "in this stack of 100 resumes, find four that stand out sufficiently to bring in for interviews." The "stand out significantly" check doesn't take 10 minutes per resume.
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.
If you're selecting 10% or 5% or 1% that are interesting to bring into an interview, what is a false negative?
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.
It's a matter of ROI. The initial skim is just the sorting phase. And sure, I may miss a great candidate, but that's the price one pays. It's much better to get a false negative than a false positive.
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.
I think I’ve got over a hundred to go over for one of my positions right now. I take a half day a couple times a week to go over them. I just consider it a priority and make time for it. Training and then firing someone is such a massive waste.
if you’re hiring senior and above the number of radically different technologies is extremely small.
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).
> 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."
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.
> If you do put a "skills cloud" on it, be ready to talk about them all.
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.
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.
It tells you that the candidate at least understood the business impact of what they were doing, and it gives you something to talk about in the interview. "How was that issue identified? Did you find it or were you assigned the task?" "How did you achieve those results? What technical decisions did you make to get there?". "Were you the team lead or did you work under another team lead?".
So many good questions to spawn from that one line.
Those lines of questioning are open always, regardless of what’s written in the resume. You have precious few inches in the resume, they should be reserved to highlight your own accomplishments, the aspects of any project that you actually drove. When I see these kind of metrics on every other bullet (for L5 and below) it tells me a lot about the candidate and not that they have an appreciation for the business impact of their technical skills.
For the skills, I feel for every interviewer that grills you about them there are five that would have never bothered to interview you if you hadn't listed them. If the job posting has Kubernetes, data science, Angular, React, Ember, Java, linux, apache, python, postgres... for a junior dev role, I am damn sure going to list them even if I only have a general idea about them. I highly doubt they are going to start grilling me on the inner workings of postgres, they just want to know I have worked with an sql database.
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!
> 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.
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.
No I'm looking for bullshitters. People who are willing to lie on their resume and won't admit when they get caught. If they say "I just put that there to get past the filters" then great, we can move on. If they try to BS their way through an answer, then what else will they try to BS through?
I want someone who will just admit when they don't know something. It's a sign of great intelligence.
I have C# from a school module from 7 years ago on my resume. I wouldn't be able to answer many interview questions about it but I would be read to work in C# after a few hours of brushing up my skills.
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.
I'm not trying to trap anyone. I would ask you about C#, you'd say "that was seven years ago, I don't remember the details" and we'd move on. I'm looking for someone who starts making up things about C# assuming that's what I want to hear.
That's the kind of person I'm trying to avoid. Someone who isn't honest about their skills.
On top of results(or even rather than), it can be more useful to talk about scale. Often times the end result is not really in your control. One could say 'deployed a pilot project to a group of 10,000 users to see the effect of X on Y' or 'worked on a project that had a throughput of 50k transactions per hour', etc...
I can’t recall the last time anyone asked me about shit on my resume - tbh.
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.
My thought here is to pay reviewers to read resumes and use eye tracking to train a diffusion model so you can issue resume prompts that will produce the most eye-catching resumes.
"resume for a 20-something who travels abroad and knows the rust"
I know that most people don’t read resumes because I’m always asked a lot of questions that would have been answered if the interviewer had read my resume.
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.
I read the entire resume before an interview. I skim them when I'm deciding if I should offer one or not. Also I will ask about things that are in your resume because I want more details.
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.