Probably a dumb question, but when you say "tailor your resume", what kind of tailoring do you mean? I've seen this advice repeated a lot, but I've rarely taken it because I tend to apply to jobs with the same job title and roughly the same responsibilities; in general, I assumed that tailoring is mainly helpful if you have a diverse/generalist skillset.
Like, it's obvious to me why a true Jack of all trades would use different resumes for applying to a plumber role vs a carpenter role, but less clear why a career plumber would tailor resumes for applying to two plumber roles at slightly different companies.
Several months ago, having exhausted all other options in fruitless job search, I asked for assistance of a recruiter who I used to work with some time ago. Just to get some pointers on how I could improve my search, with his experience working on the other side. His advice on "tailoring" was very simple.
Go to the most popular LLM (ie Claude). Give it the job description. Give it your resume. Ask it for percentage match, it will give you a number. Then ask for advice on improving your resume, you can either ask to rework the resume by itself (if you're in a hurry) or you can work with the thing to modify the sections/entries yourself, one by one, if you have time. With each modification you will get better and better percentage match. Ideally you need to get to high 80% or maybe even 90%.
The idea is that automated ranking tools used by recruiters/HR are ultimately use the very same LLM, so you are improving your ranking assigned to your resume by those ranking systems.
I have to add that now this advice is mostly useless as everybody's using the same technique so you won't be standing up against others but merely be on the same level.
Add to it the fact that many job descriptions are inaccurate and sometimes downright misleading, and hiring managers use their own criteria, and you will understand why connections/referrals is probably the only way to get hired now.
> The idea is that automated ranking tools used by recruiters/HR are ultimately use the very same LLM, so you are improving your ranking assigned to your resume by those ranking systems.
Working in HR-tech, that is definitely happening, and "self-bias" is a thing with LLMs so if you can guess what the employer/screening-process is using then that's a bonus.
That said, we should distinguish between "Hey robot tell me if X matches Y" prompts, versus model-weights comparison. In the second case, the system feeds your resume into a model with no prompt, grabs all the magic math numbers, and statistically compares them to the magic-numbers if the model had been given some "ideal" resumes.
If the job is for a backend Java developer position, change the list of languages you know from:
Languages: JavaScript, C#, Python, Java
to:
Languages: Java, C#, JavaScript, Python
Many times people order their languages by familiarity or preference for working with that technology. Don't make the person looking at the resume have to hunt for the information. If it's last on the list, that may say something about how much you're interested in that job and how likely you are to stay.
> but less clear why a career plumber would tailor resumes for applying to two plumber roles at slightly different companies.
If one company is looking for a plumber to do PEX and another is looking for someone who is experienced with natural gas and black pipe, you might want to make sure that your experience in those two different domains of plumbing are at the front of the experience. They're both plumbers, but the heating and air conditioning company hiring a plumber is looking for different things than the residential new construction plumber.
It's so funny to me that a tech company will have no problem hiring a VP from, like, a beverage company - but heaven forbid you put your programming languages in the wrong order on your resume.
Hiring a CEO, you know (of) the person and its more likely a "the board wants to hire {that person}" and it really doesn't matter what the text of their resume says. At most there's a dozen candidates and a several month process for selecting one of them.
For developers, if the resumes are largely the same, then you're selecting for the ones that show evidence that they read the job posting and want to work there.
This isn't about hiring the best candidate - it's the least risky candidate that is hired. If you're listing the preferred language of the job and the language that is mentioned in the job posting last, you're more likely to be a risky candidate than one who lists it first. You may not know the language as well. You may not enjoy working on it (there's a reason I don't list php in the languages on my resume).
In a stack with less risky candidates, the one that has the preferred language last won't be at the top of the list for callbacks.
While this makes absolutely no sense to me, I'm pretty sure unhinged language fanatics would reject some resumes because "Java is not the first on the list".
HR people and AIs, as much as I criticise them: would not reject that.
AI wouldn't. It'll crunch the resume in milliseconds and sort it out itself.
HR is a mixed bag, usually without technical context. I'm sure most engineers in the 00's and 10's have some experience of "Java and JavaScript are similar, right?" In a recruiter call.
If I have 100 resumes, and 50 of them list Java first, and 50 of them list Java last, which pool of 50 am I most likely to find someone who knows and doesn't hate working in Java?
You're going to select 10 people out of that list of 100 because you don't have time to call everyone for three weeks to evaluate their skill.
You've also got only two hours to look through all 100 of those resumes today. You're spending about a minute and a half looking at each resume. How are you going to evaluate someone for a Java backend position who's last job was in C# and they list Java last in the list of languages they know?
>which pool of 50 am I most likely to find someone who knows and doesn't hate working in Java?
The one who has actual projects or professional experience in Java? I'm surprised this is such a sticking point. I list my skills last on the resume because it's the least relevant and it was mostly to try and satisfy ATS. But reality is stranger than theory, I suppose.
At least, that was my old approach. I found some advice I really liked and ultimately integrate a tech stack sub-bullet in every experience now. Seems to be a good balance of ATS and human(-skimming) readability.
If I were reviewing 100 resumes, I wouldn't use the language list. I'd use something with actual context, like work experience.
But more than that, why do you think someone who is terrible at java wouldn't put it first in the list when applying for a java oriented job? Assuming they were aware of this unwritten rule.
The last paragraph makes a great point: if the person has been out of Java the game for long, they will definitely be second to someone who's fresh out of a Java job.
And the reason is exactly as you say: limited time, excessive number of CVs. This completely changes the game.
Plumbing for new construction, plumbing for HVAC retrofit (even boilers and heat pumps might be further split), and emergency plumbing service tech (for leaks, water heater replacements, and blocked sewer lines) all seem different enough to me to make making clear what experience you had relevant in plumbing.
Greenland sharks are interesting because they do everything slowly, including aging. Our best guess is that pregnant Greenland sharks have at least a decade-long gestation period. Which seems like an adaptation to cold and relatively barren environments?
Worked on my fat ps2 just fine, I think I even used a dvdrw disc to do it initially... my memory is a little sketchy, I remember that I need a hard drive adapter though because usb is sooooo slow.
On the off chance Dan sees this: one of the footnotes ("Some Zitron predictions" > July 2024) is broken. Right now it's showing a little 0 that doesn't actually link to anything if you click it :(
I'm biased, being a software technical writer and not a dev, but at least from my side of the fence I think LLMs are no better at generating docs than they are at generating code, and might actually be way worse :)
My devs keep throwing Claude-generated writeups at me that look okay at first glance but fall apart when you actually try to follow the instructions they lay out (which makes them useless for anyone who's not already familiar with the product or feature they're describing), and/or have major structural and logical gaps, and/or gloss over messy details in a way that makes the product or feature sound better but doesn't reflect the reality of what we actually built.
Which turns into an ironic ouroboros where I then have to punch my own queries into an LLM and ask it to read our codebase, compare those details against the original writeup, try to decipher what the hell it was trying to say, etc. And even that turns into an extended back-and-forth where my LLM is like "The original writeup is inaccurate; it should say X" and I'm like "Are you sure? That contradicts what I know about related concept Y", and then the LLM is like "Good point, I dug into it more and the real answer is Z." (And even then, god only knows if Z is correct. I still have to get real developer eyeballs on anything before it goes live.)
Documentation was difficult to keep in sync with code because the tools didn't operate at a natural language level. Things like refactoring names, or terminology, or concept changes (foo is now fooGroup that contains bar) were tedious.
The granularity at which documentation parity is kept makes a big difference.
For example, brekaign things down into explicit assertion blocks in the code, and a link to the documentaiton that covers that assertion. So block-to-block tracking works well. Tracking completely separate documentation to independent codebase... idk I haven't tried it but my guess it that the context windows are too small for that.
But minor things like making sure there are unique error codes, that the codes somewhat make sense, etc. are all helpful. If nothing else, the model being stupid and acting as a rubber duck for pair-programming is useful for knowing what to document given a different perspective.
> But, and maybe I'm just a curmudgeon, but I kind of wonder why we write articles like this. Like if a culture is bad, is it likely a CEO is going to be looking for random blog posts for constructive criticism?
I think the odds of any particular article making it onto a CEO's radar are low, and the odds of them actually taking good advice to heart (let alone implementing it) are even lower. That said... I also get the impression that the shittest kinds of C-levels and VPs are disproportionately swayed by whatever opinion they last read in their daily email newsletter or heard on a five-minute podcast snippet. So at least in theory, if you were able to inject a seed of a good idea into the zeitgeist, that idea might reach the level of saturation where it turns into a form of white-collar peer pressure.
Unfortunately I also think the ideas that reach the peer pressure saturation point tend to be less "be nice to your employees" and more "put shock collars on them and make them beg for their jobs," but I guess it can't hurt to try?
I think sharing such ideas openly allows people to converge on similar feelings and experience which eventually leads to people experimenting these for real. We need to take into account that a lot of people reading and writing these kind of thoughts seriously may not be CEO at present but that does not prevents the possibility of them becoming the CEO's in future
> The present understanding is that the tale's moral supports team effort and recognition of the vital part that all members play in it. In more authoritarian times, however, the fable was taken to affirm direction from the centre.
IIRC that's what happened with the Boar's Head listeria outbreak. Inspectors had repeatedly documented that the facilities were nasty, but BH was allowed to continue operating for years because <reasons>. Things only came to a tipping point after multiple people died.
Like, it's obvious to me why a true Jack of all trades would use different resumes for applying to a plumber role vs a carpenter role, but less clear why a career plumber would tailor resumes for applying to two plumber roles at slightly different companies.
reply