What we look for in a resume
huyenchip.com
huyenchip.com
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.
Then follow up with the age-old advice:
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.
I do agree with all of your other points
And also, as you said, the resume drives the interview, so they are good jumping off points and that's why they are there.
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.
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.
Nice one
> 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.
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.
Mistakes can be golden.
Should I put this on resume and would it be in poor taste to quantify the results?
He just said:
>> that ended up being used to commit a (arguably) crime against humanity.
What about that makes you think that he knew what it would be used for?
"I'm the civil engineer who designed a large and complicated factory for the mass baking of ceramic products."
...
"I did not know the next government would start a world war and use them to gas Jews."
You seem to assume that everyone has perfect foresight. I assure you, even you don't have perfect foresight.
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%".
But if someone told me that they were a senior SRE at MindGeek, I’m inclined to hire them.
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.
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.
Same applies to resumes. They are impressive to recruiters, HR and often hiring managers themselves.
- 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.
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.
So put that in the resume. Say how you delivered it better, faster or cheaper than the next candidate in the pile would have.
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?
That isn't rewarded in all jobs, mind you, but it is something to look for when you have a choice.
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.
> 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.
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.
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'.
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.
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).
"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.
Two different hiring managers in this thread have already said this, but in case that's not enough here's another https://www.askamanager.org/2020/02/my-step-by-step-guide-to.... You might even want to spend some time with her whole section on resumes, she answers many of your other questions too https://www.askamanager.org/category/resumes.
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.
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.
"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%.
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?
This is after years of delivering LOB software to clients in banking, manufacturing, and oil & gas industries.
Ha ha ha ha!
Asking questions like "What data do you have to support this?" can often create a lot of enemies - including your manager.
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.
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.
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.
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.
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."
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.
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.
"resume for a 20-something who travels abroad and knows the rust"
It has many biases and false negatives. But the point is that you should know this going in and adapt accordingly.
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.
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.
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!
Currently hiring Java devs.
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).
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.
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?
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.
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.
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.
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.
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
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.
I sometimes notice people using LinkedIn for something else, but I don't get it. It's mostly a resume-hosting site for me.
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.
That cannot be true, getting through screening is a zero sum game.
Yea. That is called a zero sum situation.
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"
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.
I want someone who will just admit when they don't know something. It's a sign of great intelligence.
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.
That's the kind of person I'm trying to avoid. Someone who isn't honest about their skills.
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.
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.
So many good questions to spawn from that one line.
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
Particularly when they started out by saying they're "looking for reasons to say yes", not for reasons to say no.
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.
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.
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]
[0] https://jobs.lever.co/claypot/7b38b49f-baa4-42b6-a58f-bab653...
[1] https://jobs.lever.co/claypot/9c6fedbf-3c91-4a48-98b9-467d00...
That's a pretty specious conclusion.
Everyone's experience is different but on average, tailoring has better results than spam.
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.
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).
> 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.
https://web.archive.org/web/20230125042620/https://huyenchip...
So they're apparently not counting it against someone, which is good.
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.
Unless you are going against an entire culture, for example you want Fridays off but applying to high frequency trading companies.
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.)
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.
Not to take away from your point in any way. This discussion just reminded me of that and I realized the irony.
I personally wouldn’t care. I can see good reasons for both.
Remember, every hiring manager has different things they look for; and different criteria for accepting / rejecting a resume.
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".
Often you can figure that out from the job description.
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é."; …
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.
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.
But at the end of the day, software startups want hackers. And hackers know how to spell Java.
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?
Given that this is a forum and low stakes, I just find it rather amusing.
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.
> 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).
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.
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.
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".
- Making commits on github everyday for a year
- Making many pull requests to popular open source projects
- Show commitment!
- Spent 3 years traveling the world before Stanford.
Meanwhile, has no real technical commits/PRs on GitHub herself... ever. No streaks to speak of... ever. https://github.com/chiphuyen
This is such an elitist and superficial article.
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.
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.
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.
¹ 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)
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.
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.
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).
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.
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.
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 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.
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.
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.
I don't know if that's truly obvious from a candidate's POV, especially if they don't know the person reviewing their stuff
In what scenario does it? I am suggesting that such a scenario does not exist.
There are three types of people who might read your resume:
* people who are technical and will look at your code. (Likely, the author is in this camp)
* people who are technical and don’t have the time to click on your GitHub link
* people who don’t know what a commit is
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.
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.
We understand that not everyone has time to contribute to public discourse, so #2 is optional.
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.
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.
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.
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.
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 :-)
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 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.
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.
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.
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.
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
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.
That said, I agree that the advice is much less helpful for anyone who has significant industry experience as an ML engineer.
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.
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.
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.)
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.
- 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".
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.
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.
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.
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.
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
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.
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
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 wantI'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'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.
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 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")
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.
Ultimately, you have to decide if you actually want to work with the person you are hiring.
I don't quite get what you mean by degrees, university degrees? is being self-taught 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.
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.
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.
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.
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.
- I still read every resume
- I ignored the keywords
- I pretty much valued exactly what the author does.
This is just plain wrong. When doing interviews at my previous company, we always looked at their github repo if provided.
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.
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.
I’m surprised this needed to be explained.
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.
I’m surprised this needed to be explained.
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.
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?
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.
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.
S = Passing the software screening stage
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?
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.
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.
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.)
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.
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.
And it's good for people to post those things so you know what each group is looking for.
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.
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):
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.
This is... not true? Also not necessarily something to even select for in a corporate environment (even if you want to tell yourself that it is).
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.
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
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.
For the human eyes, emphasize job title, the company (basically a brand name), and key results at the position.
Emphasize your education if you went to an Ivy school or top state school, otherwise it won't hold much weight.
Ultimately it's a numbers game, if your resume gets in a stack with Ivy & FAANG holders, you are fucked, so apply more.
Another option is to side-step this stupid process, and get tight with a recruiter and networking.
More importantly, once getting into an interview, you will find the only thing they value is LC top 50, so practice those.
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.
Resume's get you interviews and interviews get you jobs.
Optimize as such.
Anyone can put keywords, metrics and effective processes.
I’ve never found a comp sci undergrad to have any trouble learning. Lack of passion, yes but this doesn’t translate to poor work performance.
Ultimately it boils down to how well the individual will work with the team and management. It’s more of a personality question.
A great resume and the person could be a dick despite being technically able.
Yes, but I am forced to include git to ensure that other companies won't throw my resume out for now listing git.
hahaha
ehh, metrics oriented CVs feel like bullshitting
>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"
I know it's not a very "scientific" and objective criterion, but it has never failed me :-)
And I note how, in the comments, people are taking a few lines out of context and going "Ha! Id never work here"
I recommend you read the damn artice and make your own mind
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.
Someone does not like DevOps/Platform Engineers.
It's literally as simple as using the exact phrases in the job description to (truthfully) describe your own accomplishments.
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.
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.