10 ms·

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 usuall

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.

jwilber 4y ago
At first you say: “No one reads resumes” 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
- jedberg 4y ago
  Further down I said "they skim for technologies and read around that". So in my example, I'd be skimming and see "Python" and then read around it. And also, as you said, the resume drives the interview, so they are good jumping off points and that's why they are there.
- cableshaft 4y ago
  > 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.
  - lifeisstillgood 4y ago
    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. Nice one
  - 4y ago
delaynomore 4y ago
>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.
- jedberg 4y ago
  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.
  - squeaky-clean 4y ago
    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.
    - berniedurfee 4y ago
      100% agree. Including numbers along with accomplishments was hammered into me at $bigcorp during performance review time. Same applies to resumes. They are impressive to recruiters, HR and often hiring managers themselves.
- renewiltord 4y ago
  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.
user5678 4y ago
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.
- jedberg 4y ago
  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.
doix 4y ago
> 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.
- Sodman 4y ago
  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.
  - shagie 4y ago
    > 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."
forrestthewoods 4y ago
> 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.
thrwawy74 4y ago
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"
ptrhvns 4y ago
What failure modes, biases, or false negatives does this method suffer from?
- jedberg 4y ago
  I'm not saying this is a method, I'm saying this is reality. From my experience, this is how most hiring managers read resumes. It has many biases and false negatives. But the point is that you should know this going in and adapt accordingly.
z3t4 4y ago
> Your resume should talk about results 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.
- vkou 4y ago
  > 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.
mym1990 4y ago
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...
confidantlake 4y ago
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!
stcroixx 4y ago
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. Currently hiring Java devs.
- dijit 4y ago
  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).
- jedberg 4y ago
  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.
  - mquander 4y ago
    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?
deathanatos 4y ago
> 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.
- jedberg 4y ago
  I disagree. They said metrics that show your contribution are useful, which is exactly what I advocated for.
LudwigNagasena 4y ago
> 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". That cannot be true, getting through screening is a zero sum game.
- jedberg 4y ago
  Why do you think it's zero sum? I might only have one position, but I'll interview as many people as I need to until I find one that is a great fit.
  - LudwigNagasena 4y ago
    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.
  - Cheezewheel 4y ago
    >I might only have one position, but I'll interview as many people as I need to until I find one that is a great fit. Yea. That is called a zero sum situation.
    - jedberg 4y ago
      No it's not. Getting the job is zero sum. Getting the interview is not. And we're talking about getting the interview.
brailsafe 4y ago
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"
iLoveOncall 4y ago
> 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.
- jedberg 4y ago
  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.
  - iLoveOncall 4y ago
    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.
    - jedberg 4y ago
      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.
bradlys 4y ago
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.
jiveturkey 4y ago
> Your resume should talk about results. 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.
- jedberg 4y ago
  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.
  - jiveturkey 4y ago
    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.

jwilber 4y ago

At first you say: “No one reads resumes” 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

jedberg 4y ago
Further down I said "they skim for technologies and read around that". So in my example, I'd be skimming and see "Python" and then read around it. And also, as you said, the resume drives the interview, so they are good jumping off points and that's why they are there.
cableshaft 4y ago
> 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.
- lifeisstillgood 4y ago
  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. Nice one
- 4y ago

delaynomore 4y ago

>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.

jedberg 4y ago
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.
- squeaky-clean 4y ago
  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.
  - berniedurfee 4y ago
    100% agree. Including numbers along with accomplishments was hammered into me at $bigcorp during performance review time. Same applies to resumes. They are impressive to recruiters, HR and often hiring managers themselves.
renewiltord 4y ago
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.

user5678 4y ago

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.

jedberg 4y ago
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.

doix 4y ago

> 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.

Sodman 4y ago
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.
- shagie 4y ago
  > 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."

forrestthewoods 4y ago

> 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.

thrwawy74 4y ago

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"

ptrhvns 4y ago

What failure modes, biases, or false negatives does this method suffer from?

jedberg 4y ago
I'm not saying this is a method, I'm saying this is reality. From my experience, this is how most hiring managers read resumes. It has many biases and false negatives. But the point is that you should know this going in and adapt accordingly.

z3t4 4y ago

> Your resume should talk about results 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.

vkou 4y ago
> 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.

mym1990 4y ago

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...

confidantlake 4y ago

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!

stcroixx 4y ago

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. Currently hiring Java devs.

dijit 4y ago
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).
jedberg 4y ago
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.
- mquander 4y ago
  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?

deathanatos 4y ago

> 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.

jedberg 4y ago
I disagree. They said metrics that show your contribution are useful, which is exactly what I advocated for.

LudwigNagasena 4y ago

> 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". That cannot be true, getting through screening is a zero sum game.

jedberg 4y ago
Why do you think it's zero sum? I might only have one position, but I'll interview as many people as I need to until I find one that is a great fit.
- LudwigNagasena 4y ago
  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.
- Cheezewheel 4y ago
  >I might only have one position, but I'll interview as many people as I need to until I find one that is a great fit. Yea. That is called a zero sum situation.
  - jedberg 4y ago
    No it's not. Getting the job is zero sum. Getting the interview is not. And we're talking about getting the interview.

brailsafe 4y ago

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"

iLoveOncall 4y ago

> 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.

jedberg 4y ago
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.
- iLoveOncall 4y ago
  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.
  - jedberg 4y ago
    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.

bradlys 4y ago

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.

jiveturkey 4y ago

> Your resume should talk about results. 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.

jedberg 4y ago
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.
- jiveturkey 4y ago
  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.