Hacker News Reader

Comment by ingvul | Hacker News Reader

> Refactored our front/end experience using React.

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

View on HN

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.

Original author here.

This is fair. For a developer at a small status, connecting their work to an increase in user engagement might be appropriate.

At a mid- or large-size firm, your bullet points would be more relevant and a better reflection of the work done.

I hope you don't mind if I steal these bullets when I update the post! :)

Question: Why are you doing this for free? Are people coming back for advice?

Those silly numbers are a complete showstopper form me but may actually work with some folks i would not want to work for.

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.

Are you asking why is OP blogging about this for free?

Well played.

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.

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.

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.

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.

IMO being able to quantify with numbers tells me the candidate actually cared about the outcome as well as the method.

No shortage of developers who consider rolling out a new feature to be a win even if it replaces a feature users preferred.

And do you think individual contributors have access to that kind of metric? And if so, would the 27% not represent a team effort?

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.

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

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

^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

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

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)

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.

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.

But what number would you like to see on a one liner bullet point to indicate “scale, scope, and complexity”?

Designed and implemented GraphQL API for 30 objects serving 200 Queries per second

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.

How would you write that line?

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

That still seems meaningless.

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! :)

Quote away!

OP here. Hope you don't mind if I borrow this for the update of my post!

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

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.

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.

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.

Or it is just a random number to show I have measured something because a website told me so. Why bother with numbers?

Because until it becomes abused to worthlessness it gives you a leg up on those who aren't doing so. That's the cycle of most things involving hiring.

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.

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.

> The number may be BS or unscientific

> but a number says you measured it somehow

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.

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.

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

OP here.

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!

[1] http://www.paulgraham.com/submarine.html

OP here.

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

Reply on news.ycombinator.com