What a great technical resume can do for you
meetleet.com
meetleet.com
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.
> 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.
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)
How would you write that line?
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.
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 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.
Hope you don't mind if I steal some of your comment to use in the update of my post! :)
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."
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.
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.
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.
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.
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.
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.
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.
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! :)
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.
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.
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! :)
Those silly numbers are a complete showstopper form me but may actually work with some folks i would not want to work for.
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.
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.
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 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.
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.
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.
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.
No shortage of developers who consider rolling out a new feature to be a win even if it replaces a feature users preferred.
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).
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?
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.
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"
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.
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.
>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.
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.
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.
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.
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.
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.
“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.
I have a different angle on why it is rubbish.
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.
"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."
Hope that makes sense!
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.
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.
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.
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.
But in this existing world, a non-standard resume just makes it harder for anyone to screen quickly.
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.
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.
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.
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 :)
Who claims the credit on their resume and/or performance review? All of them.
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
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.
[1] https://www.meetleet.com/#team
[2] https://www.theladders.com/about-us
[3] https://en.wikipedia.org/wiki/TheLadders.com
[4] https://www.theladders.com/resume-reviewer
Disclaimer: I used to work with Marc 17 years ago when TheLadders was at pre-A round. Good times.
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.
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.
This sounds like one of those “how to pass your exams with least effort” advices.
How about you get abnormally good at what you do?