I've read a lot of resumes in my time, and here is my advice:
No one reads resumes. At best they skim them. They look at the shortest lines, which are usually where you worked and the job title. Name recognition makes a difference here, no matter how many people tell you otherwise. This applies to your college as well. But don't let it discourage you, it's more of a "if you have a big name there you get a boost but it's not a negative if you don't".
They skim for key technologies and then read the text around them.
They most likely will read the full text of the most recent job, so make sure that is the most detailed and interesting.
Your resume should talk about results. Don't say "Created a new CMS for the company". Say "Created a new CMS for the company in Python that resulted in an ~70% reduction in website update times, from 1 hour to 18 minutes."
If you do put a "skills cloud" on it, be ready to talk about them all. If someone had a skills cloud I would immediately look for the most esoteric skills and dive deep on it in the interview (after Googling it myself) to see if you were BSing or not. If you really know that skill, you should know more than what I learned in five minutes of searching.
All this applies to your LinkedIn as well, which you should keep up to date, so that if there is a job you want but don't want to spend the time applying, you can just send them your LinkedIn. :)
Edit: Forgot to mention, as pointed out below, that your resume also drives the interview, so while some of what you write won't be read to get the interview, you still want it there as a place to jump off during an interview. Always better if you can drive the conversation towards your most positive qualities, which is easier if they are in your resume and the interviewer asks about them.
> If you do put a "skills cloud" on it, be ready to talk about them all. If someone had a skills cloud I would immediately look for the most esoteric skills and dive deep on it in the interview (after Googling it myself) to see if you were BSing or not. If you really know that skill, you should know more than what I learned in five minutes of searching.
That's super important in my opinion. I try and write as little as possible on my resume because I don't want to get asked about stuff I don't remember. I keep it to 1 page, write as little as possible and hope that people recognize the default LaTeX font and interview me because my super concise CV makes me look interesting/mysterious.
It's worked well enough for me, but it's a small sample size and luck plays a huge role of course.
Couldn't agree more. Not even just in the skills cloud section, don't put anything on your resume that you're not ready to talk about in an interview. It's baffling the amount of candidates that answer questions about their resumes with "Oh it was so long ago I don't remember" or "Oh it was just a quick 2 week R&D spike that was never shipped".
If something was a long time ago, just summarize it and keep it short and sweet. Nobody needs to read 8 bullet points on an internship you had 7 gigs ago which has no relevance to the job you're applying for. Contractors are particularly bad offenders here in my experience. No hiring manager will read through a 13 page resume for somebody with 6 years experience. As the TFA mentions, use that valuable space to highlight more recent, relevant experience and put your best foot forward. Everything else is just noise.
> Nobody needs to read 8 bullet points on an internship you had 7 gigs ago which has no relevance to the job you're applying for. Contractors are particularly bad offenders here in my experience. No hiring manager will read through a 13 page resume for somebody with 6 years experience.
The first bullet point for each one of those is:
* Followed the Software Development Lifecycle
The second bullet point is:
* Attended all required meetings and ceremonies for agile scrum
At the end of each contract is two lines of technologies used in the environment (though not necessarily by the candidate). For example, kuberentes will certainly be on that list. When asked about helm or kustomize or kubectl: "Oh, the build put an image out on docker hub and then the operations team did all the work to deploy it."
Maybe I should reduce some of my earlier entries. I've still got my entire work history on my CV. I worked on a specific CMS from 2004-2008, and I still get asked for gigs related to that CMS (even if the version I worked on is nothing like the current version). I worked on a PHP problem for 3 days once, and put it in mostly as an example that I can quickly adapt to new languages, but some people actually want to hire me for a pure PHP project.
The "this is everything that I've worked on, if this interests you, contact me" is different than a "this is the information relevant to the job that I am applying for."
If you've got a CV hosted somewhere with CMS and you still do CMS stuff and want to get hired to do CMS stuff... leave it on there. If you don't want to do CMS stuff, take it off.
If you are applying to a job that isn't doing CMS stuff, on your resume that you're sending to them don't have more than a single bullet point for that old job about CMS duties.
>Created a new CMS for the company in Python that resulted in an ~70% reduction in website update times, from 1 hour to 18 minutes
Personally, I don't put too much emphasis on these numbers because most of them are probably BS. Don't get me wrong, it's still probably in a candidate's best interest to quantify their accomplishments since it's recommended everywhere but don't over do it.
They are absolutely BS because 99% of programming is unquantifiable. There are too many variables. I added 5 features this quarter and sales went up 5%. Is it because of the features, or better sales techniques, or dumb luck?
"Redesigned the web pages and user satisfaction went up 10%" - but also you hired 5 more customer support agents and a backend engineer improved the slow pages by 30%.
"Created a new CMS in python (Based on the old CMS) (With a team of 2 others and one guru who did the design but I wrote his code) resulting in 70% reduction in update times (after we ran it in a cluster with twice the resources but I never could understand clustering so guess it was my coding)" "And didn't have time to write tests, and that project was canned because it took too long actually"
As engineers we're measuring everything, all the time right? The point is 'wrote a web api' is worse than saying 'wrote a web api that handled 1M tx/hour' or some such. Even if the number in this case was exaggerated, it stands out and we have something to discuss in the interview phase.
And if the software you write works with money at all, put the amounts in there. Moving around large amounts of money shows trust from your existing company, and attention to detail.
> As engineers we're measuring everything, all the time right?
Is this mostly a joke? I've written plenty of APIs, but I have never load-tested them in isolation, never had to respond to underperforming latency or throughput metrics, or even face any feedback on software performance. In most cases, I don't know who uses the code I wrote, and no metrics from them ever make it back to me personally. For exactly 95.2% of what I've delivered, I couldn't tell you that I improved Foo by Bar units even if you held a gun to my head.
This is after years of delivering LOB software to clients in banking, manufacturing, and oil & gas industries.
I think it depends on work culture. We recently merged with an american corporate and their engineers are obsessed with measuring, pilots, ab testing, RFCs etc. It's so slow to work with them even on the smallest features. Poor 10% of users who miss out on awesome features for 4 months because we "need" a control group.
I think that the point of the parent poster is that often even when the work culture is obsessed with measuring, the people doing the A/B testing and careful study of the benefit to the company are quite separate from the people implementing the change; the information will be used in some decisions and flow to various layers of management, but the developer who built that feature won't necessarily even get a message when it eventually got chosen for widespread deployment or got abandoned after 4 months of being shown to a control group, much less getting the data on what the estimates of financial impact showed.
I'm not so sure about this. I support things and I've supported them over absurd growth periods for years. I've lost track of how many zeros are on the number of things per thing; it doesn't matter.
The process is: You're in charge of a thing, it grows, it breaks, you fix it, it grows, it breaks, you refactor it, it grows, it breaks, you fix it, it grows you replace it and shard it into N things, they grow, they break, etc. The metrics matter, but after a while it's just bigger and bigger but gotta work, so you just make it work.
Oh -- obviously I'm not an engineer -- I don't wear a striped hat and drive a train or sign blue prints.
They might be, but they are a good jumping off point for a discussion during an interview. But also if you say something interesting, it will pique my interest enough that I at least want to talk to you about it in an interview.
Was going to say this. You need your resume to cover both types of people who will be looking at it. HR/Managers for initial screening and then developers for the real interview. For a startup where I know the dev or founder are seeing my resume right away, I wouldn't include those types of quantifications. If I'm applying at ${bigcorp} then it helps get you through round 1.
The value is as a hook in a conversation. e.g. if you have:
- moved from Kafka to Flume
- installed Kubernetes and Dockerized our code
- binary serialized our data
Then this is going to happen:
1. I will assume you don't care about the outcomes of what you do, only the task
2. I will assume you don't know how to communicate why something matters
3. I am going to have to pick at random and hope it's interesting
On the other hand, if each one has the outcomes listed, not only is it clear that you know why, but perhaps more importantly, it is a conversation hook that I can use to enter the discussion. Well, why was it important that the size of the data be small? Couldn't you just zstd your JSON instead of binary serializing some processed version? etc. etc. and then you get to show off why and what that thing you made does and I get to enjoy that and we're both happy.
Most developers don't have agency to choose what they work on within a company. Expecting the developer to have any influence on the outcome of what they produce other than the implementation quality shows a lack of understanding in how actual software development works.
And to be fair to you, almost all management two steps removed from actual coding does not understand how actual software development works. If you are interviewing a PM you should care about the outcome, for engineers focus on quality, timeliness and skill.
Have you considered... Asking? Asking why you are doing something? All of these changes are going to have a purpose behind them, and at least in these examples those reasons are likely to be things a dev is in a position to metric the results of themselves. How much throughput did you add by switching to Flume? How much did you reduce bandwidth with that binary format? Even if you don't have access to the production metrics (and most places you will) you could estimate based on synthetic data.
Even for product work I've yet to meet the product person who isn't eager to talk about how a new feature was received when a dev asks.
Does your company put you head to head with another developer to see who can develop the same feature the fastest?
Or maybe you secretly keep tabs on all of your teammates and their delivery speed, so that you can calculate how much faster than your teammates you are at delivering and how many fewer bugs you ship?
As a manager, that's half true. We have business needs, but I am hiring for the ability to think past "what is being asked of me" and into "What do we really need, and how can we deliver it?"
That isn't rewarded in all jobs, mind you, but it is something to look for when you have a choice.
I've been a software engineer at a few highly regarded companies for a decade now, at none of them did I have the ability to make large product or design decisions as a software engineer. I was able to suggest things, I was able to call out issues in the design and I was able to propose ideas but I was never able to unilaterally make any decisions and a lot of the time any ideas I had were put on the backlog because the company was in focus mode on one specific goal (and I'm not criticizing this idea of having focus).
So my point is, if leadership and product are bad and ask engineers to produce turds. The engineers don't really have control over the fact that they are producing turds but they have control over the quality, how buggy, and the shinyness of the turds.
There's three questions for every product - "Why?", "What?" and "How?"
> I've been a software engineer at a few highly regarded companies for a decade now, at none of them did I have the ability to make large product or design decisions as a software engineer.
IME, even the highest engineer at the company has little to no ability to make even small product design decisions.
I'm not saying whether I think it's a good thing or a bad thing, but the truth is there's a role at every organisation who's job it is to decide what the product should look like and what it should do. That role decides all the "what" questions.
Engineering is all about "How?"
Even the product design role doesn't have all the power - the "Why?" is decided by someone else.
Key point: quantify the shinyness of the turds, so that HR screen likes the look of the CV, and be prepared to talk about turd shinyness and why it would matter.
How about we start with you not making 2 massive assumptions off of a sentence in a document that summarizes anywhere from 1-30+ years of someone's work.
Then how about we move away from you thinking that interviews are for your entertainment and the interviewee is a circus animal where 'you get to enjoy that' as they 'show off'.
This is a weirdly aggressive response to what is literally the core purpose of collecting resumes. Like it or not a hiring manager likely has hundreds of resumes they are looking at and nowhere near enough time to review them all. Making judgement calls on limited information is necessary. Maybe the hypothetical engineer with this resume does understand the goals and outcomes of these tasks, but they have failed to demonstrate it in this resume. Given another engineer who gives me details about the business need they were meeting and the outcome, why would I interview the first instead of the second?
The core purpose of collecting resumes is gauging the likelihood that a candidate may have the skillsets to align with what the job is, and then bringing them further into the process to dive deeper into their experiences. It is not to make wild assumptions about how someone is probably incompetent because they put put 'GIT' or 'JAVA' or omitted the business need and outcome on every project they have worked on(good luck getting all that on one page). It is almost a certainty that someone making snap judgements on what capitalization was used for a specific tech is also making those judgements on things like nationality, origin, sex, etc...
To be honest, why do you even care what the business need was? Maybe it is classified? Maybe it just landed on their desk and they crushed it? You honestly want to read about the business needs of things that are completely irrelevant to you and in the past? Go download a white paper.
Your whole paragraph is a juxtaposition. You are saying that hiring managers are strapped for time to thoroughly review all the resumes(I agree) but then say that a resume should have the business needs and outcomes of any number of projects that a dev has worked on in their career(and we haven't even touched on what they actually DID for those projects).
The core purpose of collecting resumes is to determine which candidates are most worth bringing in for an interview. A candidate who understands the business purpose of what they are doing and is capable of calibrating their task to best meet that need and gauging the outcomes of how well it did so is infinitely more valuable than one who just blindly does whatever task with no knowledge or understanding. Skillsets are more than just a list of technologies you've worked with.
"Deployed our core application to Kubernetes": Cool you once saw a Dockerfile and Kubernetes YAML.Like every single other applicant. I don't even know from this if you have a basic understanding of Kubernetes. "Deployed our application to Kubernetes for better server utilization and resiliency increasing our uptime by 20% while reducing cutting our server costs by 10%". This person at minimum has some idea of how to configure Kubernetes for application resiliency, knows how to measure and maximize hardware utilization, knows how to measure and minimize downtime, and probably knows enough about Kubernetes to provide advice about when to use it and when not to. Maybe the first person does too, but they did nothing to show it.
> It is not to make wild assumptions about how someone is probably incompetent because they put put 'GIT' or 'JAVA'
No one said wildly incompetent.
> every project they have worked on(good luck getting all that on one page)
Don't put every project on your resume. Pick the most interesting ones for the job your applying for. If you are sufficiently senior that this still doesn't fit one one page, use two.
> It is almost a certainty that someone making snap judgements on what capitalization was used for a specific tech is also making those judgements on things like nationality, origin, sex, etc...
No.
> To be honest, why do you even care what the business need was?
Most hiring managers. Someone who understands WHY they are doing something will make better choices than someone who sees "Move our application to Kubernetes" in the backlog, grabs a yaml template off the internet and calls it day.
> Maybe it is classified?
Government resumes tend to be EVEN MORE outcome focused than private industry. You can write "increased pipeline throughput by 50%" without writing the national secrets in that pipeline.
> Maybe it just landed on their desk and they crushed it?
How can they possibly know they crushed it without understanding why they were doing it in the first place, or anything about what happened after they released it?
> You honestly want to read about the business needs of things that are completely irrelevant to you and in the past? Go download a white paper.
A white paper tells me nothing about the candidate.
> Your whole paragraph is a juxtaposition. You are saying that hiring managers are strapped for time to thoroughly review all the resumes(I agree) but then say that a resume should have the business needs and outcomes of any number of projects that a dev has worked on in their career(and we haven't even touched on what they actually DID for those projects).
You know what takes longer than reading a resume? Interviewing someone. Your right. Resumes are going to get a skim first. Only the most relevant ones are going to actually get read thoroughly. This is exactly why you want numbers and metrics as much as possible. Numbers catch the eye far more easily than sentences. If I see "saved $100,000" on a page, that's going to get caught on my first skim. It's an effective hook. I want to know more. Without it I've just got "Kubernetes, C#, Javascript", I might as well have a computer read the resume and build me a checklist.
I appreciate the thorough response. I guess we disagree about the purpose of a resume, I just think it is wrong to assess someone's worth off a one-pager(two pager max). There is obviously a lot of grey area between what a perfect resume and an atrocious one looks like, and that will vary even between each job application. Matching the expectations of candidates with those of the hiring managers is extremely difficult, dating can be thought of as a similar problem that has not found a great solution(and in no way am I saying dating is like interviewing).
For classification I meant that generally a company you have worked at will not be keen on you going around talking about their internal business needs, especially if it is close to the product.
Lastly, as some have mentioned, statements like 'increased this by X' are usually either fudged, or marginally related to what the candidate worked on, conflating factors being in the mix.
Isn't it preferable to you that I continue to be like this so overtly? Since you dislike how I am and you may well dislike working with me, you can instantly reject me and my org. This is good for both of us.
I don't think people are "circus animals". But I do like to work with people who have done things that they are proud of and who do like talking about those things. And it is important to me that we both enjoy the conversation, yes.
I agree. I know it's the conventional wisdom to phrase things in that way. Having hired a lot of people and read a lot of resumes I personally either ignore these statements or have a chuckle over them when they are silly. In no world would someone capturing the "impact" of what they did make me more likely to hire them.
I'd actually say I'm much more interested in understanding what concretely a person actually did, so I know what kind of experience and capabilities they have, vs what it led to, which has so many external variables and is probably mostly BS anyway.
Your resume should talk about results. Don't say "Created a new CMS for the company". Say "Created a new CMS for the company in Python that resulted in an ~70% reduction in website update times, from 1 hour to 18 minutes."
My take: I’m actually not convinced anyone cares too much about those numbers in a resume. Great topics to probe in an interview, but not much of a signal on a resume. Reason being: they’re easy to fluff and are almost always inflated bs.
> Reason being: they’re easy to fluff and are almost always inflated bs.
Not only that, but how would engineers, for example, know how much money was saved or earned from blah feature or project unless that was explicitly shared with them? Time saved or usage can usually be measured by the engineer, but money is a lot trickier.
Like I'm able to say a speech application I made was used in over a million calls, because I looked at the database and saw that many call records in there. And I'm able to say that I set up an one-click 30 minute devops process for deployment that was previously done over the span of 4-8 hours manually with multiple engineers onhand in case things went wrong (and they often did due to user error), because I was physically present during those manual processes and could directly compare and contrast the time difference.
But I can't say it "saved the company X million dollars" or whatever because I wasn't in management and didn't have those figures shared with me.
At least not honestly. I could make some bullshit up (I don't, but I could), like you said, and how are you going to verify it? Do you think a past employer will confirm or deny those figures if you call? You'd be lucky to get much more than confirmation that I worked for them and what dates at this point, thanks to all the liability around it. Also there's no guarantee that they know (or remember offhand) themselves, maybe they weren't on that project.
> Like I'm able to say a speech application I made was used in over a million calls, because I looked at the database and saw that many call records in there. And I'm able to say that I set up an one-click 30 minute devops process for deployment that was previously done over the span of 4-8 hours manually with multiple engineers onhand in case things went wrong (and they often did due to user error), because I was physically present during those manual processes and could directly compare and contrast the time difference.
These are both perfect for a resume. They are quantified and measurable and would be interesting to talk about in an interview. For example, I'd probably ask you what tools you used to set up your 30 minute deployment process and what they were using before and how you managed such a huge gain. I would ask you how you built your voice application to scale to a million calls.
These are both great for a resume. They don't all have to involve money.
Yeah, they are both bullet points on my resume, actually. But there are several jobs where I can't quite say this.
Like I worked on several games that didn't do well in the market (for various non-technical reasons), so I know I can't brag about saving money or time or usage for the company, but I learned a lot of skills by being on those projects, so I benefitted personally in ways that could help the prospective company out.
In fact I might have gotten more skills from those projects than that speech application, for example, despite that one being used a ton.
So I don't really have anything better I can say there than "did this this and this on the project, lead X number of people, etc", which are basically the 'responsible for...' bullets that everyone advises against including on a resume.
Also in case you're curious, I set up the process by using Octopus Deploy and several custom Powershell scripts after an audit of their existing processes and all the various information for all the servers, firewall settings, windows services, database snapshots and schema migrations, etc (there was a lot, each major system had like 40+ steps to it by the time they were done) etc.
Before the engineering director of the department would lock himself in his office and execute .BAT scripts one by one from a terminal and copy files and other things manually, while everyone else chilled in the main office, waiting (usually around 4-5 people). If anything ever went wrong, and usually it did, it would take several engineers to investigate and help revert things if necessary.
It was a mess. They knew it was a bad process, and had previously had another developer start investigating how to make things better using Octopus Deploy, and he gave up and quit the company and KT'd to me that it was impossible, no one was cooperating with him, he couldn't get the information needed, and well... I didn't have his experience and think he just didn't want to do it.
I had everything working for several processes (and we set up more and more over time after we had things working) in about the same time as he spent accomplishing very little (I started with his setup), and I didn't know anything about Octopus Deploy and barely anything about DevOps beforehand.
Great anecdote that, a real classic - previous experienced engineer couldn't get the cooperation and information he knew he needed to do it properly so barely started. Newer inexperienced engineer wasn't quite sure what was needed but built something to get several processes working and used that to convince everyone to provide the support to complete it.
I've closed $100k worth of consulting by opening with "My name is Zwayhowder and I've spent years making every cloud transformation mistake possible so you don't have to".
I'm not sure why you'd be willing to work on such a project but then be concerned about putting it on a CV. Assuming something I don't understand, you could talk about the impact it had on your employer without going into details of what it allowed them to do.
Woah there Betsy, I wasn't accusing anyone of anything, I literally didn't understand the comment as well as you apparently did.
So the second part of my comment stands. In the case of such a civil engineer, I'd focus on "Designed factory and rolled out process allowing organisation to achieve strategic objective to increase rate of baking ceramic products by 25%".
You can come up with decent figures. And i think it is worth it not just for a resume but monthly lookbacks
So multiple engineers on hand for 8 hours - let's say 5 engineers. That's 5 person days. A deployment a month (cos anything that painful gets done less often) gives 60 person days, at something like 2x daily salary of engineer (assume 500pd for easy maths) and you saved company 60,000 usd a year whilst increasing reliablity and speed.
Getting the numbers in the first place is one challenge, but if you do metrics and measurement, you get hundreds of numbers and improvements, different each week. It's not like you're working on a single goal and target, and then wave goodbye when you're done. Who remembers all those numbers and improvements? What did they come down to cumulatively over the years? No one can know.
But crucially, one also works in teams. There's no way one person can claim credit on one measured improvement unless it's something very trivial and isolated, a single-person project.
There are many people saying that they read negative things between the lines about people who don't put quantifiable metrics to their CV items. I don't mind missing metrics, it's much better than having some fudged up bullshit metrics in there.
The CV is there to establish trust between two people who don't know each other. Don't fill it up with stuff which shines with fabrication and misrepresentation.
I recently saw a CV with a very specific claim about developer efficiency improvements brought about by their introduction of a design system to the product.
I was instantly put off - because while it might be true there’s just way too many variables to claim a 68% improvement was down to your design system.
I find this very difficult because I think all great results are due to team work, and a bit of luck. Like the software we specialized on happened to become a very fast growing market. And we captured a big chunk of that marked with only a team of 5 people, but we could probably not have done it without each other. All our work was very intertwined.
> I find this very difficult because I think all great results are due to team work, and a bit of luck.
Correct, but North American hiring culture expects you to sell yourself, in the STAR format. Situation (Your job) -> Task (Your project) -> Action (Your role) -> Result (Numbers go up). So, if you want a job, you have to play the game.
You obviously didn't move mountains all by yourself - you were an employee, not a solo self-contained business unit. If the hiring manager wants more details about what exactly your role was in moving the mountain, they can ask in the interview. Be honest, but don't sell yourself short.
I've heard this sort of meme description style proselytized over and over, and have tried it, but I can't think of a single time I've ever genuinely been in a position in which I had literally any control over either the decision that was made to do it, or insight into the outcome if it existed, and probably wouldn't believe anyone who told me differently. These stories seem to me like just being in a unique fantasy position in some startup where you happen to be given more autonomy and individually refactor some core thing end-to-end with analysis that ties your lucky results directly to sales.
A much more real and honest description would simply be "Upgraded 20 year old wordpress and ensured no data loss or breaking changes took place, which helped improve the editorial experience for our writers"
Because the pool of applicants is so vast, you are far more likely to get passed over because there are so many other candidates to interview rather than being passed over because you don't hit the lowest bar acceptable for the interview.
I’ve been hiring for 15 years maybe and always read resumes. The skills bubble is critical for me personally - they need to have some stuff in there that matches what tech we use. I also don’t look at LinkedIn - doesn’t add anything to me not already on the resume.
You must not get a lot of applicants if you have time to read all the applications. But there’s no way I’m reading 100 resumes for one job. I’m skimming them at best.
And if you’re not looking at LinkedIn in 2023 you’re probably missing out. My LinkedIn has far more detail than my resume because it’s not page limited and a lot easier for the reader to search and zero in on what they want.
jedberg, I know you are a smart guy, so I wonder if you can explain this thing that has always mystified me.
The difference between a good hire and a bad hire is really big, right? So why would you be like, there's no way I am reading 100 resumes?
Suppose it takes you or someone like you (i.e. maybe you can get in a room and do all the resumes with a few people on the team in an hour or two) on average 10 minutes to reasonably critically evaluate a resume, maybe follow and read any interesting links on it. Then the pile of 100 resumes takes about 15 hours to evaluate. Suppose that the person you hire has an expected tenure of 2 years. That means they will be working for about 4000 hours. 15 hours represents less than 0.5% of their productivity. So can it really be that critically evaluating the resumes doesn't even give you a hire that is 0.5% better in expectation? I would have thought it was like, 50% better, if the resumes are your primary screening tool to decide who to bring in for an interview!
I have been working for like 15 years, and all my coworkers are always just like you -- they don't read the whole resume, they don't go read the candidate's code, they don't read the candidate's blog, etc. But it seems self-evident to me that spending a few hours to try to hire better coworkers has a huge ROI for the team. The time I spend basically always finds stuff out about the candidates that my coworkers find interesting and important, and often prompts further interesting information in the interview.
I always just figure that the explanation is: my coworkers don't enjoy doing hiring stuff, and nobody is making them do it, therefore they don't. Do you think differently?
I like this comment. At the end you wrote: <<my coworkers don't enjoy doing hiring stuff>> Can you clarify something for me? Are you a hiring manager? If yes, the "ROI" comment makes a lot of sense. And do "co-workers" mean other hiring managers... or non-managers? As a non-manager, putting effort into hiring doesn't have good ROI for me personally.
My CV and LinkedIn profile had links to open source projects for more than 10 years. I am someone who interviews a lot -- I like to move from company to company for diverse experience. Only once in ten years has anyone asked about my open source work. They are generalist libraries (Java and Python) that I "import" at every new job. They give me a real edge over my teammates. My point: Interviewing seems like a total gamble. My best strategy is to figure out what the hiring manager wants and pretend to be that person. In most teams, the hiring manager calls the shots nearly 100%. If they like you, you will be hired. I've had crap tech interviews with the "teammates" and still gotten offers because I transformed (during the interview!) into exactly what the hiring manager wanted. Bizarre.
An alternative explanation: even if they did spend more time on the resumes they wouldn't be selecting better, because they don't know what to look for
Ah, the sheer ego size of hiring managers who go around saying stuff like "understanding how candidates think" or "assessing cultural fit"
The brightest minds of psychology - with far, far more resources and time - can't replicate those results if they run the tests this Monday or this Wednesday... and then comes the hiring manager and they say they can do it with a CV, some technical assignment, and an hour of chat. After having spent less time properly studying the topic than highschoolers spend on their homework each week
It isn't "critically evaluate" but rather "in this stack of 100 resumes, find four that stand out sufficiently to bring in for interviews."
The "stand out significantly" check doesn't take 10 minutes per resume.
Additionally, doing nothing but reading 100 resumes (no meetings, no development work, no trouble shooting issues, nothing else) is soul crushing.
Going to blogs some HR departments will frown upon as it may introduce biases into the evaluation process that they'll get sued over. "The candidate recently wrote about her experience with pregnancy on her blog that the interviewer had looked at" - and you've got a discrimination suit on your hands.
> It isn't "critically evaluate" but rather "in this stack of 100 resumes, find four that stand out sufficiently to bring in for interviews." The "stand out significantly" check doesn't take 10 minutes per resume.
So it sounds like you're saying that you can do a really fast check with ~no false negatives. That is, you won't skip over the best candidates and fail to interview them.
But are you sure that's really true? Often if you can find any code a candidate wrote, it quickly stands out as "exceptionally bad" (like, you can see bugs at a glance, the formatting is a mess, stuff is copied and pasted everywhere, the project isn't what was advertised) or "exceptionally good" (like, they are making PRs fixing tricky issues with really thoughtful writing and immaculate appearing code.)
There's almost literally nothing on a resume that can stand out that much other than, like, "ICPC winner" or "lead engineer on Chrome" or "famous celebrity I know by name". At first glance, the resume of the guy with the exceptional code will just look like "went to some school, worked at a few companies where they did a few bullet points." How are you so sure you will decide to interview him if you just skim the resumes very fast? What if you have four candidates who went to better schools and companies, and you interview them instead?
I get the "soul crushing" complaint. If I were king I would try to split the labor among engineers as much as possible to mitigate that. Or hire more slowly.
If you're selecting 10% or 5% or 1% that are interesting to bring into an interview, what is a false negative?
I'm not going to claim that the ones selected are the best or that I'm missing ones that I would give a thumbs up to if I had the time to interview every candidate.
Instead I'm looking for "are they applying to this job? Do they have some of the skills that the job is looking for and have claimed to use those particular skills in a past job or project? Do they have a history that demonstrates that they're likely to stay around after becoming a positive contributor?"
I've got an excel spreadsheet where I am to give a 1 to 5 score for each of the skills (1 is "no claim of the skill being used" to 5 of "specifically claimed to use the skill in a current project or role"). The next column is "average tenure in months" and lastly there is a column for red flags or green flags. You will note that nothing in there asks about past company or school. Considering schools can get into trouble for discrimination if the person went overseas or to a HBCU. If you want to call out something (the candidate spelled JavaScript as 'java script', "JavaScript" and "java Script" (with java lower case and bold)) then that can be put in the red flags.
From that list (and multiple people all fill that out for all resumes), HR then selects the ones to move to the next round of interviews.
If I am looking for code the candidate wrote that can cause problems with discrimination suits at this level of the interview. If we look for any blog posts on them or social media they've written, we open ourselves up to lawsuits and claims of biased hiring.
When it comes to code, we have a take home test that is given to those who are selected. Having the take home up front has been met with "but you aren't paying me to do this" or other forms of refusal to do it... and I'm not going to go through and review 100 submissions - I don't have the time for that.
For that code part of the interview, again, there is a rubric that is set down such that anyone reviewing the code should come to the same conclusion.
And while it seems a bit impersonal, the key is that the same criteria is applied to everyone and if someone else was to watch a recording of the interview (this isn't done, but its the hypothetical goal) that they would come to the same conclusions based on that same rubric for evaluating the candidate.
It's a matter of ROI. The initial skim is just the sorting phase. And sure, I may miss a great candidate, but that's the price one pays. It's much better to get a false negative than a false positive.
A false negative costs me very little. A false positive is a massive burden. I'm optimizing to avoid false positives.
Also to be clear, I will read the full resume of a candidate I'm interviewing. And their blog and GitHub and whatever else they tell me about. And I'll take notes so I can ask them about interesting things I find.
The skimming is just for the initial "should we consider this person for an interview" screen.
I think I’ve got over a hundred to go over for one of my positions right now. I take a half day a couple times a week to go over them. I just consider it a priority and make time for it. Training and then firing someone is such a massive waste.
if you’re hiring senior and above the number of radically different technologies is extremely small.
what I mean is, a good Java dev will be able to code in Go in under a month.
A developer who knows MySQL will learn postgresql just fine.
I don’t tend to put much weight into specific technologies, more I try to figure out how exposed you've been to paradigms that are important (OOP, RDBMS).
> Your resume should talk about results. Don't say "Created a new CMS for the company". Say "Created a new CMS for the company in Python that resulted in an ~70% reduction in website update times, from 1 hour to 18 minutes."
You do exactly the thing the author discusses, and without addressing any of the author's (very valid, IMO) criticism of the problems with trying to do this.
> If you do put a "skills cloud" on it, be ready to talk about them all.
Go a step further.
Only put items in your “skills” cloud that WANT to be asked about and can deep dive. These skills should be things you hope the interviewer will ask you about.
If you can spend the whole interview talking about points in your skills cloud then it should be a slam dunk.
meh. I think that's bad advice in 2023 (even in 2018), as a moderate volume resume reviewer with lots of hiring experience -- resulting in 25% fewer remorseful hires.
Well, not quantifiable results as you describe anyway. If you are a VP level with a budget, then ok. Or a very low level IT person with metrics to meet, then ok. But as an average SWE, no one is believing these numbers. Even when true, it feels like a force fit to fit a misguided expectation. Unless you specifically went into the project to improve efficiency, and YOU were the one that identified the problem and INITIATED the project SPECIFICALLY to grind out more widgets, then I'd find some other aspect to crow about.
In the CMS case, then sure if you identified the CMS as a real issue, worth fixing, and led the project, and can describe the size of the team (could be just yourself) to tackle it, and are taking responsibility including if it failed, then ok. If you're just assigned the task and it happens to be more efficient, blah. Maybe the starting point was exceptionally bad, n^2 vs log(n) due to the first version being a hack. This 70% "result" tells me nothing useful, honestly, except that you are a slave to bad, one-size-fits-all, resume guidance.
It tells you that the candidate at least understood the business impact of what they were doing, and it gives you something to talk about in the interview. "How was that issue identified? Did you find it or were you assigned the task?" "How did you achieve those results? What technical decisions did you make to get there?". "Were you the team lead or did you work under another team lead?".
So many good questions to spawn from that one line.
Those lines of questioning are open always, regardless of what’s written in the resume. You have precious few inches in the resume, they should be reserved to highlight your own accomplishments, the aspects of any project that you actually drove. When I see these kind of metrics on every other bullet (for L5 and below) it tells me a lot about the candidate and not that they have an appreciation for the business impact of their technical skills.
For the skills, I feel for every interviewer that grills you about them there are five that would have never bothered to interview you if you hadn't listed them. If the job posting has Kubernetes, data science, Angular, React, Ember, Java, linux, apache, python, postgres... for a junior dev role, I am damn sure going to list them even if I only have a general idea about them. I highly doubt they are going to start grilling me on the inner workings of postgres, they just want to know I have worked with an sql database.
Most of the time it feels like a performance from both sides. We only want to hire the best! We need all 30 of these skills! Oh yes sir I am the best I absolutely know all those things!
> If you do put a "skills cloud" on it, be ready to talk about them all. If someone had a skills cloud I would immediately look for the most esoteric skills and dive deep on it in the interview (after Googling it myself) to see if you were BSing or not. If you really know that skill, you should know more than what I learned in five minutes of searching.
I was doing the same when I was an inexperienced interviewer, but then I realized this meant I was passing up on highly competent software engineers because they were not highly competent resume writers.
Seems like you're looking for great resume writers. I would reconsider if I were you.
No I'm looking for bullshitters. People who are willing to lie on their resume and won't admit when they get caught. If they say "I just put that there to get past the filters" then great, we can move on. If they try to BS their way through an answer, then what else will they try to BS through?
I want someone who will just admit when they don't know something. It's a sign of great intelligence.
I have C# from a school module from 7 years ago on my resume. I wouldn't be able to answer many interview questions about it but I would be read to work in C# after a few hours of brushing up my skills.
I also have 5 years of software engineering in a FAANG working mostly on Java.
But I guess you wouldn't hire me then.
It's fair to ask what level of proficiency the person has and skip the questions you were planning to ask if they answer like me, but it would be stupid to actively try to trap people.
I'm not trying to trap anyone. I would ask you about C#, you'd say "that was seven years ago, I don't remember the details" and we'd move on. I'm looking for someone who starts making up things about C# assuming that's what I want to hear.
That's the kind of person I'm trying to avoid. Someone who isn't honest about their skills.
On top of results(or even rather than), it can be more useful to talk about scale. Often times the end result is not really in your control. One could say 'deployed a pilot project to a group of 10,000 users to see the effect of X on Y' or 'worked on a project that had a throughput of 50k transactions per hour', etc...
I can’t recall the last time anyone asked me about shit on my resume - tbh.
It’s all kinda pointless. People do leetcode, system design, and then a (series of) manager interview(s). They don’t often ask me much about stuff directly from my resume - especially for technologies or skill cloud related shit.
My thought here is to pay reviewers to read resumes and use eye tracking to train a diffusion model so you can issue resume prompts that will produce the most eye-catching resumes.
"resume for a 20-something who travels abroad and knows the rust"
I know that most people don’t read resumes because I’m always asked a lot of questions that would have been answered if the interviewer had read my resume.
But when I’ve been on the opposite side of the table, I’ve always read every word of the resumes of the candidates. I think the hiring process would go better if more people did this.
I read the entire resume before an interview. I skim them when I'm deciding if I should offer one or not. Also I will ask about things that are in your resume because I want more details.
> We read every resume. This means that a lot of tricks you’ve read about how to beat automated screening such as include certain phrases of job descriptions in your resume, repeat “hot” keywords, fill your resumes up with random metrics, etc. not only doesn’t work on us, but also hurts your chances.
It seems unfair to penalize people for playing the game and attempting to maximize their chances for success. It forces people to make a choice where they're effectively rolling the dice as to what the best course of action is -- either they optimize for the reality that resumes are largely computer screened, or they optimize for humans hoping that it's not. I don't think you should blame people for optimizing for what is likely the most common scenario.
>It seems unfair to penalize people for playing the game and attempting to maximize their chances for success. It forces people to make a choice where they're effectively rolling the dice as to what the best course of action is -- either they optimize for the reality that resumes are largely computer screened, or they optimize for humans hoping that it's not. I don't think you should blame people for optimizing for what is likely the most common scenario.
At first, I disagreed with you because I assumed if Chip took the time to write this post, she must be linking it or at least making it clear from the job postings. I just checked the job postings[0, 1], and they never tell the candidate that a co-founder reads every application personally nor give any indication that they're handling applications with more care than the average company (and the average company treats candidates like garbage).
So, I agree. If you don't tell candidates that you're unique in the way that you process applications, you can't expect candidates to approach you differently than they approach most employers, who reward keyword stuffing.
I have a similar hiring process to the author, but I spell out in my job posting that I, the founder, am reading every application personally.[2]
> I have a similar hiring process to the author, but I spell out in my job posting that I, the founder, am reading every application personally.
I mean, the real question is if the job candidate will actually believe it.
From personal experience, I put my website's URL into my CVs. When you bother to visit the website, I have a little shibboleth there that says to mention a certain thing in the job interview and I'll give you $50. I've only ever had one person ever mention that in ~20 years of the shibboleth being there, and I gave them the $50. I used to put the shibboleth in the CV, but it felt a bit crass after a while.
Also, great note there at the end of the application. I would believe you in this case.
I'm pretty sure I would get into a significant amount of trouble with my company's people team if I accepted $50 from a candidate. I honestly would consider the presence of this offer on your website as a red flag.
Yeah, if I really wanted to know if someone had clicked through to my website, maybe I'd put something like "Ask me about the time $THING" But, really, an interview doesn't seem like the time to play cutesy games.
You don't have to accept it, you just have to mention it.
OTOH, I'm pretty sure most companies have rules against hiring candidates who offer money to the interviewer (even if the interviewer declines, the candidate is rejected anyway).
I tried this in the past, it never worked. Resume spam is waaay better. That said it still is bad. In my whole life I got to technical interview stage only 8 times, and 2 of these were referrals...
No, it means they want to work but definitionally when you are sending out ad many applications as you can you stop caring about the individual qualities of a company - that comes later, when it becomes relevant.
As far as I can tell, the company in question (Claypot) has <10 employees. How many people do you think have even heard of them, let alone want to specifically work for them? Approximately all of their applicants are going to fall into the other bucket.
YES! I thought, well say "yes" to my list of technologies I'm familiar with. If you want to hear more about how I acquired those skills, you could ask...like with a process of engaging with applicants. Let's call it an interview.
My view of this: you're playing the wrong game. "Know your audience."
If you're applying to megacorps, fine, optimize for searching in a resume database. An early/mid-stage startup doesn't want to select for people who have megacorp offers; that's a waste of time.
Once upon a time I knew of a college job board that required resumes to be uploaded in HTML. I heard of multiple startups that would simply View Source and check if the resume's HTML appeared handwritten or if it contained the tell-tale meta tags set by Microsoft Word when it exports HTML. (Said job board was replaced by a new system that uses PDFs, sadly.)
Was it explicitly said that the HTML needs to be handwritten?
Because otherwise, I don’t really see the point of that approach. People using whatever tools allow them to produce an adequate result in an efficient manner, that’s a good thing. For some people, that tool might be Microsoft Word.
If the specification said “use HTML format” and the application was indeed in HTML, I don’t see a problem.
I was first introduced to HTML in high school when I didn’t have a Microsoft Office license. That meant that I actually did the opposite for writing assignments and hand-wrote my HTML document to print from a browser.
Not to take away from your point in any way. This discussion just reminded me of that and I realized the irony.
The lack of specification is likely intentional there - apparently they're not trying to distinguish between people who can or can't follow a spec; but rather they observe that for some people the obvious or default or simply easiest way to get a bunch of text in HTML would be to write it in Word and press 'export', and for other people the obvious or default or simply easiest way for them to do the same would be to write HTML directly. It seems plausible that those are two quite distinct groups of people, and apparently they prefer one over the other.
This seems like a strange asymmetric take. Aren't people who fill their resumes with word soup penalising people who don't play the games and instead fill their resume to actually be read, and convey actual meaningful information and projects to the reader?
The discrimination is already built into the system, so if you have to discriminate, if i was hiring, i'd want to do so against the game players. At least in high skill data science-esque jobs, the ability to hire for people who aren't playing games and actually doing the task seems like a plus. and additionally, if you structure your resume in such a way, you filter for companies in such a way as to avoid the dystopian megacorps and managers who expect you to play games.
that being said, I've yet to figure out a way other than networking or optimisation to reliably get past any institution big enough to have a significant HR presence professionally incapable of judging the things they're notionally hiring for. I've had the experience where I've found HR has culled resumes and chosen which ones go through to the decision maker, which is incredibly frustrating when they're by definition unqualified to be making such decisions.
ps: I will read every resume I see. I despise word-soup/algorithmic/ business catchwords/someone told me to use active language resumes.
Strange, they may have changed their text since you read it, because this is what I see:
> We read every resume. This means that a lot of tricks you’ve read about how to beat automated screening such as include certain phrases of job descriptions in your resume, repeat “hot” keywords, fill your resumes up with random metrics, etc. doesn’t work on us. They can even hurt when you apply to companies like us, because the resume space used for these tricks is the space you aren’t using for things that are relevant to us.
Emphasis mine. They're not penalizing folks for the alphabet soup, but pointing out it's a lost opportunity when you have finite space.
Yes, it looks like they've edited the article within the last three hours. Not sure what else if anything changed, but the original is still up on archive.org
There is no fairness in hiring (nor anywhere else). I once saw a hiring manager pull a resume out of the stack and throw it away because it was printed on cream-colored paper. I glanced at it--it was impressive in general. Certainly a plausible hire at a place like Google.
That's okay. You're not writing a resume to get hired. You're writing a resume to interest the places you'd like to work and repel the places you'd be miserable at.
This is a good point. Unless you are desperate for a job, you can be strategic. You could even list things that are a turn off for you. Companies that bin your CV because of honesty and trying to get a good fit are probably not a good fit.
Unless you are going against an entire culture, for example you want Fridays off but applying to high frequency trading companies.
What game? If I send someone a document, I expect them to read it. If I send them a list of repeated keywords just to rank higher in a dumb algorithm that I'm hoping they use, and it turns out it's a human now staring at a page of repeated words... I don't find it surprising that the human is not impressed.
> It forces people to make a choice where they're effectively rolling the dice as to what the best course of action is
The best course of action is to make good resumes. If the scanner can't pick them out, the company will notice in any spot checks that it spits out only garbage. If you optimize for a computer, computer says yes, then a human opens it to see what your experience is and what to talk about in the (phone) interview, human would still see you're trying to cheat their system (which could be a good thing if you apply for a hacking company, perhaps).
> If the scanner can't pick them out, the company will notice in any spot checks that it spits out only garbage
This is giving the companies a huge amount of credit. The problem isn't that the only spit out garbage, just that they are 'unfairly' rejecting strong resumes.
> include certain phrases of job descriptions in your resume
Especially this one, because I do that for the human reader, not just for the machines.
The point of the resume is to show that you meet the requirements for the job—asking a candidate to rephrase the job requirements in their own words actually obfuscates the parallels between their work history and your requirements, creating more work for everyone involved.
> It seems unfair to penalize people for playing the game and attempting to maximize their chances for success.
If a resume just lists word soup, you’ve really given the reader no choice. What you should be doing (if you want to work somewhere where humans read resumes) is not keyword spamming, but using those key words in sentences that are also meaningful to humans.
Everything is just signal, strong or weak. In my experience, those who are applying to both computer-screened jobs and human-screened jobs are not suitable to work with me.
It's just like if you write that you are an expert at JAVA, GIT, and Python. Java is not an acronym. Neither is git. Is it unfair that I judge someone negatively for this? Perhaps you would consider that so. For me, it's just signal. If I'm wrong repeatedly, I will have a higher hiring cost and someone will beat me in the market. I am making those choices for the business on a hundred different axes constantly. I have no problem trusting my intuition here.
Don't worry, it sounds like you're an absolute nightmare to work with, so I doubt any of the candidates that didn't pass your filter are missing out on anything. Win win!
I, on the other hand, would pass this filter and highly appreciate working with someone who maintains it.
Not spelling it JAVA or GIT is a minor, but important detail in an industry full of acronyms. People who miss out on small details like this are also make massive mistakes elsewhere in their work and tank the productivity and morale of their teams as a result.
The funny thing is that while talking about attention to detail you say things like '...miss out on small details like this are also make massive mistakes...'
Given that this is a forum and low stakes, I just find it rather amusing.
To be fair, misspelling "Java" as "java" or "JAVA" is both a signal about Java knowledge and a signal about understanding what's canonical English usage in the U.S. So it's somewhat biased against non native English speakers.
But at the end of the day, software startups want hackers. And hackers know how to spell Java.
I didn't list "java" as a misspelling. It could theoretically refer to the command line program of the same name that the applicant knows about.
Spelling it JAVA means you are ignoring that it could stand for an acronym. I don't see how that's biased against non-native English speakers; languages other than English have acronyms. I suppose it could perhaps against speakers of languages that don't have the concept of uppercase/lowercase; but then wouldn't you expect speakers of these languages to reproduce the (unfamiliar) name "Java" exactly?
Well, I see it as us not being a match. It is good that those who don't want to work with me have all the information required to do so. I try to be as transparent as possible.
> It forces people to make a choice where they're effectively rolling the dice as to what the best course of action is -- either they optimize for the reality that resumes are largely computer screened, or they optimize for humans hoping that it's not.
You are making that choice, though. Any time you make a resume, you are making choices about the profile of the one reading it.
> I don't think you should blame people for optimizing for what is likely the most common scenario.
Not interviewing a candidate is very different from "blaming".
> It seems unfair to penalize people for playing the game and attempting to maximize their chances for success
If you bring up the topic of attending _college_ on here, there will be at least five people who say "I make a point of never hiring college graduates, because I knew one once who was incompetent". Penalizing people who play the game is something of a sport in nerd circles.
Which means that unless you can get info on what a particular hiring manger's preferences and annoyances are, your chances of surviving a résumé screening are indistinguishable from chance.
Almost every time I'm given advice (by people who should know, by being SHRMs having X years experience as a hiring manager) that isn't taylored to a specific reader, I learn yet another hardline contradiction of somebody else's advice. For example, another commenter here asserted that you should use sentences (to put keywords in perspective/context), which I've heard multiple times, but I have far more often been told to use phrases and keywords because sentences take too long to read. Proponents of each seem to view it as a MUST, and auto-reject anything that looks like the other. This same pattern holds for almost every bit of résumé advice I've ever gotten.
Some people even say to submit multiple different copies with different style variations "so that one might get through, while others say that if they receive more than one for the same role, they discard the candidate.
["Include $this!" | "NO! Never include $that!]
There is no Win.
Only "do a thing, until somebody tells you to do a different thing".
> Which means that unless you can get info on what a particular hiring manger's preferences and annoyances are, your chances of surviving a résumé screening are indistinguishable from chance.
Often you can figure that out from the job description.
Rarely. There's almost never a "Don't format/say like X; do it like Y instead." analogue.
Instead, completely arbitrary rules are in play with hard disqualifiers unshared. Things like:
"Every job should have at least four bullets."; "But only one page, or I chuck it"; "But-but, if it's only one page, _I_ wonder what they've been doing with their life (except new grads), and chuck it."; "Don't include more than title, company, and duration for irrelevant jobs."; "But any job without details looks like they're hiding something or didn't accomplish anything there."; "Start with a mission statement!"; "Never waste my time with a mission statement."; "ALWAYS include a cover letter, or I chuck it."; "NEVER waste my time with cover letter, or I chuck it; if it's worth saying, it should be on your résumé."; …
If you are applying to work at this company, this is probably good advice. If you're applying to work at most companies, ignore this advice. Everything he writes here makes sense, which is why you know that in our nonsensical industry, it is a waste of your time to put it into practice.
It's remarkable that, for an industry that prides itself on having individualist approaches and everyone doing things their own way, everyone somehow also keeps trying to give universally true advice.
That said, the title is, explicitly, "What WE Look for in a Resume". The intro makes it clear this is about them and them only and is more of a transparency report, an encouragement for others to be more open too. So I wouldn't blame this particular post of trying to be too general.
Honestly, having spent half of my career at small companies and occasionally screening resumes... I'd say this is great advice for joining a small company.
More importantly, if you're directly applying to a role, or you're applying through a recruiter, it's useful advice.
I generally follow these practices, too, and I'm quite happy where I've landed.
I worked at 7 small companies total.
All CVs are read. There may be some screening if recruitment agencies are used. Which is sad.
Aside: if using an agency you might need a CV for them and then when you talk about the job switch to the role-facing CV. I got burned by this in the past presenting a microsoft heavy story to a non microsoft using company they didn’t want to talk.
I don't agree with a lot of the things¹, but by and large, it's good advice to apply for us as well. Not sure what exactly the "nonsensical" things are that you say we need to waste time on to put into practice instead.
¹ like those "good metrics" examples such as having picked a store location using <magic> and the location worked out doesn't mean as much as the "bad metric" example of how many code reviews you've done (tells me you've seen a lot of code and collaborated, even if "you could have done it in just one year" as the post argues)
Any advice you would give for brushing up a resume? I'm not a dev but work in IT and do a lot of admin work, networking and a lot of security work. I am having a super hard time fitting all of the skills and tools I use on a one page resume. I had considered using like a GitHub Pages resume but haven't had a solid reason to do so.
For example, if you consider common skills like Jupyter notebook and git your competitive advantage (the only reason to include them in your resume), I would automatically assume that you have no other competitive advantage.
What an insane take. Different teams use different tools, and a team may or may not have time to bring someone up to speed on a tool they haven't used.
Listing git isn't a statement that it's your "competitive advantage". It's simply stating that you have experience with it.
Came here to post something similar. While I agree that if you're going for a senior position its probably less relevant, there are lots of junior and mid level riles that have various "hurdle requirements" like this. As a result, listing them on the resume is a way to say "yeah, I can do that"
> I do care about metrics. I especially appreciate metrics that are presented with two components:
> How they can be tied to business objectives.
> Your contribution in achieving that metric.
I think this one is often tough for junior ICs and even senior ICs in big companies. It's still tough for me after decades. A lot of us are far down on the totem pole, 8 managers away from anyone who knows anything about business objectives. If your job is to turn protobufs from one API into json on the other API, it's going to be difficult to turn this into a description of adding business value.
Projects in tech companies are gigantic. "Impact" is always super hard to quantify. Down at the bottom of the totem pole, you're working on a tiny 0.01% piece of the product. That's my impact?! Not very impressive. Higher up on in management, or off to the side in product management / project management, you're not really physically doing any of the actual product, but are making architectural decisions, serving as tech lead, herding cats, submitting status reports and so on. How do you quantify that? Some people just punt and focus on the product's performance: say [PRODUCT] earned the company [$X] and won [Y] awards. But you're still not quantifying your own impact. I think for the last 10 years of my career at BigTech, I can't possibly quantify my impact in numeric terms because they were such small pieces of gargantuan projects.
> I think for the last 10 years of my career at BigTech, I can't possibly quantify my impact in numeric terms because they were such small pieces of gargantuan projects.
Honestly, this would make me depressed rather quickly. I can't imagine not knowing/experiencing my impact via the work I do. Maybe it is one of the personality differences between people choosing to work for startups/scaleups vs. big tech (no judgement either direction, just my conjecture).
It’s a trade-off. I don’t get to implement the cool ideas I feel might greatly help my current employer, but their expectations of me are generally low and I get paid enough that I can retire a little over 40. Works for me, its not like I’d actually get paid more if I did something cool anyways. That energy is better spent on my own projects.
I’ve generally noticed attaboys and prestige aren’t really personally fulfilling anyways, no one cares and my work will probably be irrelevant in a year or two regardless. A bit nihilists, but it helps one detach after a long day and deal with the occasional failure.
I think business process perf profiling is a thing but micro managing seems to be their debugging. It's going to be nice if they can profile any part of process without messing with us (hey how's going?)
All of the advice sounds great, but not at all practical for some of the best engineers in I’ve met.
>Regular contibutions to personal GitHub for a year,
well too bad I work 15 hours a day in this tech company that has private git repos
> open source contributions, or stackoverflow answers
Well too bad that I don’t want to work opensource or use stack overflow (I don’t for work because we have our own internal one for years)
> show measurable impact
Well too bad, whatever impact I have in the corner of a 50000 employee company is probably not going to be enough for you.
How about just checking I know what I put on the resume and being done with it, instead of expecting me to cure cancer for a job position that has me change colors of a button every few days?
Edit: to be clear, I do agree with some of the things said like “look for a reason to say yes”. This is generally good advice outside of hiring. It brings new opportunities and when it goes wrong, lessons.
It's also worth noting that many companies have policies against open-source contributions, the use of public forums (like stackoverflow), and so forth. This is obviously more common in big tech as opposed to startups. I know employees in those corps that love coding and do that stuff in their spare time - but because of the policies they do it under a screen name and certainly don't mention it in their resumes, etc.
In some of those corps there actually is a "dont ask dont tell" kind of policy around personal projects/blog posts/oss contributions/etc. as the company forbids them unless you have special approval. However on the flip side managers know that the people with those projects and experiences often have a stronger drive than those simply treating coding as a 9-5 job.
I also know of cases where the interviewers were very impressed by the candidate's Github repo/oss contributions but stated that the candidate would have to stop working on that stuff after being hired. I know people who upon graduation seperated their projects for this purpose, continuing some under a screen name and having other less important ones for resume purpose knowing that they may not be able to continue working on them under that name in the future.
I actually did not know that was a thing, and I’ve been working in startups for over a decade now. I’ve never worked in big tech though, so maybe it’s common there. If a company told me I couldn’t work on side projects without approval, I’d tell them to fuck off.
Sweeping assignment of all copyright—including for things done off-hours—to your employer are common features of employment contracts in the US, which means no open source work without requesting an exception. This is true even in many startups. Absence of that kind of provision is seen as risky by investors or acquiring companies, who fear current or past employees will try to claim parts of the company's IP as their own.
Most are chill about adding exceptions (they don't actually want to claim copyright to that children's book you're writing in your free time) though. Still, sucks and probably ought to be illegal.
I just tell them "this is something I do" and if that's a problem "I'm not giving that up". Leave it to them to end the interview, no need to get an attitude.
I understand the anger from the ancestor post... that this is "standard practice" in the purported "land of the free" is just fucked.
but you do give a classier way to handle it which does leave the off chance that they'd make an 'exception' for some "special" candidate, still I wouldn't like to work in a place like that.
lol I’m not being literal. I couldn’t imagine ever telling an employer literally to fuck off. But I’d decline any job offer that came with that string attached. No amount of money is worth the freedom to do what I want with my own time.
As the article says, they’re looking for reasons to say “yes”, not reasons to say “no”.
If you say you don’t have any open source contributions due to company policy, that’s not a bad thing, it’s a demonstration that you respect the policy.
Also, for professionals who have a life besides coding and work, they might prefer spending their time with family, kids etc.
I spend my entire day at work in front of a screen coding, writing documents, meetings etc … the last thing I wanna do in my non existent spare time is to spend more time indoor in front of screen working on side/open-source projects and stack overflow.
You might use that as metric for junior/fresh out of college, but definitely not for experienced professionals.
It would not work for me and I have built tons of staff.
>Regular contibutions to personal GitHub for a year,
But what you quoted is not what she wrote. What she wrote was
Some signals of persistence that I’ve seen:
* Daily contribution to GitHub for one whole year.
* Being good at anything that requires consistent effort,
e.g. a Kaggle master, a chess master, a professional athlete, etc.
* Having previously joined another early startup before and stuck around.
I get that the idea here is to look for positive signal but for someone
talking about daily github contributions her own https://github.com/chiphuyen?tab=repositories
falls a bit short. Not a good look.
> well too bad I work 15 hours a day in this tech company that has private git repos
Same. I've been in the industry for nearly 25 years and have written hundreds of thousands of lines of code and tens of thousands of sql queries, but I can't share any of it.
If I am considering a candidate enough to look at their GitHub, I will actually look at the content.
If someone was actually trying to pass this off as relevant work, I’d disqualify them for being dishonest. They’d be 1000x better off by having no GitHub history.
Not if it's in a private repo... you won't be looking at anything. Are you going to outright reject a candidate because you can't see contributions to their current employers private org/repo? I believe this is the point the poster is trying to drive home. You can't see their contributions because they're private.
If you commit only to private repos then you shouldn’t be linking to your GitHub, as this article also says.
Resumes are for communication. Communicate! Tell the reader what you do, and demonstrate it as much as you can. Everyone knows that private repos are a thing, that’s okay. This can be articulated.
The article says verbatim "Don’t include a link to your GitHub link if it’s empty." yet you're giving 1000x (your words) credence to an empty profile versus someone working privately. Private contributions show up on the graph, you just can't see the content of the commit. So it's not empty and to your point it can be articulated. Sounds like you just want to see some examples of work, just ask for that, but that's not a resume.
“A commit graph and nothing else” is approximately equivalent to empty as far as I am concerned. If I clicked such a link on a resume, I’d say “wtf am I supposed to be looking at here?” If your repos are private, just tell me they’re private.
It is well known that many engineers can’t share their work. It isn’t a requirement. But if you do share your GitHub, make sure it adds value to your resume and doesn’t detract from it.
My Github has projects I have worked on in the past. Most of them are stable and don't need anything more than a few npm dependency updates a year. Linking to it to see these projects is useful to the kind of company that wants to see some small things I've built. If fake contributions to a private repo will tick a box somewhere, so be it.
The scenario is the author of this blogpost, who apparently wants to see that I'm dedicated enough to write code every day. I am, but it's for my employer, not the public. I'm not going to go home and waste even more hours of my life in front of a keyboard to prove that I'm doing something I already am.
I am sure the author is aware that not all software is public. I think the authors point is that you should find the best way to demonstrate your dedication, not that you have to do it in any one particular way.
If employers use stupid metrics, they get stupid data. Making a Github account look active is exactly as honest (in some ways more) as saying with a straight face that I'm passionate about <boring sector served by company's product>, and that's been required for decades.
Yeah, that attitude is plenty enough to get you a job at a megacorp looking for a good-enough coder to fill a position.
But early stage startups, as mentioned in this article, don’t really work that way. You’ll be working closely with people who are enthusiastic enough about the company to make major sacrifices to be there, and they will want to work with people who feel the same way whenever possible. You’ll be interviewing with these people, they will be senior, and they’ll recognize feigned enthusiasm.
You can set it so it shows contribution stats from private repos. Also companies with healthy attitudes to devs can allow their enterprise GitHub instance to transfer contribution stats to dev’s personal GitHub accounts.
> Well too bad that I don’t want to work opensource or use stack overflow (I don’t for work because we have our own internal one for years)
Then communicate that. The point in the article is just to demonstrate that you deliver consistently. If you have meaningful contributions to an internal system, tell me about it.
> whatever impact I have in the corner of a 50000 employee company is probably not going to be enough for you.
Working at a large company is definitely different than working at a small company. The breadth and depth of the job responsibilities will be different.
That’s okay. Not every job is for everyone.
> How about just checking I know what I put on the resume and being done with it
What do you mean by “check”?
Resumes are a place for the candidate to tell me about themselves, they’re not some sort of background investigation. I presume they are honest unless the candidate gives me a reason otherwise. And if the candidate gives me a reason to believe they’re not honest, I’m not wasting any time sleuthing about their background — they’re disqualified.
> How about just checking I know what I put on the resume and being done with it
Which would bring us to another favorite Hacker News topic, i.e. venting about how tech interviews are terrible, and why don't interviewers just look at the candidate's resume and projects instead :-)
And that's fine. I think there's confusion that every SWE can work at every company.
Every place has bias in their hiring. It's literally the point of screening candidates. This place chooses to bias against folks who just want to code at work and want to use a traditional resume. Makes sense when every hire can make or break your company and you don't have the resources to put someone through a multi-month boot camp before letting them touch the code base.
When every hire can make or break your company, then you are looking at this from a very wrong perspective. In that case you should be hiring in network, candidates you know, or are vetted by people you trust. Or hire people on contract and convert them to full time. Or work with trusted vendors in the field who can source great candidates.
Not every SWE can work at every company, that is pretty much true. But creating arbitrary “signals” to figure out who will be a great fit will doom your company with a very specific type of people, which is not what you want when every candidate can make or break your company.
Startups tend to be shockingly ignorant of the culture at larger companies (or non-startups in general), and personally I find it a bit of a red flag when it seems like nobody at a startup has worked for a real business before. It's great to have fresh takes, but there should be a few people on the team who also know how normal companies operate.
I remember interviewing for a startup that sounded pretty promising. The interview was going well and then I was asked for a presentation. I told them that I was more than happy to present on personal projects (of which I had plenty) but was not comfortable sharing details of work related projects while not explicitly representing that company.
They basically said "too bad" and where shocked that I cancelled the rest of the interview. I've worked at plenty of a companies in the past where being willing to share other companies' internal work would be the red flag, and turning down such a request would be seen as a good sign.
> I would actually not apply to this company.
Sadly that was the same impression I've had, and this is from someone who has been following the author's writing for awhile. Especially in the current economic environment.
A lot of companies are very uptight about external presentations without explicit approval. This is mostly about conferences and the the like but a private presentation to a competitor might well be looked at even less favorably.
I don’t think they were suggesting you have to do all of those things, but rather that those things are examples of resume content that demonstrates what they’re looking for.
Making something optional on an application is a waste of everyone's time.
If it is optional, and it doesn't have bearing on the application process, then don't ask me to include it.
If it is optional, but it does have bearing on the application process, then I assume that I'm not a good fit for you.
If it is optional, and it officially doesn't have bearing, your screeners and interviewers may still have an internal bias that favors applications which "go the extra step" to do the optional work. Even if they don't, I'm going to assume that they do and that we're all wasting everyone's time in asking me to apply.
Disagree. There can be multiple optional things, where nobody is expected to have all of them, but everybody should have some of them.
It’s a way to expand the pool. Startups especially need a lot of diversity of skills, so rather than specifying the one ideal set of skills/experiences, it’s better to be open to a wider range and then use what you’ve gained from this hire to inform what you need in the next.
Rigid checkbox criteria makes sense in dinosaur companies, but not small ones.
They're literally flagging one "sanctioned" way to provide signal as an example in a resume advice post--how is that a waste of time? This lets people infer what other types of "optional" content might provide signal: publications, blog posts, etc. Transparency in the application process is fantastic and it's wild to me that people are upset about a company posting some ways that applicants can make themselves stand out. This is order of magnitudes better than VC, finance, etc.
This. Companies just like to make candidates go that extra mile to finally not even look at their resume. Job listings where they already are interviewing candidates or have hired one are still up. Imagine how much time is wasted with frivolous optional questions.
How interesting. The first two assertions would imply that you model candidate fit as a pure product of the dimensions you have. i.e. if any of the dimensions are absent then the candidate isn't a fit.
Well, the difference is that my candidate fit model is not a pure product. It has some sums in it. Your teammates at my org will be people like that.
Slightly disagree, they're just providing one potential way to signal experience. I'm sure there are other ways not listed (firth author publications from tier 1 conferences or journals) that are more valuable. I think you're right that this could be used as a tie-breaker, all other things being equal.
I don't think it should all be taken that literally. It's not about literally using GitHub or stackoverflow but about having anything demonstrable, even if it's just words on paper about what you did in your role and not a link to something public.
If you can't show anything, you're a tough sell no matter where you apply, and that's not meant meanly but it's the problem literally everyone has when looking to get their first serious job without having done side projects or other demonstrable things in the past. You might be offered an entry level position if they don't simply take your word for it or have tests available to assess claimed skills. (On the other hand, a friend once took a test for a job, like hacking some application for a security consultant position, did very well at it, better apparently than someone who joined a month earlier and gets a principal consultant title and salary, but my friend was given a junior position... YMMV how much they care about tests if you can talk the talk and are of the age to get grey or bald.)
Oh they literally want code on github. And that’s a hard no for me and should be for most.
I don’t play these games. I don’t take tests, I don’t have public repos, and I’m not going to change that.
Why? Because these tests are arbitrary, faulty, and highly based in subjectivity. They are costly to me both in time and mental health.
Back when I was fresh and did them, I found that I always ended up starting a new job with a bad attitude. Well duh, it’s abusive to make a person stand in front of others and have them evaluate their worth live. It’s abusive to ask someone to work for you for free so that they can see if they like you.
It’s a terrible cycle and it shouldn’t be justified or normalized.
There are plenty of people out there who want to hire you without coming up with idiotic games for you to have to play. Seek them out.
I can see valuing some clearly passion driven extracurricular activity. Like if someone is a top SO contributor, that's cool. Or if they're part of a big open source project. Or also if they volunteer at a soup kitchen or charity. Stuff like that may be worth including on your cv to show what your interests are. I wouldn't weight it much differently than anything on the hobbies section, but it's still cool.
Personally I'd be wary of hiring someone who had done just the right amount of all this stuff, and who appeared to be soulessly gaming metrics instead of actually being interested in stuff. Otoh, there are jobs and work environments that fit well for that kind of person, and screenings that optimize to make sure that's what they get. It's just as important for people that aren't that way to not get accidentally stuck in such an environment. Like a "17 pieces of flare is only the minimum" kind of vibe
No one really knows how to hire so they chuck in random filters that sound good.
That said I get the impression overall that the OP preponders each CV and tries to evaluate it on its merits. Small
companies can’t afford to turn good people away because of silly reasons like you haven’t produced code on an open license and uploaded it to Azure.
Impact is about understanding the impact. Which talks to then getting jobs where you can write a good story about them after. Which you might do. I don’t. I optimise for joy and teamwork so I take the hit in bragging rights. However there is usually a story to tell of how you helped the company be better.
All this said I am curious if the “no cv” approach of fly.io will catch on. They have an interesting sounding application process.
I think the advice she has is mostly pretty spot-on for recent graduates looking for ML Engineer jobs, and I think her advice is consistent with what I was mostly looking for when I was a hiring manager for non-senior roles.
That said, I agree that the advice is much less helpful for anyone who has significant industry experience as an ML engineer.
I would love to work on a company that allows time to contribute to opensource or answering questions on SO. 15 hours a day sounds like modern slavery.
I think the well is really poisoned here. Resumes either hardly matter, or are just for SEO.
- If you're shooting resumes off into the void of companies "apply now!" pages, it's HIGHLY unusual for them to be looked at by a human. And when they are, they'll probably be considering more data points (looking at your LinkedIn and GitHub). So here it's best to make them "machine readable, human-tolerable".
- If you're handing out resumes at an event, you are going to want to make it terse and punchy. Sell your impact and skills. I think this is the least degenerate form of resume. Also, I've never done this outside of my career fair in college, where your resume is basically just your GPA and expected graduation year.
- If you're being referred, your resume is mostly for talking points when you're chatting with someone. So making it like a powerpoint is best for this.
Plus, for the first one, most of the time you just get ghosted. So forget overly tailoring your resume to the company, unless it's one you really really want into. In which case you're probably better off poking around and trying to either find a recruiter or find a referral even if it's just a "I talked to this person once and they didn't punch me in the face at all, you should interview them" referral.
I'm honestly kind of passionate about resumes, in theory? "Here is a 1-pager of my professional career" is an interesting problem. Unfortunately, that's typically not the problem you actually need to solve when you're sitting down at your doc titled "Resume".
Not sure about the first one. I work for a big company and when we hire we definitely human-read lots of resumes, which isn't to say that machine readable is not a plus. I agree that tailoring may not be worth it.
I'm surprised nobody mentions hobbies etc. Maybe I'm just an old fart but I like to get an idea of the person as well.
The main problem of hobbies is that I typically don't think they matter enough to deserve space on the single page of your resume. I'm not even a decade into my career and I'm already considering cutting my college stuff down to "COLLEGE NAME YEARS ATTENDED DEGREE GPA HONORS" in a single crammed line. I think I'd put down my in-major GPA and emphasis courses before I'd put down that I like video games and my cats (.....which let's be real, you can probably just assume is in the hobbies for software engineers).
It'd depend on the field (and region), I imagine, but after the first job or two I feel like all that matters with respect to schooling is that you went. Five or ten years into a career I'd be surprised if coursework that hadn't been used on the job was relevant, and GPA wouldn't even be considered.
Hobbies are probably not that useful either, but I could see them catching a hiring manager's eye. Coursework probably won't have the same effect, although I suppose it could help you get through ATS.
Not that I think anyone's really looked at my resume for over 20 years (jobs through network), but I think the idea of a hobbies line is that it can be a conversation ice-breaker. That said, I don't think I have one on mine. If theey Google me they'll turn up more than enough to talk about.
It varies significantly, as these things do. My first job out of college ~didn't accept people with below a 3.8, so they'd explicitly ask if you left it off (or worse, would assume it was <3.8 if you didn't bother to add it).
> - If you're shooting resumes off into the void of companies "apply now!" pages, it's HIGHLY unusual for them to be looked at by a human. And when they are, they'll probably be considering more data points (looking at your LinkedIn and GitHub). So here it's best to make them "machine readable, human-tolerable".
I wish companies would just keep it real and admit this, and instead of asking for a resume, specifically ask for a simple text or XML file with a machine-readable list of keywords. Because, let's be honest: That's all the machinery at the top of their funnel does. Once you get past the keyword filter, they can ask you to craft a real resume for them. It would cut down on everyone's work: the candidate's and the hiring company's.
I'm firing off resumes to hundreds, maybe a thousand companies anyway. It would be nice to have a standard, structured format for communicating with their AI screening machinery, that I could use for all of them.
At least when I was a hiring manager at an AI start-up, I looked at just about every resume submitted, and I thought the advice was pretty spot-on for what I was looking for. That said, I've never worked at a very large tech company, so I could believe that humans aren't reviewing them at those institutions.
> if you consider common skills like Jupyter notebook and git your competitive advantage (the only reason to include them in your resume), I would automatically assume that you have no other competitive advantage
I get this, yet, at the same time, I've been asked by recruiters if I was comfortable working with "git flow with Gitlab and Jira" since I did not name any of those in my Resume.
I wonder if I've ever been filtered at first instance for small annoyances like this, it's hard to build a good resume when everyone is looking for something different so I would appreciate if things like adding keywords would not count as a deterrent.
Now I thinking how I can put that I've been the unofficial git guru in several jobs in the resume without sounding like I'm just playing the keyword game.
Maybe under "Skills" I'll add something like "git is my bitch and I eat merges and shit rebases". Or is it too formal? XD
> I've been asked by recruiters if I was comfortable working with “...Jira"
Great question - I might start asking this, and shitcanning anyone who claims to be both experienced and comfortable with the idea of working with Jira.
You can optimize for this one guy who has something of an axe to grind, or you can optimize for the 99.99% of employers who look at education, relevant skills and employment history. It's almost definitely worth ignoring everything in this post.
Reading the claypot.ai website doesn’t really attract any interest or give the idea that you’ll be working for a startup that’s going to be financially rewarding or with a purpose or even a product. My guess is the recruiting and hiring is mostly due to Stamford connections and not the type of place that’s attracting applicants outside of that sphere.
This is the sale they make to candidates, would you “say yes”?:
What makes Claypot AI special?
A culture of transparency, collaboration, ownership, and learning (we're in a new space so there is a lot for us to learn!)
An opportunity to win over a large, growing, yet untapped market for fast ML delivery
A strong community
Expertise in both distributed systems and machine learning
A very high bar for engineering craftsmanship
What will you get?
Competitive compensation package
Flexible remote-friendly culture with options for in-person collaboration
Learn how to build a startup from the ground up
Public speaking opportunities
An environment for you to grow into the career you want
I'm on my fourth job in four years. First company was a startup that went under, other two I immediately realized I wasn't a good fit but I stayed for about a year each, gave it my all, then resigned with peace of mind. Salary was never an issue. Now I'm at a startup again -- I'm happier than ever, wouldn't leave this job for the world, but we're on shaky ground and the recession might sink us despite our best efforts. So in 2023 that might be 5 jobs in 5 years.
I don't think I'm the outlier. I've only met one person that does legitimate "job hopping", and you can tell from talking to them that something's off. Most of the time people switch jobs for good reason. Disqualifying someone based on that means you're either an Ivy League kid that never got their hands dirty, or you just think you're a rare enough exception that the rule still holds.
I've been unlucky enough to have 'unintentional' job hopping, the gaps of which I think make me look like a poor candidate. If someone looked at my LinkedIn or resume, they might automatically move on because of a 4 month gap here or there. If I actually received an interview I could explain "Well, this was a small company and they couldn't pay me on time so let me go" or something similar. When you've been stuck towards the bottom end of the economy with companies that may not be run that well, it can make you look worse than you are vs circumstances beyond your control.
I'm due to interview someone tomorrow who has had 20 jobs in 25 years... a few 6-month contract positions but mostly 12-18 months in 'permanent' roles. I'd estimate that most of the roles would have been on project-based work of >2yrs duration.
I'm keeping an open mind - this person isn't ruled out but it's difficult not to read something into the possibility that they've never seen through a project.
> These articles claim that at large companies that receive an influx of resumes, recruiters set rules to surface resumes that contain certain keywords... That is a bad strategy for applying at startups like ours. We’re not looking for keywords. We look for demonstrated expertise. Here are a couple of ways to demonstrate your expertise.
I'm always a bit surprised when startups, whose leadership doesn't even seem to understand the dominant hiring patterns for large, mainstream corporations, expect candidates to cater specifically to them.
If you're trying to get me to work for an "AI/ML platform" startup in this market right now, you'd better spend more time convincing me that you'll still exist in 2 years than telling me how I can tweak my resume for this specific company.
Honestly, a startup looking to hire founding positions should probably be searching their own networks rather than screening hundreds of resumes a month.
The author is on to something here: "look for reasons to say yes"
The default in hiring is no. Confirming the default is a lot of work, and often, you miss a lot of great talent. Here are some situations where I've seen this play out:
NO because of degree requirement. YES candidate wrote the CMS our product was built with. (candidate didn't get job because we found out two years later he had applied and the recruiter never forwarded the resume on)
NO because of 3 years out of industry. YES to candidate because he had the same job at competitor that went public 3 years ago and had a 3 year non-compete (was a CFO, so it was real). (recruiter had a policy of I talk to every applicant, and the candidate told her who he was and why he applied... hired)
NO because of multiple 1 year gaps in employment. YES because candidate had managed multiple five year construction projects on time, on budget. Turns out the gaps were where they guy took one year off and volunteered, helping build schools in Africa. (recruiter sent to hiring manager, and hiring manager passed because he thought the guy was a "job hopper")
Exactly. I don't want to spend weeks interviewing people, my boss doesn't want to pay me to interview people, and my PM wants someone who can work on their tickets ASAP. It will be much easier for me if I can just hire you.
So "give me reasons to say yes" is great advice, along with "don't give me reasons to say no" (like lying or being an arrogant douchebag).
Use things like degrees as a green flag, rather than the absence of one being a red flag.
I'm not sure that it's representative of the industry, as a whole, but it's excellent.
For myself, I read every résumé that I got; sometimes, not completely. If I saw that it wasn't a fit, early on, I'd abort the process.
But, for the most part, I enjoyed long, complete résumés, and would have killed for things like GH repos (they weren't really a thing, when I was a hiring manager). I tended to look for "orthogonal thinking," and "diamonds in the rough." Very few folks would come in the door, with the skills we needed, so I expected to invest a lot of training.
I interviewed about 40 people over the last year, and agree specifically with not listing every single possible technology you've touched in the last 10 years, especially things you're not comfortable talking about. Because I will pick ones we're using or that I have experience with, and will ask you questions about them, and if you can't answer really basic questions then I'm a lot less confident you're not bullshitting me about everything else you've written down.
I think (I'll have to touch it up soon) that my CV bundles skills by degree of familiarity. I wonder if that's appropriate?
For instance, I have used lisp dialects to build useful functionality, but I'm not that comfortable with it. Does that kind of thing have a place on a CV?
Most CV advice I could get seemed to be from non-technical people.
I guess I primarily want to showcase adaptability, and making a laundry list of languages I have "notions" of could work. As long as it can be reasonably explained, one can probably put it on a CV, though it depends on the recruiter.
I think it’s more important to focus on core skills.
Put it this way - by far the best two candidates I interviewed this year had CVs that basically said they worked in Python and had for a number of years and told me a bit about projects they did with it. The worst interviews I had were with people who over-egged their ability on a huge range of things and couldn’t answer basics.
Expertise takes time to acquire. I’m skeptical of people who claim to be experts in too many things
While I believe this is true, the problem with the statement is that these resumes and candidates are not claiming expertise; they are listing skills. Basically "I've used this in my work before." That information probably isn't very useful (that you used Jupyter or Git), but the resumes in question are trying to cover all the bases.
There’s a lot of bad advice here. Like you can dismiss this article right when the author says they read every resume and don’t use a scanner. Unless this is a tiny shop with no recruiter anywhere in the process, this simply isnt true. The recruiter is going to screen some of them, even before the hiring manager gets to them.
Now don’t get me wrong. Some of the stuff in the article is good, if tailored for new grads and junior people, but some is just bad and wrong.
I’d say pretty much anything everything billeted in this article is trash. The insights in the prose.
TL;DNR
Don’t skip the keywords folks.
No one gives a fuck about your social media (eg StackOverflow, GitHub, Kaggle, etc). I don’t have time to read some rando’s code, and all it does it show me that you don’t have a hobby outside of promoting yourself on social media.
Let's be honest here. What are you getting out of GitHub? My experience has found exactly two cases:
1) It's a toy. There are like two files and and ~100 lines in total. In which case, the repo is meaningless.
2) There's a fuckton of code. In which case, you are absolutely not reading it. You can't. You have no context, nor do you have the time. Reading code is Hard. You absolutely are not going to spend several hours inspecting some rando's code. So what's the point?
You can get the same amount of information from reading the resume and a 30 minute phone screen.
> 1) It's a toy. There are like two files and and ~100 lines in total. In which case, the repo is meaningless.
I don't see it that way at all. Short programs can be very meaningful. For example, I wrote a python program that generates Verilog code for a rational rate resampler that is under 100 lines. That would be very useful to discuss in an interview.
> 2) There's a fuckton of code. In which case, you are absolutely not reading it. You can't. You have no context, nor do you have the time. Reading code is Hard. You absolutely are not going to spend several hours inspecting some rando's code. So what's the point?
I absolutely read the code. I'm not digesting every line, but I take a look at the general structure and try to get a feel for it. If I can clone it and get it to run easily, even better. I can do this because I'm an expert in my field, and we only interview people with relevant experience and skills.
> You can get the same amount of information from reading the resume and a 30 minute phone screen.
Not for me. I've had people BS their resume and the phone screen and then fail miserably in the in-person interview. I've yet to have someone who had a strong github resume not ace the in-person interview too.
You do the same thing as when checking out any tool/library/whatever: Skim the README, then if still interested jump into a file or two and look at what the code is like. It’s pretty likely - if this person works in the same domain, usually the case - you (as an experienced dev) will be able to guess what files are worth looking at and quickly get at least some minimal understanding of what is being done.
And remember, this is just to decide whether to invite someone for an interview. Looking at the repo is just to get some extra signal.
So at best zero signal compared to a coding screen, but even less if it’s in a language youre unfamiliar with. So you can’t judge quality at all. Just, “Yup! There’s code!”
Also, there’s no point to look at the code in a library you’re using, because you’re not maintaining it. When was the last time you popped open some random file in Kafka? I bet never.
Do you not find that 95% of the time it's just a blank GitHub though? The only people I've seen without that are either in academia or work on OSS in their day job in some way.
My area is tightly coupled to a few OSS projects, so we tend to attract people that are active contributors. I've never been let down in the in-person interview by someone with a strong github resume.
Same thing with GitHub activity grid. I don’t even know what it’s supposed to tell. Even if I’m writing code everyday, that doesn’t mean I’m checking it in, and even if I was, I’m not doing it on a public repo or even on a GitHub hosted repo.
I look at those but they don’t tell me much as people are often working on a template and have had help, so I can’t disentangle what is someone’s work as easily
What im seeking in a company, i can datamine in a day from linked in. Your tech department churns through people? Dying from tech debt.
People vannish from the job market after quitting you?
Toxic culture and burnout stake.
Why cant a company be expected to put in similar effort to background crawling? Why cant there recruiters be not expected to properly vet the jobs they contact me with? Why is the effort expected so low, from those who have the biggest ressource pool?
I've had the luxury, perhaps outside of the first job, of looking for work while I have work. This makes it a bit easier to be targeted in my approach, so it might not work for everyone. But I use a resume to apply for a job, so every job gets a different resume.
At the top of every resume is a job description: a table that lists the company needs and my skills with respect to the requirements--even if I don't have any. Typically it's one page for a hiring manager to compare against the JD and decide whether she wants to look at the canned bullets of my work experience.
My current and prior jobs had a formal application process post offer: I did not go through an online application process or submit a resume to an electronic system until after we'd gone through interviews, etc.
If I find a place I want to work, I make some effort to find out who the hiring manager is for a given position. If I can find an email address, I'll reach out; if not, I look for a mailing address. If I'm really motivated, I'll try to find a phone number.
My experience with this approach has generally been positive: it helps identify good employers, makes, I think, a good impression, and ensures that we don't waste each others' time.
This is very interesting, it appears to be catering to devs who love to work on own project and see help on SO.
It also helps a competent manager to see the code structure and such.
Nothing wrong with that, but! ask yourself, if all the SO profile is all questions and no or no correct answers, what does this tell you?
How would you know if the repos are not forks or copy paste jobs?
And what kinda projects will be in the repos?
For sure nothing proprietary, hence private projects.
Have these projects been done during work time or during time off?
Both are bad, if the dev worked on private projects during work or if they go and code 5 hrs a day after work, or any unhealthy amount.
I used to do many projects outside of work,things like sign up, log in features from scratch in node because I thought I need to learn the next new thing, but once I moved positions into a more product ownerish role, ie, much more work, I had literally no time any more to spin up a personal project.
But yes, all in all, this is much better than applying at the typical company where hr is writing nonsense job requirements like 15 years experience in golang and such.
A = Concise and short CV, made to be read by humans.
B = Bloated and keyword-riddled CV, made to be read by machines.
I = successfully landing an interview
To me, it seems that P(I | A) > P(I | A). That is, if a human reads CV "A", you have a greater probability of landing an interview, than using CV "B".
But then, P(S | B) > P(S | A), because the screening software can filter out candidates that lack the correct keywords, etc. And in order to get to the interview stage, you need to pass the initial screening stage. You could have the best CV in the world, but if its rejected at step 0, then that doesn't help you. So it seems to me that its better to maximize your CV for S. This all of course assumed that there's no alternative ways around / bypassing the screening stage.
I think the fundamental problem is that once a company crosse a certain threshold on the number of applicants, using humans goes out the window for the screening stage.
150 for one person seems tough, but what if the company gets 15000 applicants a month? And most of these are junk anyway?
You folks are probably going to skewer me for this, but here goes:
I’ve been a hiring manager for many years and hired a lot of people.
It starts with reviewing resumes just to see if someone has a few years of experience in similar technologies as what we are working with.
If it looks good, I just pick up the phone and spend half an hour or so shooting the shit - an intelligent person will realize this is an opportunity to talk about their experience and they’ll do that.
If that goes well, they come in for a face to face chat with me and maybe one or two of our developers, totally free form and absolutely no coding challenges or nothing.
If they seem like they have their shit together, we hire them.
I’d say I have about a 90% success rate with this model. Yea, sometimes you get a good bullshitter and it doesn’t work out, but that’s easily remedied…
I have a lot of faith in casual conversational interviews and don’t worry about grilling people on whiteboards. I just go with my gut and that’s it.
Anyone who can bullshit so well they can survive this really ought to be in sales or something. They'd make way more money with their evidently incredibly good social skills, working in a field where it's directly applicable.
I'm convinced most of the "bullshitters" people "catch" with programming puzzles, who "can't even write a for loop" are just choking under interview pressure, or are for-real bullshitters but never would have made it through the process you describe anyway, because they're not that good at bullshitting.
We were interviewing someone that used to work with my manager... as his boss. My manager basically said "This guy is awesome, we'd be crazy not to hire him" but obviously my manager wasn't allowed to be a part of the interview.
He BOMBED the interview, which was a pretty simple coding challenge. I could tell he was incredibly nervous (despite being a very experienced developer) and it felt obvious to me that he was only bombing because he was just so nervous.
I could tell from talking to him that he probably knew what he was doing. We hired him and he was great. Some people are bad at interviewing (myself included.)
I don’t know how I feel about this post. On one hand, if I were running a company, I would want a hiring process similar to this.
On the other hand, the company I work for has draconian publishing policies. I can’t have a technical blog, can’t have GitHub repos of hobby projects I work on my own time, can’t write about any of the work I do on my resume. If I want to contribute to other repos, I need an approval for legal which takes forever and if you’re lucky enough to get it, you have to write “not a contribution” in the submission. When asked about what to write in the resume, they say to copy the job posting (or parts of it) I was initially hired for.
Aside from these crazy policies, I love working at my current workplace but sometimes I wonder if I’m hurting my future by staying on and letting my resume for these years spin into a black hole.
Maybe I missed it in the article but it looks to me like they're hiring more junior candidates. For more experienced candidates (which it sounds like you are) I think years of experience doing similar things in a similar field/organization would be the most likely thing to lead to a phone call.
I interviewed with Claypot last summer for an infrastructure role. They responded about 5 weeks after I applied. My first conversation was with Chip herself, where she appeared to be checking Slack for our entire conversation.
I did a technical interview where the interviewer asked me to do calculate some statistics over streams in a Jupyter notebook. I completely bombed the interview, let that be clear. But it was very odd to me that for an infra engineer role, at no point was I asked about any experience with ML infra, scaling, operationalizing models, storage, networking, etc.
Sorry, I prefer a concise one page resume that tells me just enough that makes interested to want to learn more. Anyone can claim outcomes and metrics on a resume that can never be validated.
You don’t need to “validate” the outcomes and metrics on a resume. The usefulness of this content (or anything on a resume) is not in its utility as a test of character.
I like when people list outcomes and metrics. It gives me a starting point for something to ask questions about. Projects make for a lot better interview discussion topic than “skills: HTML, JavaScript, CSS […]”
As a data point: we've been hiring resume-blind for going on 2 years now. We tell candidates they don't have to send us resumes, and we generally don't read them.
I did resume blind hiring for a bit. I had a list of skills they would need and said “apply if you have them”. Then I asked them to submit a paragraph about how they will bring a unique perspective to the role. I got a lot of interesting applications but some of the interviews didn’t go very well. They didn’t have the skills.
We don't interview. We do work-sample tests (WSTs). Anybody can get our first WST just by asking. Not submitting any WST response is our biggest downselect, followed by rejected first WSTs. I'll get on the phone with anybody who asks to, and we'll answer almost any question by email regardless of where people are in the process.
The whole thing is calibrated to take less candidate time (from a suited candidate) than an interview loop would.
You can see a warts-and-all experience report from a thread started earlier this week (amusingly, I only found it because I was searching for people shit-talking Chicago on HN):
Regarding resume length, I'm a huge fan of the "collapsible" approach: if when reviewing your resume I somehow print out only page 1, is it still great? Is everything I need to be interested in you there? If so then you can have all the pages you want.
The origin of this test is that I do not actually want to read your resume. I'm not going to look at the other pages if page 1 is boring! So tell me who you are first and if I'm interested, I will follow along.
The one thing I don't see mentioned here is spelling and grammar. Probably the single most important thing you will ever write that absolutely must not have any spelling or grammar errors is your resume. When I am reading resumes, as soon as I see a spelling or grammar error I toss the resume. To me it indicates that you don't have an attention to detail and you really don't care enough about getting a job to make sure your resume is flawless.
This is just for this specific company or this person alone. Usually, they or HR only spend around 15-20 secs on each resume to decide. Github or others don't matter
I honestly don't like the tone of how our industry treat us. They are trying to find skilled workers to help companies or finding beggars who please them the most?
Yeah, it's always the same w/ this: there's absolutely no consensus whatsoever. I once removed "git" as keyword (as i.e. recommended at the beginning of the post), and got asked tirelessly by recruiters if I actually didn't know git, and why I wasn't mentioning it... So yeah, those skills list are meant for recruiters and machines alike...
This company sounds like an extreme outlier. About the only companies I still see doing it this way are the ones whose employee count can be done with two hands, and without re-using fingers. As in, single-digit employee count, maybe low double digits at most.
Don’t get me wrong, this is the way it SHOULD be done. But my cynicism at the employment market makes me very dubious that anyone other than a micro-handful of companies beyond the sub-10-employee startups are still doing this. Even small startups can leverage third-party HR services that will automate most of the hiring process. And for busy founders, that is a godsend that they eagerly reach for.
So, does anyone have the “perfect” resume template? I have been told many things by various recruiters. None of the answers are the same. If I apply, and some other person applies and has less experience than me, but they have an inside connection referral. They will most likely get the job. Sometimes I had gone through few rounds of interviews, and had very good vibes/result. In the end they say no. I have stated to lookup org reviews. If a recruiter reaches out to me they have my full attention, I expect the same. Often times something serious comes up and then they go MIA. Still learning the way these organizations operate when it comes to hiring. Have yet to master that.
Looking for a very specific set of things or type of resume is a huge oversight. Very few people are going to know what you're looking for, and anyone competent doesn't value their time so little to micropolish their resume for exactly your company. If you're not scanning every resume to read between the lines of how the applicant has devised their resume to try to digest what skills and experience and personality they actually have, then you're basically overlooking a significant percentage of those who apply
A corollary to this is if the company you're applying to isn't competent enough to figure out if you're right for the job, you probably don't want to work for them anyway
I tailor my resume to almost every company where I seem like I could fit. Especially since I’ve had a lot of jobs and a subset is more interesting to an employer than a different subset, and I like to keep page count to 2-3 pages max even though I could probably do a 7 page resume.
A major pain point in doing this is you lose track of what you said and to whom, especially if you include cover letters (which I also do).
What I learned that is helpful is to save every version of your resume/cover letter including any sources (latex), and timestamp/date these resumes. Do this even if you didn’t tweak your resume, space is cheap.
Anyway I found that to be real helpful to track what resume I’ve sent out and what it says.
When I have been the one hiring, whether as a supervisor or as part of a hiring committee, my favorite part of the paperwork has always been the cover letter. I cannot agree with this article's advice saying it is not important. Are you kidding me? Write me a few nice paragraphs about yourself, why you think you're a great match for the position and why you want it. Highlight something from your resume that I am probably only going to otherwise skim. The cover letter is like the first couple minutes of sitting in the interview. We get to know each other a little, and importantly to me, I get to know whether you have half-decent writing skills.
One very small tip - don't overdo it in selling your accomplishments. I see surprisingly many resumes with the words "vast experience", and they're usually obvious bullshit.
OTOH I've got a close-ish relative who's had a very successful career in HR in multiple large orgs and now does some résumé consulting on the side, and she always re-writes things way beyond what I'm comfortable actually claiming and insists that's for-sure the right thing to do when applying to most bigcos—just part of playing the game, and if you don't play, you can't win.
You'll tell her you did X and she'll be like "well it sounds to me like that was Y, so write that down" and you're like "well... kind of? But not really" and she's like "yes, it's Y, you're cutting yourself off at the kneecaps if you don't put Y". Where Y is usually something to do with leading or managing or "architecting" something, and it's maybe technically true but I'd never have characterized it that way and would be struggle to talk about it as if it were that.
That may be fine for getting past recruiters, but if you get to competent tech interviewers who decide to ask you about technical things you are "expert" in, and you flounder, then your credibility is shot.
> It can weaken your resume. For example, if you consider common skills like Jupyter notebook and git your competitive advantage (the only reason to include them in your resume), I would automatically assume that you have no other competitive advantage.
Yes, but I am forced to include git to ensure that other companies won't throw my resume out for now listing git.
>If you’ve been working for 2+ years, remove your GPA and coursework. I care more about your work experience.
I do believe in this too, yet I've been told a few times that in some countries or corpos people tend to care about this and I do wonder whether I should have "targeted CVs"
Some good suggestions and tips in the post and if I may, I'd like to add a tip of my own: scan the CV/resume for spelling, grammar, formatting mistakes.
I know it's not a very "scientific" and objective criterion, but it has never failed me :-)
Do... you invite people who've made those mistakes in to interview, at least? Else I'm not sure how you could have even a fairly unscientific sense of whether applying this criterion has failed you or not.
Definitely, and to be honest I’ve seen a few exceptions that confirm my unscientific rule. I try not to judge by the look, but in a CV for an engineering role I like a nice format without errors. Same goes for code reviews. I prefer clean & commented code over dirty/sloppy hacks.
Ah, cool. I definitely would expect some significant correlation there, but wouldn't be so sure without checking—looks like you're Doing It Right (well, as right as one can with hiring practices, short of running an actual study), sorry for implying you might not have been.
The attitude that this post conveys is that the advice she presents is universal. No. It's just her company and for her circumstance only. If you tailor your resume to fit her advice you'd be tailoring it for her company.
Many startups don't read resumes. For my company the resume is screened for buzz words by a recruiter. The candidate is fed into the interview pipeline before ANY interviewer reads it. I read the resume 10 minutes before the interview starts. My company IS a startup, her advice Does not Apply to My company.
There was a radio ad on NPR for Indeed.com that said "We identify candidates for you whose resumes are an exact match for your job description," and I thought "NO YOU FOOLS! YOU'RE GIVING AWAY THE GAME!"
It's literally as simple as using the exact phrases in the job description to (truthfully) describe your own accomplishments.
> Show how you acquired and use that skill in your job
This can be difficult to do especially as the years of experience add up. I have 20, and can only put so much on 1-2 pages. I typically limit short story telling to the most recent gig.
> Share your expertise on public channels such as: StackOverflow answers, open source contributions, papers, blog posts
I share stints and short responsibilities for the open source work/projects I'm involves in. Again, towards a reasonably-sized resume, listing any more than that could easily bump my resume to 3+ pages.
> Daily contribution to GitHub for one whole year.
Terrible metric. Perhaps this wasn't well-written. Consistent contribution is more important than vanity metrics like daily contribution. And even then, it doesn't represent what someone has been up to. A month's worth of work can be squashed into a single commit that is pushed. Not to mention this can be easily faked. This reflects poorly on the person writing this as a form of measure.
> Having previously joined another early startup before and stuck around.
Bad signal. Startups are fickle, and many don't last more than a few years. I've joined several that shut down a year or so after I started. And I get asked about it all the time during interviews.
> I’m a bit hesitant when I see candidates who change jobs too frequently, e.g. 5 different companies in 5 years. I understand that not all jobs work out, so it’s okay, sometimes necessary, to move on. However, consistent job jumping can imply that you get bored or give up easily. A year at a job is hardly enough to get deep into a problem space and make significant contributions.
I don't think the author fully understands the startup ecosystem, or hasn't considered the range of nuance that exists.
> We look for people who can bring a unique perspective to the table.
I like this, but they don't mention critical thinking, which goes hand in hand.
> 5. We care about impact, not meaningless metrics
Odd assertion, since they clearly care about meaningless metrics like github contribution frequency.
> If you’re applying to a small startup, say, of less than 20 people, spend some time researching who works at that startup and email them directly.
Careful here. This can quickly get you blocked if you're pasting the same message to multiple people. A better practice is to choose one person and reach out, wait, and try again. But write the message organically, don't just copy and paste.
> Don’t include a link to your GitHub link if it’s empty.
False. Include it with context. e.g. if contributions are hidden by a private project that you've been involved in. State why it may be sparse. A long-standing github account is a good signal.
Another point of concern: The word "references" appears only once, at the top. References are under utilized, and I include a line at the end of my resume that states references are available upon request. As I don't provide them by default so their contact info cannot be farmed.
Based on this article, I personally wouldn't bother submitting an application to this company.
This is an ad for a startup that is hiring a "founding engineer" with a "competitive compensation package". Are you so excited about the mission that you'll work toward it for free, anon?
Absolute bs. It's all about connections, the whole resume thing is bs. People in high positions are there because someone got them in. You need to be top 5% smart to make it there, and with SO MUCH effort and sacrifice to to achieve the same. Capitalism rewards entrepreneurship.
Basically go to an Ivy League school and you are set for life?
Please don't tell me society works like that -- its extremely cynical and it doesn't motivate people to work hard for opportunity-- life becomes based on nepotism or whate college/frat you went to as defining your life.
Obviously not everyone has the capacity to do some jobs -- you can't turn an Amazon warehouse worker into a ML engineer in a year.
Let's not forget that HN is a bubble of elite coders/educated thinkers in the top 10 percent of income, education, and intelligence distribution in society anyways. I feel you are inflating element of artificial scarcity without considering other perspectives.
No one reads resumes. At best they skim them. They look at the shortest lines, which are usually where you worked and the job title. Name recognition makes a difference here, no matter how many people tell you otherwise. This applies to your college as well. But don't let it discourage you, it's more of a "if you have a big name there you get a boost but it's not a negative if you don't".
They skim for key technologies and then read the text around them.
They most likely will read the full text of the most recent job, so make sure that is the most detailed and interesting.
Your resume should talk about results. Don't say "Created a new CMS for the company". Say "Created a new CMS for the company in Python that resulted in an ~70% reduction in website update times, from 1 hour to 18 minutes."
If you do put a "skills cloud" on it, be ready to talk about them all. If someone had a skills cloud I would immediately look for the most esoteric skills and dive deep on it in the interview (after Googling it myself) to see if you were BSing or not. If you really know that skill, you should know more than what I learned in five minutes of searching.
All this applies to your LinkedIn as well, which you should keep up to date, so that if there is a job you want but don't want to spend the time applying, you can just send them your LinkedIn. :)
Edit: Forgot to mention, as pointed out below, that your resume also drives the interview, so while some of what you write won't be read to get the interview, you still want it there as a place to jump off during an interview. Always better if you can drive the conversation towards your most positive qualities, which is easier if they are in your resume and the interviewer asks about them.