> Refactored our front/end experience using React.
vs
> Increased user engagement 27% by refactoring our front-end experience in React.
Do tech interviewers actually prefer the second description over the first one? To be honest, I find the second one out of context (and a bit robotic/pedantic). Reasons:
- sure, 27% may look like a decent increase, but what was the metric you guys used? How many users you have? One cannot put all of this info in a resume of course (because it's a resume!) so please don't just drop a 27% there as if it means a lot
- I can imagine that the goal of the team/company was to "increase the user engagement", even perhaps "increase the user engagement by X%" and the product team thought "alright, let's refactor our front-end in React; no idea if it will bring an increase of X% or X/2%, but let's do it". But it's impossible to say that React (or any other tech) will bring you an increase of engagement in %X exactly. You just don't know that number, the number comes after; you may have some hypothesis but that's all. So, what you are actually telling me is this: "hey, we wanted to increase our user engagement by some percentage and so we refactored our front-end in React. Later on, our analytics tool told us that the user engagement increased by 27%." Again, you weren't aiming for that number, it just happened.
- you are not going to get hired for that 27%. Imagine there's another candidate that says "Increased user engagement 89% by refactoring our front-end experience in React". What now? Is him better than you? Again, context is king, but you cannot put that much context in a resume.
As a hiring manager, most of the “Increased revenue by 27%” type lines on tech resumes are clearly awkward attempts to implement generic Internet resume advice. When was the last time a company attributed sales growth to some developer making a change? Don’t try to take credit for things that the company, as a whole, accomplished.
The two places I like to see specific numbers are when communicating project scale or demonstrating some quantifiable change that was directly attributable to a person’s work. Good examples:
“Reduced AWS bill by 40% by profiling server code and implementing strategic optimizations”
“Architected cloud backend to support 500,000 daily users”
“Reduced average page load time by 57% percent”
If there isn’t an obvious, direct relationship between the person’s actions and the business outcome then I simply ignore it. If the person can only cite company-level achievements that don’t directly relate to their work, I assume they’re reaching because they can’t otherwise demonstrate how they personally contributed.
>>And do you think individual contributors have access to that kind of metric?
This actually goes back to a piece of career advice I read about a decade ago and was able to make use of to significantly boost my income: when picking projects or teams, try to move close to those that directly affect the company's bottom line. You'll have much better success when asking for raises and promotions because it'll be a lot easier to show the impact of your work (or at least have access to people who can pull up those numbers/reports for you, if you have been nice to them).
Of course they have access to the metrics. To take the 3 examples given, somebody removing AWS instances should have access to the billing, somebody running a web application should know how many daily users there are, somebody optimizing page load time would measure the page load time before and after.
Why? Great technical resumes make for better outcomes for professionals. We talk more about here: https://www.meetleet.com/#faq
Silly numbers: ok, if those numbers are silly, I agree, you shouldn't use them. What numbers are relevant to your professional success? How can you demonstrate, as a technology professional working in a commercial enterprise, that you helped improve the company, team, or product during this year?
The important thing is to find numbers that you don't believe are silly, but that are meaningful and relevant to your performance and share those. The nature of the accomplishments you cite, and the type of numbers you use, reflect the type of professional you perceive yourself to be. And that signal is meaningful to hiring managers in recruiting processes.
Fair enough, nothing wrong with that. I was interested if this is a startup or just your way of attracting clients.
Numbers are not silly per se but if i read a cv that tried so hard to quantify things, i‘d be sceptical. example: every developer knows that the number of lines of code can mean a multitude of things good or bad.
Well, that's exactly right: "every developer knows that the number of lines of code can mean a multitude of things good or bad."
So the goal is to display your sophistication and level of experience by showing your performance with numbers that are appropriate to your level and skill. Something that, when you're asked about it, demonstrates your capabilities, and your ability to delve into the technical details, in a way that only someone at your level could do.
Again, thanks for the feedback. The comments on this post, as usual for Hacker News, are phenomenal and informed. I think I've come up with at least 3 additional posts just based on everyone's feedbacks and critiques!
I would still like to have an answer regarding your business model. I think that beeing fully transparent here would benefit you in the end.
Are you storing those cvs?
Are you processing them?
Are you building a business around benchmarking CVs?
So why include such an obviously silly statement in your article? It just makes the applicant look inexperienced.
I am a single data point, but also someone who's interviewed 100+ developers across multiple companies, and from my perspective, after reading your article, you don't seem to be a person to listen to, and seem to be contributing to the already large amount of bad resume-writing advice online.
The main thing I have a feeling you misunderstand (the article makes me think you're not an actual industry professional) is that in most cases, to get hired, developers don't need to impress some technically-illiterate business person. The goal isn't to make some business guy swoon over how you managed to improve a metric a business person would typically care about. Instead, developers need to impress some very technical person, often multiple such people, to get hired. A resume should be written accordingly, and the goal is to make yourself appear to be a mature professional in the eyes of other mature professionals. You don't need to dumb things down - you don't need to do it for their sake, so dumbing things down just makes you look less knowledgeable or like you're trying to bullshit your way through things.
If I see "increased user engagement by rewriting into react" on a resume that just makes the candidate look like they're desperately digging for things to put in their resume that will make them look good. It is literally better to just write that you rewrote something into react. Of course, it's only a small part on my opinion of the candidate, but mentioning user engagement there, especially with a number attached to it, makes the person look like they're an inexperienced guy writing their CV by reading some bad "you need to show how you helped the company" internet advice.
"Measurable successes" are good if they're something I will see and it will think they are very intelligent and/or have a high level of expertise in some area, like solving a difficult problem / improving something in a way that's more efficient than I would expect. The fact that something they did was useful to the company means nothing on its own. You improved openh264 baseline encoding speed by 20%? Do tell.
For example, I once improved a part of a system, the slowness of which was causing big problems (things taking 20+ minutes to run), by 1000-10000%+. This was a huge thing. My boss was ecstatic and could barely believe it. He had asked me to look into optimizing it, but would have been happy even with a 100% improvement. I would never mention this on my CV though, even though I do mention that I worked on the system. Why? Because 1) an experienced person reading my resume would likely correctly assume I'm overselling what I did 2) I would get asked about it in the interview, and I would have to reveal I did it by going through the code and rewriting all the unnecessarily-O(N^2) parts into O(N). The fact that I had presented this as some kind of achievement would leave the impression that I am much less experienced than I actually am. It doesn't matter that I did something useful for the company, and it doesn't matter that I made a large measurable improvement to something. What matters is how much intelligence or technical prowess it proves I possess, and in this case that's very little. If I was in my early 20s, maybe it wouldn't be a bad idea to include something like that, as it would suggest I am at least a somewhat decent programmer and not stupid. But for me personally, it would be out of place. So it's good to think about what level of expertise you're trying to claim. But "I improved user engagement by 27%" will just always be bad, sorry.
> Don’t try to take credit for things that the company, as a whole, accomplished.
Skeptical about this one. Ostensibly, any result of value is achieved by the "company, as a whole" -- this seems like a tautological statement. Have you considered that committing to (and following through) being part of a long initiative that directly increases revenue for the company as a whole /is/ something worth mentioning on the resumé, and not merely par for the course?
It seems pretty pessimistic to reduce that to "awkward attempts to implement generic Internet resume advice." and I wonder if that has anything to do with what you see as a hiring manager. That is to say -- are you sure you're not scaring away candidates who actually /do/ accomplish these things? A technology arm of the organization that has increasing amounts of P/L responsibilities is par for the course at many quickly growing startups. As a hiring manager, I would be a huge fan of seeing these lines on resumés provided the follow up conversation I had with the candidate wasn't full of BS. If you're not, what does that mean?
To your point about not taking credit for things a company achieves: I think of this similarly to the advice about not always saying "in my opinion"; of course it's your opinion, you're saying it! Similarly, of course your contribution was just one part of a team effort, nothing is ever achieved in a vacuum! But I struggle mightily with this on both counts.
This is a great way of explaining it. I've often wondered why such claims have a bit of a cringe factor to them, and you nailed the reason why. Great distinction b/w nebulous claims and hard numbers. (Although I would exclude page load time which tends to be just a metric football in many companies.)
yeah for me it's a negative: they're misrepresenting themselves before we have even met. this is especially bad in stuff like dir/vp roles. ("... sorry buddy, you rode a unicorn, the 500% growth only means you didn't fall off. is that really your contribution?")
You’re going to miss a lot of talent by reading too much into peoples’ resumes.
There are dozens of possible explanations for any given bullet point that range from horrible to excellent.
Trying to draw too many conclusions from a resume isn’t all that different from reading tea leaves.
Well the opinion you form of a candidate is based on a combination of multiple things.
Also, in my experience, the candidates whose resumes contain questionable/silly things rarely turn out to be great; there is a negative correlation between questionable/silly stuff in the resume and quality. None of the top tier people I've interviewed (the kind where you start thinking "this guy should be interviewing me" during the interview, let's say I've had 5-10 of those) had anything questionable or silly in their resume, and for all of them I was sure the person was going to easily pass the interview based on just reading their resume. This correlation is in fact quite strong in my experience - I can't remember exactly, but I feel like the best candidates I've had who've had anything questionable in their resume were mediocre at best.
Note: just simply having a low-effort resume doesn't count as "questionable" here, I've had low effort resumes where the applicants turned out to be pretty great. Of course, that doesn't mean you should write a low-effort resume - it reduces your chances of getting an interview in the first place. People should just write honest, informative resumes. It's not really that hard to do as long as you're not thinking about how to manipulate the person reading the resume.
yep. it's a negative suggesting multiple potential issues: political/misdirecting, lacking positives that they could have instead highlighted, awareness+communication issues where they didn't realize the mistake, etc. none of those may be true, and even some they are, not matter for the role, so you're right, can be fine.
but in a startup scenario.. there's less room for hiring mistakes than in a bigco, so I wouldn't just ignore. I've definitely passed on folks after catching lies in their CV - trust is a pretty basic ingredient before asking someone to own something. overclaiming here isn't a 100% lie, but it is a warning sign on issues like the above that are worth understanding.
^this. refactoring into React or any tech stack does not correlate directly to user engagement or revenue. It sure does have impact; but perhaps it's more relevant to state something like improving page load time, developer productivity, time to market (or MTTR, etc) because of cleaner architecture that enables to iterate faster and so on
I totally agree that this trend is dumb. It doesn’t even pass very common sense checks. Just because its numbers doesn’t make it a good signal. Anyone can cherry pick numbers that make their contribution look godlike. Oh I improved the loading time of our internal tool by 1000% by applying very basic optimizations I googled 5 minutes before that no one had bothered to do since it’s low priority.
Especially at smaller companies where you can easily 100-10000x specific things that no one has had time to optimize yet since they haven’t been top priority. To a smaller extent at big tech but the point is that optimization numbers without a great amount of context is completely meaningless (like the parent said)
Numbers are good. These are the wrong numbers to include. You want something that indicates the scale, scope, and complexity of what you did. I don't care that you increased user engagement by X%. I care that you've designed and implemented the type of things that I need designef and implemented.
Improved the performance of a rendering system from 10000 objects per second to 100000.
Super vague, means basically nothing. Maybe it should be written with a bit more detail about what kind of rendering system this is. Still I would be interested, and in the interview I would ask them to explain the system and what they did. However, if it was something stupid (the original code was just super bad) then they would look dumb for bringing it up. Basically, if you put something like this in your CV, it should be something you're proud of for a good reason, not a result of trying to think of anything where you can reduce the impact of your work to a number.
The impact of most work cannot be reduced to a number, so it's perfectly fine to not have any "measurable successes" like that in your CV. In my experience, 75% of people don't, and 75% of people who do have stupid ones that just make them look worse (ie they read online resume-writing advice and put in something like the example this discussion is about). So there is no point in actively trying to think of something like that to put in your CV. If you have something, put it in, if not, that's fine. There's a pretty good way to decide whether to include it: does imagining your interviewer reading it make you feel proud or embarrassed?
But what if you implemented the same rendering system from scratch? If you put in a number, it will mean basically nothing. You can just describe what you built. You don't need to reduce your work to a number. This is simply incorrect advice in the linked blog post. The people hiring you are not judging you based on numbers which claim you contributed to the business in a measureble way. This is simply not true. Ideas like this are usually pushed by people who are not even in SD and are instead self-proclaimed "experts" in the field of "finding jobs" or whatever and are painting all industries with the same brush.
How many daily users? How many posts/orders/sales per day? (that one depends on what your company sells or does)
How many GB of traffic?
How many people did you work with in your team/department? If you provide internal or public libraries, to how many developers?
I don't think it's shocking to have a line "Worked in the web team with a total of 4 developers in charge of the website of the company (react), backend API (nodeJS), and the Android application."
200 queries per second, while pegging 8 CPU cores. Meanwhile my coworker got the short straw implemented a less-used API serving 10 queries, but did it much better than me and used no CPU.
That's far from a perfect statement, but it's not the worst that you see. As an interviewer, the difference is between junior and senior developers. It's an indication that they they understand the currency and some metrics for an area/business, but more than that, it sets out their position.
That position is something I should be challenging in the interview with questions to probe deeper:
* Can you tell more about the GraphQL API? Was this new or replacing an API? Tell me about the constraints and goals you were working towards?
* What issues did you have getting to that level of performance? What trade-offs did you make when you hit issues?
* What are the challenges with running your API in production?
* Can the API you implemented scale higher? If so, what would need to be changed with it as you scale to 400 and 1200 queries per second?
If this person has done the work this should be a good discussion and you can start to bring in some of your business or technical problems. It will be very evident whether someone has just invented metrics, or the statement is describing the work of others.
I feel it's important for technical interviewers to have some experience with STAR/behavioral interviewing. This assists with screening/selecting resumes and exploring these areas in interviews.
OP here. This is exactly right: "I feel it's important for technical interviewers to have some experience with STAR/behavioral interviewing. This assists with screening/selecting resumes and exploring these areas in interviews."
Hope you don't mind if I steal some of your comment to use in the update of my post! :)
To me that would still tell nothing. Did you just implement 30 queries that are “get item by key” from a database someone else designed so that your job was extremely easy ?
Even if it doesn't answer every question it gives you at least some insight into the scale and scope of what they did. Sure numbers can always be fudged but it's better than no numbers.
> Sure numbers can always be fudged but it's better than no numbers.
You can make the same argument for user engagement or business metrics numbers too. For most managers reviewing resumes, any number is better than none.
Thanks for the comments. Perhaps I can be helpful by walking backwards from something you do perceive as valuable? For hiring conversations, what's a great one look like to you?
OP here. I agree with your feedback. At a small startup, engagement might be relevant. At a larger company, scale, scope and complexity, relevant to the level, are absolutely more appropriate.
I agree, but I also believe this is what the HR department would respond to best, if you happen to go through them first. All too often that is the case.
OP here. Readers of your resume, and ultimately hiring managers, will make assessments of your overall capabilities based on the type of achievements you use in your resume.
If a senior engineer cited an improved loading time that could be googled in 5 minutes as one of the 4 or 5 accomplishments in her or his two years at a company, they'd be sending a bad signal about the type and scale of achievements they're capable of. Hiring managers will be looking for something more level-appropriate and that indicates a relevant level of skill.
The exact number is irrelevant, the fact that there is a number is relevant. That means the developer not only understood the business requirements but also measured the impact afterwards. That's a very valuable skill in many companies that use metrics to make decisions.
In fact it doesn't even matter if the number was utter BS and unscientific in measurement. So are probably 80% of metrics in companies that are metrics driven. But the manager running the team still needs a metric to meet their goals and this developer shows that they can deliver that.
OP here. I think this is exactly right "The exact number is irrelevant, the fact that there is a number is relevant. That means the developer not only understood the business requirements but also measured the impact afterwards."
In follow-up interviews, the interviewer may dig into those results, and in reference checks, may try to confirm your achievements, so I do not think it's accurate to say it would be OK to use BS numbers.
But the overall sense that numbers are important, and send an important signal about a developer's work habits, patterns and practices, is true.
A number can be corroborated by multiple people and have a logical chain to its creation and still be utter BS. Even scientific papers with their standards have massive issues with reproducibility. Look at the HN comments pointing out measurement methodology flaws when some corporate blog claims X% improvement.
My point was more towards those engineers who are sticklers for accuracy and truth. It doesn't matter in this case. Mass delusion is fine as long as enough people believe it and there's a thin veneer of logic around it.
That's not really the type of information offered during a reference check. Did x employees actions on this project result in a 27% increase in engagement?
A lot of places only give yes this person worked here between those two dates.
The person giving the reference would be in no position to answer in many cases.
Legally a company doesn't want to get sued because they told another company the person didn't hit 27% when they might be able to prove they did.
It shows that you are thinking about 'the greater goal' of improving commercial/revenue performance for the company over "just" technical stuff. This is incredibly rare, I would say less than 5% of technical/developer resumes I read have anything remotely relating to this. Usually very tech heavy, which is great, but a few bullets about this shows you understand and care about more than just the tech side.
as a developer you generally can't directly pin numbers to your contributions. A very long time, I helped a company get into a new segment of market. I have no number to give, it's just that the CEO, told me so. I'm not even sure it was smart to go there, I was just asked to transform the product to go there, and I did, but I'm not a salesman.
But you don't need numbers for that. A simple "increased user engagement by refactoring our front-end in React" is more than enough; it tells me that the goal was to "increase user engagement" (that's the greater goal, nice!) and that you know (hopefully) your way around React (tech stuff, nice!). The number strikes me as bs.
Companies are driven by numbers and manager bonuses are driven by the numbers their team produces. A developer who shows they can produce those numbers is valuable. The number may be BS or unscientific or whatever but it is there and usually that is enough for management. Anyone can say "increased user engagement" but a number says you measured it somehow which gives it worth and that is why management wants numbers.
Okay so it may be BS, but at least it's measured somehow, where somehow may include pulling it entirely out of your ass.
But indeed this is key:
> Companies are driven by numbers and manager bonuses are driven by the numbers their team produces
Those numbers may be bullshit as well, but there's already a cult around them and you demonstrate belonging to the tribe by flinging around numbers just like they do.
I agree this is something to look for, but doing that with numbers alone makes you look like you had extremely narrow responsibilities, and probably shouldn’t be interacting with stakeholders anyway because you can’t use words like a normal person.
100% agree. For a long time I got by with my resume just covering achievements at a high level without any numbers. Every time I asked for resume advice, people suggested adding more numbers to it. Having worked on building up a lot of infrastructure stuff from the ground up, I never really had a great way to describe my job with a handful of numbers because the impact was the creation of the project rather than increasing/decreasing/reducing/whatever metrics. Eventually I caved in to the trend but this led to an interesting encounter: I had one behavioral interview where the interviewer really ripped apart some of the numbers -- what does "growing user base by 50%" mean out of context if you only have 10 users, how accurately can "decreased load time by 75%" actually capture the scope of your work if it's a 5 minute change, etc.? Numbers can be great to tell a story, but it seems like often time that story is either a distraction from the day-to-day reality of a job or just a gamed metric of some kind.
This trend really sucks because there's a definite pressure (at least early in one's career) to pick up tasks at work that look good on a resume but may be low-impact IRL (e.g. rather than adding a new feature that people will pay for, let's just whittle away at latency that's already fast enough for our users).
Thanks for the great comment and sharing your story. In the context of your background - "Having worked on building up a lot of infrastructure stuff from the ground up," it's important that you chose numbers that are level appropriate for someone of your capabilities. if the feedback was " how accurately can "decreased load time by 75%" actually capture the scope of your work if it's a 5 minute change", then that indicates that you may have been showing numbers that weren't truly indicative of your skills and talents.
And I don't agree that picking up tasks that are low impact IRL will help. Ultimately, hiring managers aren't easy to fool, and low-impact metrics make a small impact on resume readers.
Charitably, it's to show you care about business context.
Realistically, it's a tribal signal to cargo culting manager types who like to talk about percentages and like pointing to flipcharts with a stick in a suit.
It doesn't matter what number you put there.
If you're writing to numerate, technical types don't do this, because technical people know that just a percentage without context makes no sense. You reduced costs by 16%? Costs of what? What's the denominator? You increased engagement? What does that mean? Subscribers? Clicks? Time spent?
This is the same kind of thing as when academics sprinkle unnecessarily complicated-looking math equations to describe plainly obvious things with impressive symbols, when it's objectively unnecessary. The goal is to give it a certain look, to signal seriousness.
As silly as it may sound, it probably actually works.
Since we are on HN, probably many of you know the Paul Graham classic "Submarine" [1] post,
> Our greatest PR coup was a two-part one. We estimated, based on some fairly informal math, that there were about 5000 stores on the Web. We got one paper to print this number, which seemed neutral enough. But once this "fact" was out there in print, we could quote it to other publications, and claim that with 1000 users we had 20% of the online store market.
> This was roughly true. We really did have the biggest share of the online store market, and 5000 was our best guess at its size. But the way the story appeared in the press sounded a lot more definite.
> Reporters like definitive statements. For example, many of the stories about Jeremy Jaynes's conviction say that he was one of the 10 worst spammers. This "fact" originated in Spamhaus's ROKSO list, which I think even Spamhaus would admit is a rough guess at the top spammers. The first stories about Jaynes cited this source, but now it's simply repeated as if it were part of the indictment. [4]
> All you can say with certainty about Jaynes is that he was a fairly big spammer. But reporters don't want to print vague stuff like "fairly big." They want statements with punch, like "top ten." And PR firms give them what they want. Wearing suits, we're told, will make us 3.6 percent more productive.
I think it's similar with certain hiring managers too. They want definite statements, because it provides for CYA ammo. The guy looked great on paper, look at those percentages!
I agree with this: "just a percentage without context makes no sense. You reduced costs by 16%? Costs of what? What's the denominator? You increased engagement? What does that mean? Subscribers? Clicks? Time spent?"
And this: "Charitably, it's to show you care about business context."
But disagree that you should not do this if writing resumes for "numerate, technical types."
A great technical resume helps get you the interview. In an interview, especially a behavioral interview, you'll be asked deeper question about that 16% cost reduction. Exactly the question you've pointed out. And your resume is more likely to get selected for the reason you pointed out - it shows that you care about business context, or, more broadly, commercial technical achievement.
With technical, numerically literate types as interviewers, they are going to want to know something about how successful you were in being technically accomplished. And the plain, observed, fact is that professionals who demonstrate, with numbers, their accomplishments, get more interviews than professionals who paste their job description, or simply assert they achieved something good without quantifying it.
And a good Paul Graham citation is always welcome and relevant! :)
From the perspective of the interview, such numbers can come across as an actually big deal or as near-cringeworthy "followed resume advice". There's a very thin line in between and I feel many interviewers will fall on different sides - particularly depending on whether they are in a technical or in a business role.
In my eyes, mentioning such numbers usually comes of as resume cliché. By all means, demonstrate your understanding of the business context or highlight an important problem you solved. But I agree with the quoted part regarding numbers without context being pointless - if they're modest then you didn't do yourself a favor, and if they're impressive then I am skeptical about taking them at face value.
I agree that this particular example makes no sense. If I'm looking to hire a React developer to help me achieve my business goals, what I care about is how proficient is the candidate is in React. Unless it was it was decision of the developer to do the rewrite, the metric is out of context.
Better example built around the engineering skills, which are probably more relevant:
"Lead a team of two migrating our 100 Backbone Views front-end to React in two months, without disrupting deployments"
Author of the post here. Great comments from everybody.
The importance of numbers on your resume comes from a few places:
- Shows you care about the results of your work, rather than just performed the work
- Show that you understand the connection between your work and technical or business outcomes
- Demonstrates your specific capabilities in using your technological skills in delivering results
At this moment in time, the amplitude of accomplishments does not matter. For example, two resumes with the same type of accomplishments, but one has double the numbers of the first, would not mean that one resume is twice as likely to get interviews. Both would be far more likely than a resume without numbers to get interviews.
In a future world where all technical resumes have well-attested numbers, this may shift. We are nowhere near that point yet.
As for accomplishments not being fact-checked. Well, yes, that's true. And that's why a resume can generate you an interview request, but not a job offer. During an interview, particularly behavioral interviews, an employer will dig deeper and want to understand more about the why and how you achieved what you achieved.
> Increased user engagement 27% by refactoring our front-end experience in React.
>But it's impossible to say that React (or any other tech) will bring you an increase of engagement
I think it's more like it is very unlikely that the choice of technology used to implement something is what improves the user experience in any way. Basically the only way I can think of is if technology choice has a noticeable effect on performance.
As a general rule technology choice improves the company experience - so a statement like:
Increased our ability to roll out new functionality 27% by refactoring our front-end experience in React.
or similar statements about how technology choice improved things for the company might make sense, although of course your remarks regarding the percentage still holds.
What's really more important than having numbers is having specific details on your resume (which could include numbers). Every bullet point on your resume might represent months of work (depending on how long your career has been). E.g., you may have refactored the front-end in a few days, or maybe it took you two months. There's no way to sum that experience into one bullet point, and that's not really the point.
It's better to have some very targeted details that can reveal the depth of your experience than high level summaries which may technically be better descriptors. It helps the person reading the resume better imagine who you are and the kinds of things that you do.
It also can provide a bit of context that you can later expand on in more detail during e.g. a screening interview. They might ask you how you measured user engagement, which gives you another chance to talk and sound smart. You might miss that opportunity with more generic descriptors.
The other reason this is stupid is, the person reading your resume is usually either some administrative person doing basic filtering or a knowledgeable technical person. Neither of them are going to be swayed by you claiming you increased user engagement or cut costs by X%. The administrative person is going to ignore it as it's beyond the scope of what they're doing, and the technical guy will laugh at it.
I can't imagine a situation where this would realistically make you look good. Maybe if you're applying to a small/micro company who has no technical staff at present time, and the owner is non-technical and looking at your resume themselves? Basically a company that lacks anyone qualified to evaluate you, and they're looking for their first developer to build something that will help their business. Then you might be able to sell yourself by claiming you improved business metrics.
Probably depends who's reading it. For a non-technical person reviewing this resume, the first one doesn't mean anything. And at most companies, there are still non-technical people who screen resumes before forwarding them to the hiring manager (to make sure you have at least 10 years of experience working with a framework that has only existed for 5, etc.)
To that audience, the two examples might as well be something like:
> Remodulated the warp core using Coaster.js
vs.
> Made the company oodles of big money with this one neat trick.
As a senior developer when I see a job description that speaks more to frameworks or tool chains than product I ignore it and move on. I suspect some interviewers might do the same for candidate resumes. The difference is communicating what you actually accomplish versus how you might do it.
another thing is I can't see how refactoring with react can increase any user engagement, either the previous version is so slow that it's unusable or the product also gone through some UI/UX redesign
HN loves to be gruff and contrarian about these topics. So I'm going to say this for any readers that are or will be looking for jobs:
Yes, the article is mostly right. Yes, you should quantify your achievements as much as possible. And yes, the popular pattern "Accomplished X, as measured by Y, by doing Z" is effective.
The example in the article is not the best because there's too much of a leap between "moving to React" and "increasing user engagement by 27%". As a reader I'm left wondering why moving to React had such an impact. In this situation it's worth spending some of your precious word count to explain things better.
One of the problems is that "measured by Y" often does not exist, so if it is included, it is misleading, lacking context, or just whatever number could be found.
A colleague of mine probably doubled the speed of an API by deleting a feature on that page. The only reason we know is that it is noticeable how much faster it is in manual testing. Took him a few minutes to remove the function and run the tests. "Cut API load time by 50% with optimization of Hibernate queries" is true, but also ridiculous.
On my own resume, I have played with the words to arrive at the largest number possible for the scale of what I did. As we didn't numerically measure anything, so it was massaging of a number into a number that was large. Recruiters seem to react well to it, but it is absurd that they do.
I don't disagree that this works. I use it on my own resume. I don't think that is the problem HN has. It is just expressing annoyance that we have to play another stupid game to get hired.
Thanks for the great comment. As you think about your overall career, I guess I'd ask you to not think of this as merely a stupid game.
In the complete context, you're an accomplished technology professional who will continue to develop skills, talents, and capabilities throughout your career. How you put your talents to work in solving level-appropriate challenges and problems is important to your progression in your career.
So starting with the meaningful, real, achievements -- your ever-improving aptitude and problem-solving abilities, applied against problems of ever-increasing complexity and depth -- how do we best express that in a short, asynchronous format of about 300-500 words?
Inevitably, the compression of a human experience to this reduced, written, format will leave out meaningful nuance and important clarifications. But in the overall system, it's necessary for the participants involved to have some way of prioritizing the expense of time, money and attention on interviewing and recruiting specific individuals. The alternative is unworkable for everybody - we simply can't conduct full interviews of every applicant, it wouldn't be a good use of company's OR applicants' time.
So if, for the system to work better, we need to adopt this practice, then how can you best represent your true professional capabilities within a limited, constrained document such as a resume. My post suggests it is with numbers, and my observations of actual behavior with recruiters and hiring managers show that numbers are better.
A great technical resume can help get you the interview. In an interview, especially a behavioral interview, you'll be asked deeper question about that 50% reduction in API load time. If it turns out that it was just a few minutes to implement, the hiring manager will, rightly, question your technical judgment in putting that forth as one of the 2 or 3 or 4 most significant accomplishments in your career at that company.
So rather than viewing it as a game, I'd suggest starting with the real achievements you've had in your career, focus on those and how to best represent them in brief, written format. Tricks or shortcuts like mentioning a task that only took a few minutes won't work well, and leave you behind where you could be with more appropriate achievements.
> "Cut API load time by 50% with optimization of Hibernate queries" is true, but also ridiculous.
In my experience it's absolutely not ridiculous (improvements should be measured by impact, not LOC) but it could still be improved by conveying the benefit to the company or API consumers.
If nothing else, just make sure they come off as achievements rather than just stuff you did. We’ve all seen projects that made us go “but why? That seems like a bad use of time.”
“Migrated from MySQL to Postgres” could be a massive waste of time, or it could have made something much better. The difference between a waste and an accomplishment is what is you want the resume to reflect. A quantified outcome is one way to do that, and reflect well on some roles/projects, but not others.
Rubbish. I was in IT 30 years, and it was all about surviving BS projects which inevitably were declared a "success" if they achieved 5% of the promised functionality. Numbers, performance ? What a joke. Yet I made a good income in senior jobs, leading "succesful" projects.
Managers who hold the purse have no idea of technical measures anyway, or care.
If someone is not getting any replies even if he sends out 10's or 100's solicitations, I believe there is no tweak he can do to his resume that will help him. Because then he probably does not have needed experience or skills, so it is more about finding right level that you can apply for, than tweaking CV.
You are not going to get better salary because of your CV, after you have a reply, resume goes out of the window.
I was having a friendly conversation with my boss. I tried to joke about how windows batch basically gaslit me for half an hour, because I didn't know batch variables are substituted at evaluation time, not runtime, so it basically makes it impossible to reassign a variable unless it's in a batch script file with EnableDelayedExpansion turned on. I don't think I fully communicated the joke but I learned a lot just by trying to.
Some of this is "yes, I wish people understood that" to me, like:
"It’s to make it as clear as possible which types of problems you’ve solved in the past, and how well you solved them." This is all I care about. I want to see the complexity of what you've handled.
"As a result, their bullet points are full of sentences that begin “Responsible for” or “Worked on” or “Assigned to.”" These phrases have always struck me as meaning "I sat in the same building while these things were going on."
But when the author suggests using numbers, those strike me as bs. I assume that success in moving numbers depends on what the starting point is. I'm sure I could walk into the typical high growth startup and find tons of places where I could get a 10x performance improvement, because they've been focused on other things. Is reducing AWS cost by 17% (from a low baseline) better than doubling AWS cost and allowing the team to make better decisions because the data is normalized and easily searchable?
This made me laugh: "I sat in the same building while these things were going on."
I agree with you that starting point matters, and that context matters - such as sometimes doubling AWS costs would be better.
The nature of the advice is the science - using numbers factually works better. The nature of your feedback is the art - the types of accomplishments you choose to demonstrate reveals a lot about you as a professional.
To take our example of the doubling AWS costs to make better decisions. Well, how can you quantify those were better decisions. If it's just by the feels, that's not as effective. If you can quantify it - Helped team make decisions that led to x% improvement through database normalization - that is more persuasive than simply saying "Improved team's decision making through database normalization."
Do people take stuff out of their perf reviews and put them into the resume sometimes? I imagine most perf reviews are fairly focused on numbers as well, curious if there's an overlap of content that could go on a resume as well, my intuition says most probably there is.
Yup, this absolutely works! I always write my performance review as if I were updating my resume. If I don't like what I see, that's feedback to myself and motivation to change my plans for the next review period.
This particularly works in companies big enough that internal transfers are possible; the text of the performance review should be specifically written with the idea that the next hiring manager will read it in mind.
Oh my goodness! You are our target user! This is exactly the correct way to think about: "I always write my performance review as if I were updating my resume."
Email me please - my first name at our domain name.
How many companies actually measure things in enough detail for most people to do this in a useful manner?
I have numbers on my resume, but they are just whatever numerical metrics I could get. They are there for the sake of numbers on the resume.
Nobody is tracking how much slightly faster an API might have become or how many fewer bugs were produced a sprint unless it is an extremely data driven company.
Fair feedback here. A lot of companies are not data-driven enough. But with OKRs and behavioral interviewing, the trend is towards companies and interview processes being more data driven.
I'd suggest that this makes it more important for you to track numbers. You're responsible for your own career - your current employer certainly isn't concerned about where you will be 10 years from now.
My recommendation would be, from now on, to keep an eye on the 3 - 5 metrics you can realistically help in moving in a year. Track the numbers independently if possible. It matters much more to your career than to your company, and helps you share a story about your capabilities to future bosses and employers.
> Many technical resumes miss the results and the numbers
How are those number of any help if I can just arbitrarily select those that are in my favor and ignore the rest?
> Increased user engagement 27% by refactoring our front-end experience in React.
Was it really your refactoring that caused those 27% or something else?
Did your refactoring had any negative side effects that you are not talking about? How do I know it was really 27 and not just 2%?
Numbers are useless without context and contexts are often company-specific or purely a matter of opinion.
> Instead, a technical resume’s primary purpose is to generate interview requests for you. It’s where you make the case to “please pick me out of the pile.
Yes. A resume's primary purpose is to win favor for an interview. But! Not all suitors and opportunities are equal. That is, the goal isn't simply interviews, but interviews with the right organizations, with the right culture, that have the best potential for an LTR.
I was with the author until I got to the actual advice. "Worked with technology X" seems a lot more relevant and useful than "achieved x% improvement" or "reduced cost by 30%". The latter doesn't just signals that the owner of the resume read a questionable article online and decided to follow its advice.
When hiring managers and recruiters are looking through a stack of 100s of resumes, or even 10s of resumes, all of which say "Worked with technology X", how can they choose which professionals to interview or phone screen.
Actual experience in the real world is that those who quantify their success in using technology X to achieve goals / OKRs / results for teams tend to get the interview.
The problem with the "achieved x % this-or-that" statements is that they require a lot of context to understand and are very difficult to verify. Don't tell me that when you're screening hundreds of resumes you can successfully understand what those achievements actually represent or what kind of skills and effort they required in the context of their company, team and problem domain. Let alone compare candidates based on a bullet list of their claimed achievement, each of them using a different metric and worded in a different way.
Yes, that's completely true. Statements like this require a lot of context. How the recruiting workflow works today is that context is surfaced in actual interviews.
Would it be better if we could somehow accurately assess professionals on the sum totality of their experience, contributions, behaviors and traits? Yes, indeed it would. But it would also be a lower-paying world because managers would only have sufficient information to hire the people they know closely, and have personally observed over sufficient periods of time.
Our modern system that enables people unknown to a company to be hired based on a simplifying process is a feature, not a bug. Because of this system, companies can scale, hire hundreds or thousands of engineers, and create world-defining products. That success is what enables companies to pay the extraordinary compensation that the technology profession currently earns.
In a world historical context, or even a 21st century capitalism context, the compensation paid to professionals with only a few years experience is absolutely without precedent. Many technology professionals earn more per year in their first year of employment than their parents or grandparents ever earned in a year in their entire lifetimes.
So while I agree there are downsides and negative aspects to the tradeoff of the modern, anonymous, meritocratic system of hiring, the benefits, for technology professionals and the world, far outweigh the negatives.
Yeah I think this article has good advice for something closer to a perfect world, where a company gets a good signal for the employee but frames this as making it the prospective employee's responsibility to give that signal.
But in this existing world, a non-standard resume just makes it harder for anyone to screen quickly.
I've put lots of little coding solutions, links to my videos and articles on my website [1], and have sent this to potential employers in the past for web dev jobs. It definitely helped accelerate things, and on 3 occasions I didn't have to do their take home test since my GitHub was enough. I don't have an up to date CV and my LinkedIn is empty.
I've also heard of potential colleagues giving positive sentiment to the hiring manager/boss: "oh that guy, I'm subscribed to his mailing list, he's good".
I've received a good number of offers, and one thing I've started to wonder: are interviewers thinking I'm a great dev because all these little side projects supposedly make me a better web developer? Or are they hoping I'll increase exposure to their brand since I already do talks and write articles?
I hope it's not the former, all the time I spend writing, doing talks etc. it's taking time away (with the exception of software-based side projects) from me learning about the art of software engineering.
OP here. If you're in the 1% of developers than can consistently produce quality content in blogs, videos, and other formats, this can absolutely be a superior way to demonstrate your command of your field and the subject matter.
To state the obvious, the time, care, attention and effort involved in producing superior content such as yours Umar, is a lot more than getting a free technical resume rewrite from MeetLeet :)
How does a dev claim credit for increasing engagement by refactoring? So many of these metrics will be the result of a team. Switching to AWS may save money. But who gets the credit? The engineer? The manager? The architect?
It's more about setting yourself up for success in a place you'll be happy at.
Ask yourself, do you want to work with a bunch of people who present themselves like "X"? If the answer is "no" then don't do it.
For instance, maybe you have a graduate degree from a prestigious university but for whatever reason you don't want to work at a place where that's a filter, so you leave it off.
Maybe you've been doing technology X for a couple years and you're both good at it and really sick of it. So you leave that off too.
Really, this is about the kind of culture you want to be part of, the kind of people your want to work with and where you think you'll be happy.
You'll get fewer offers but you won't be working a job you hate that makes you miserable for the next year or two. Isn't that the more important thing?
Make sure you're sending your personal right signals
On point — I was getting some resume feedback earlier this week and was given some advice on how my resume should be written and formatted to pass an initial ATS scan. This is all well and good, generally, but I have no formal education background in CS/SWE, which I imagine would immediately disqualify me from any workplace that filters applications in an automated way. If anything, I’d imagine that trying to have the same micro-optimized resume that follows basic online advice may actually be detrimental here.
It’s tough as looking for a job is not super fun, so it’s tempting to try and find some magic bullet solution. I came to the conclusion that I’d rather try and present myself as honestly and effectively as I can and not take 99% of what I see regarding resumes to heart, and try and direct any interested people to my portfolio/work as soon as I can.
Heart comes from the same place, but a separate effort :) We're focusing on writing technical resumes for free, which is a different business than TLC.
I feel like some of the disagreement that others imply in their comments comes from a misunderstanding of what is telegraphed when someone writes their resume in this way.
The actual metrics need context to be reliable, of course, but what is being telegraphed by someone that includes outcomes-related metrics on their resume?
Contrast an answer to the above question by what is (and more importantly, is not) telegraphed by an "alternative" resume, more passive, more "used #{technology} to build #{feature}"
Bikeshedding on the exact metrics, the truthiness of the statement, is missing the forest for the trees.
I keep my resumes crisp and to the point. The first section briefly explains how I evolved from a Python 2.7 desktop application developer to a full stack web developer using Python 3 on the backend over the years.
The rest is just my employment history, a few lines describing my academic achievements and a few links to personal projects related to my work experience (I change these depending on what my potential employer is looking for).
I write this on a HTML sheet using Bootstrap for the layout and some basic styles, and I convert it to a PDF with pdfkit. Recruiters love it so far.
Do hiring managers even look at resumes (beyond maybe how many years experience person has)? Like i know they're important to get past HR screen, but i didn't think hiring managers actually read them because they are so easy to BS they are bssically useless as a signal.
Any insight from FAANG et al companies with respect to resumes? I would guess they’re just glanced at for years of experience to bucket candidates against a type of interview schedule that then determines level/comp and that’s about it. Any managers can weigh in?
vs
> Increased user engagement 27% by refactoring our front-end experience in React.
Do tech interviewers actually prefer the second description over the first one? To be honest, I find the second one out of context (and a bit robotic/pedantic). Reasons:
- sure, 27% may look like a decent increase, but what was the metric you guys used? How many users you have? One cannot put all of this info in a resume of course (because it's a resume!) so please don't just drop a 27% there as if it means a lot
- I can imagine that the goal of the team/company was to "increase the user engagement", even perhaps "increase the user engagement by X%" and the product team thought "alright, let's refactor our front-end in React; no idea if it will bring an increase of X% or X/2%, but let's do it". But it's impossible to say that React (or any other tech) will bring you an increase of engagement in %X exactly. You just don't know that number, the number comes after; you may have some hypothesis but that's all. So, what you are actually telling me is this: "hey, we wanted to increase our user engagement by some percentage and so we refactored our front-end in React. Later on, our analytics tool told us that the user engagement increased by 27%." Again, you weren't aiming for that number, it just happened.
- you are not going to get hired for that 27%. Imagine there's another candidate that says "Increased user engagement 89% by refactoring our front-end experience in React". What now? Is him better than you? Again, context is king, but you cannot put that much context in a resume.