First, I love Always Sunny, so this is amazing. Second, could I get some perspectives on this:
> While senior engineers are individual contributors; the best engineers’ best work is rarely code.
Aside from technical non-code tasks, like diagrams, knowledge sharing, etc., presumably code is the reason an engineer is hired. I understand there are leadership responsibilities as you get more experience within an organization, however it seems common for organizations to push engineers towards more and more admin and business related tasks as they gain seniority. Is this common across all or most industries? I'm wondering what is the underlying incentive for companies to do this, is it the perception that younger people should do most of the contributions?
I studied computer science because I love coding and not even a decade into my career it feels I'm supposed to do something completely different I didn't train for and personally I strongly dislike. I kept moving towards more and more technical companies, but it seems there is no escape from this in the software industry.
There are two types of senior engineers. One is the type talked about here. Someone who loves to design and code, but wants to have more impact, and finds that guiding other engineers is a more effective use of their time. See the examples in the article: Creating a new RFC process, introducing a post check-in hook for security audits, setting up a new platform team that builds libraries for everyone else.
All of these things multiply the work of everyone else. They make what everyone else is doing faster/more effective/easier.
Then there is the other kind of senior engineer -- the one that can output well structured, efficient, self documenting, code quickly. The one that you give the thorniest problems and they surprise you with a solution a few days later. Solving things that junior engineers simply couldn't.
There is value to both kinds of senior engineers. The first kind is much more valuable though because most orgs aren't doing the deep tech that the second kind of engineer is good at solving.
Realistically you want a little bit of A and a little bit of B as well.
The best is a senior engineer who can spit out the skeleton of B for junior engineers to work on; at the end of the day, sometimes parallel workstreams are more effective, and relying too heavily on a senior engineer can create a bad bus problem.
> The best is a senior engineer who can spit out the skeleton of B for junior engineers to work on
That's what person A does.
Agreed that having a super senior engineers is bad for the bus factor (FYI people are calling it the lottery factor now, as in "what if they won the lottery and retired") but sometimes you don't have the luxury of having backup people.
That's silly though because even if they won the lottery they'd probably at least have an exit period while they sorted out their winnings, and you could potentially pay them to work a reduced schedule or something, especially if they like working there.
If I won the lottery I wouldn't stop working immediately, I'd give notice and could do some hand over.
Bus factor though - if a bus hits me I am immediately gone and people have to catch up without hand holding
The “lottery” framing is the normalized and gentle way of asking “What’s our plan for when Stripe / OpenAI offers them a $1M/yr Staff role but only if they start immediately?” Think about the great engineers you’ve met, and how many of them would say “Sorry, but no - my current team relies on me, and I should help them transition”.
Maybe this is a cultural thing, but here it's pretty well understood that people have notice periods built into their contracts. Absolutely no employer would be hiring any staff with any expectation that they be able to start the next day if that person is already employed.
The first sounds like an architect or engineering manager in disguise without the title (and probably without the pay), but probably gets to skip out on some of the more boring meetings
That leads us to wider communication problems for hiring:
1) pay is usually searched by title
2) job postings are also posted with titles
3) with those titles as ambiguous, you have to dig in to find out what kind it is
The link from title to pay and the confusion around it is advantageous to companies because it means calling someone a Senior Engineer, but giving them more responsibilities, still justifies a lower pay range
I'm the number two and must I agree, the need is punctual and there's quite some networking required to be able to reach to those corners of the (big) organization where they feel lost. It's almost always about some legacy thing and it's way cheaper to get me to fix and document it, right before thinking of rewriting/replacing.
It's not true everywhere but it's pretty much rewarded everywhere. Software engineering is pretty difficult to evaluate and managers will default to evaluating "soft skills" because they haven't looked at a PR in a decade. Also, the problems most organizations solve don't require much ability.
That said, I also do not think the author means admin/business related tasks, but non-"coding" things like software design, technical vision, etc.? You might want to look at earlier stage start ups that don't need the management/pseudo-management positions (if it fits your life). Warning that you'll have to jump ship as the startup becomes successful and you get pushed into non-technical roles. :)
Job levels are tied to the amount of business value one provides. At some point in one's journey, for most developers, they will hit diminishing returns in terms of what they can provide from just their hands on keyboard contributions.Thus at some point people will tend to either peter out level-wise or need to find ways to augment what they bring to the table in terms of coding.
As an example, senior devs can be spending time mentoring, teaching, and guiding the junior devs in their team/org. Bringing up those around them will often, again not always, provide more business value than what they could have done on their own in that time.
> Job levels are tied to the amount of business value one provides.
The other replies have told you already this broadly isn't true, so I will ask this: Do you have an example of a company where what I quoted is the truth? Normally promotions are almost entirely political, I'd love to see some examples (or even one) where this isn't the case.
Note that the examples of non-code output are ultimately still code - just not code written by the senior engineer. Part of what an effective senior person does is to take their own knowledge and wisdom, and externalise it in ways that let their colleagues take advantage of it without having to learn it from scratch.
One of the most obvious ways of doing this is writing reusable code. Maybe you know the ins and outs of reliably spawning a child process in OS/2; you write a spawn_child_process_os2 function which does it, so others can take advantage of it.
But there are less obvious, and sometimes more powerful ways to do this.
The example of an RFC process externalises the engineer's understanding of how to rigorously think through and effectively communicate large changes.
The example of security check-ins externalises the engineer's understanding of how to write secure code.
The example of a platform team externalises the engineer's understanding of all sorts of code and build details particular to the organisation.
The further up the ladder you go, the less this is true.
I tell people about a senior plateau - after this point, the growth gets smaller. Everything is just another framework, just another language, just another pattern. At this point, unless you are a spectacularly proficient programmer, there's a limit to how much further you are going to improve.
Further, as organizations grow larger, there are more implications to every extra feature. That is, all of the easy stuff is done and the hard stuff means a change in multiple parts of the system, introducing fragility and cross-team coordination.
In some cases, the effort in coordination outweighs the effort in code. And that's what I need a senior developer to do - can they understand multiple systems, work with multiple teams, or do they need engineering managers to figure it all out and give it to them bite-sized?
And that is the impact that engineering leaders look for - someone who can code faster than everyone else just means there's a giant bottleneck everywhere around them.
Good points. It makes sense overall. I'm wondering if the perception is that high level engineering doesn't have as much business value as lower level engineering that allows teams to work in parallel.
> Everything is just another framework, just another language, just another pattern. At this point, unless you are a spectacularly proficient programmer, there's a limit to how much further you are going to improve.
I believe this is mostly a business decision, although one that could be justified. In theory, systems can be built such that changes and updates are simple configuration changes, including new features. Another example is using advanced techniques to guarantee no bugs. So while any given feature could be coded by multiple teams of mid-level skill, it could also be coded by a small team of high level engineers. As the system matures the cracks become visible and unless there are sophisticated techniques, codebases tend to deteriorate and that introduces otherwise unnecessary business costs to fix issues or even build a new system. The main reason I can think of why this is an accepted "sacrifice", is that a team of high level engineers cannot be as transparent as multiple teams with lower level engineers and managers. High level engineering is often opaque to everyone except others that have the knowledge.
> And that is the impact that engineering leaders look for - someone who can code faster than everyone else just means there's a giant bottleneck everywhere around them.
So yes, this makes sense but I think it's only a bottleneck if others are not as technically proficient. Speed comes as a result of more technical knowledge, and it seems to me at some point software companies are cutting that off in favor of using that experience to get everyone else up to speed, instead of continuing to leverage the direct skillset and building teams of highly proficient engineers, which in my opinion would deliver exponential business value (by coding sophisticated systems that can do virtually anything).
> In theory, systems can be built such that changes and updates are simple configuration changes, including new features.
Taken to the extreme, that's a low code platform. However, the complexity I am speaking of is the intersection of what a product should do today, what it does do today, what it should do tomorrow, and what technical debt prevents this from being obvious.
(For example, if the system has grown in a way that what was one team is now four and they are all trying to work in an intermingled codebase that made sense in a smaller organization.)
The solution may be 1,000 lines of code, but it takes the analysis from someone who provides a 1,000 line rather than a 10,000 line solution. That 1,000 lines might even be obvious once the problem is defined.
A senior developer, in this case, is someone for whom the mechanical translation of an idea to code is not the limiting part.
> So while any given feature could be coded by multiple teams of mid-level skill, it could also be coded by a small team of high level engineers.
That's entirely true. However, there are more organizations than high level engineers. And how do you manage to build those high level engineers if all we (as an industry) do is keep hiring from a small group?
> And how do you manage to build those high level engineers if all we (as an industry) do is keep hiring from a small group?
Right, scaling teams would be a problem. The alternative would be a company entirely led by engineers since most projects would eventually become too complex for others to manage. Great points, thank you.
I hear you. The so-called (full stack) jobs they have you doing everything under the sun not necessarily because you are proficient at any given assignment but because you can identify risks and bad practices quickly out of experience. The worst the job the more experience developers they need. I only once had a job where we were doing things right. The customer received our solution and it was so good, the customer said: "This is great, your solution is well put-together and well documented, your API's work out-the-box as expected, and they are fully tested. We can take it from here, thanks". Layoffs started a month later.
That's a really good point - I suppose you could rephrase to say "the work that's easiest to discuss achievements in the first round interview is rarely code"
Basically, it's hard to explain, even to a technical person, how hard a code problem was, even if your solution was brilliant. But being able to do stuff that isn't code is a really easy way to showing you can 'getting shit done'
I actually cover this in my follow-up post, around the difficulty in detecting strong technical proficiency in a short first-round interview.
If the title is software engineer, it is though. Solving business problems is not engineering. I get that at the end of the day it's about making money, but these expectations are not clear and the title ultimately reflects your expertise. I think part of the problem is the lack of standards in software engineer compared to other engineering, which have code of ethics and often require a license to practice. Those other engineering jobs are probably not doing management or solving business problems.
I personally know a senior mechanical engineer who’s basically doing what other posts are complaining software engineers end up doing — managing and solving business problems.
“Your job as a bricklayer isn’t to lay bricks. It’s to solve building problems.” If you’re actually looking for an architect or designer or salesperson or manager, hire them instead of berating developers for not doing all of those jobs at once.
Also in most countries devs don’t get paid enough to solve business problems. American tech wages are the exception.
That's funny. I studied information sciences because I loved systems but didn't want to get stuck coding all day and (no offense?) was less introverted than many of my fellow tech majors (to where even my professors would be surprised when I'd take on a coding role in a project because they stereotyped me as not fitting the part.). We studied things like documenting systems, workflows, use cases, project management, networking and introductory programming courses in databases and several coding languages. In theory it sounded great. But I the job market it's actually extremely difficult to get those code-adjacent jobs when you don't have coding experience.
Would you rather the person making the decisions about the code you write be a developer too, or not?
I’d rather be managed by developers, and you only get that by promoting developers into management.
You can stay an individual contributor if you want, and the pay is still very good. If it doesn’t work at your company, you can find others that will let you stay an IC.
A previous employer of mine established promotion guidelines based on the scope of someone's impact - individual, team, department, company, industry. But they never specified the direction of the impact.
> If you’ve worked more than 4 jobs in the last 4 years, you’re in the danger zone. Many companies will discard a CV quickly if we don’t think you’ll stick around until next year.
I mostly agree, but I think 2 jobs in 4 years? Probably fine. There's a line, and I don't think it's very clear cut.
I agree. Any given shortish stint can be for one of a million reasons. Two can just be luck of the draw especially in startup world. But at some point, things become patterns and, unless you're OK with the pattern, it's probably foolish to think that things will be different this time.
Personally, I wish we could stop judging individuals without understanding the context. There may be a million different reasons for someone that needs frequent job changes in a four year periods. Asking good questions to candidates will be far more informative and useful to the business than having a set of rules for dismissal or judgement.
Furthermore, the company is rarely/never accountable for swiftly laying people off individuals that may otherwise be excellent workers.
Frankly, if a company is discarding CVs based on perceived loyalty, then I perhaps those same companies to provide candidates with a contract reciprocates that loyalty via generous raises and job security.
> I wish we could stop judging individuals without understanding the context. There may be a million different reasons... Asking good questions to candidates will be far more informative
You won't even get to the "good questions" phase (i.e., get past the screening) if your resume is full of <1 year stints.
> Furthermore, the company is rarely/never accountable for swiftly laying people off individuals that may otherwise be excellent workers.
I've seen tons of resumes where people have done 12 companies in 10 years. think it's unlikely that was due to constant layoffs.
> Frankly, if a company is discarding CVs based on perceived loyalty, then I perhaps those same companies to provide candidates with a contract reciprocates that loyalty via generous raises and job security.
It's not about a noble ideal of loyalty. A person who leaves companies in 9-12 months is unlikely to have anything significant done in years (due to ramp-up time, etc). Not worth the risk to bring them onto your team, knowing their pattern is to be gone soon.
It's useful as a Bayesian prior. Repeated past behavior is a reasonable predictor for future behavior. There may be context that explains it, but hiring is really expensive and you want to get someone who will stick more than a year.
Leave a job per year for 4 years is at least a yellow flag to me.
> I wish we could stop judging individuals without understanding the context
"judging individuals without (enough) context" is basically what resume screening is, sadly. There may be 10 resumes that are otherwise equally strong, but one has this "issue". Then that issue might cost the opportunity to give more context. That's just how screening works.
I know this is true but it stings to see this as someone who has unfortunately done a lot of job hopping. It all "made sense" at the time, and looking back I wonder what I should have done differently, but at this point I really don't want to job hop anymore. This is how I explain my story to hiring managers:
* Startup ABC: 3 years -> Quit for a job that allowed me to break into a niche.
* Company BigCo: 9 Months -> Got asked to return to ABC as a leader, related to niche. "Great opportunity", didn't have a record of job hopping at the time, took it!
* Startup ABC: (Another) 3 years -> Got tired of the grind and quit for a job at Startup XYZ. Seemed reasonable at the time.
* Startup XYZ: 3 Months -> Toxic work environment, quit for mental health reasons. Requires the most explaining, but I felt totally justified and have since been vindicated by semi-public info about the org.
* Company HugeCo: 6 Months -> Got an offer from Meta that represented a 2x increase in comp (plus prestige of Big Tech). Hard to say no.
* Meta: 1 year -> Saw the writing on the wall my team was going to get crushed in layoffs and opportunistically jumped while I could. Ended up being correct about my team's fate btw.
* Startup JKL -> Been here for 4 months with no plan of leaving.
So all in all, in the last 4 years I've had 4 jobs, the "danger zone" as the OP put it. I don't have any desire to change jobs again soon. How would you view my story? Would you see me as a serial job hopper? Someone who can't commit? Or someone who made a series of reasonable choices in isolation that resulted in a disjointed resume? Most of this took place between 2019-2022 when the job market was on fire, and I don't necessarily regret it (after all, my salary tripled during this time). But I know how it looks.
I hopped jobs four times in four years between 1995 and 1999. Believe me, back then it really made sense (man, I miss the 90's). Although I've stayed everywhere I've worked since for at least three years (average five), this still comes up as a negative when I interview.
Definitely agree that the line is blurry. 2 in 4 years is fine, especially in 2023 when the most recent short stint can be explained by widespread layoffs
Whilst nice and settled now, I've had a pretty patchy history largely as a function of the sector I used to work in.
That said, doing recruiting, I tend to look at the longest stretch. If someone's not chalked up 1.5ish years in one organisation that's definitely a flag.
How does a hiring manager know that a resume was created using LaTex? I downloaded the author's PDF resume and it pretty much looked like any other PDF.
If you've used LaTeX a lot it has a distinctive look.
I actually write my CV in markdown and use pandoc to generate a PDF from that, but pandoc uses LaTeX to produce PDFs and I've had interviewers comment on it.
Nope, I think I have about 2 lines of actual LaTeX, second is to ensure the pagination is correct. Otherwise I just let it use the defaults for headings etc
They won't--it's nonsense. It's something you can point out if you get a screen or interview. But in my experience (and I like LaTeX and the notion of programming with neat markups for documents a lot) it just makes it hard to adapt if someone wants another format (HTML, Word or whatever) and is more of a "quirk" than a positive.
It was immediately obvious to me that it was written in LaTeX because of the font. Sure, you could use Computer Modern without LaTeX, or use LaTeX with a different font, but that's pretty uncommon in my experience.
You can also check the pdf metadata and see:
Creator: LaTeX with hyperref
Producer: pdfTeX-1.40.24
This rule only applies to a certain percentage of people, but I've benefited from it as well. For my first internship, I later found out that the only reason they interviewed me was because I used LaTeX. On paper, I was a generic student, but using LaTeX for my CV made me stand out.
I think it creates an unconscious bias. If you've gone to university and read some papers, chances are all the papers were written with LaTeX. You spend hours reading and re-reading these papers and it creates an unconscious bias where you read things in the font more carefully because you're used to the content being insanely dense.
The typeface is Computer Modern, which is an absolute giveaway for TeX.
Personally, i find the use of LaTeX a small red flag. Using it certainly does send "a subtle but clear message", but it's not that you love software engineering, it's that you're willing to waste time fiddling around with abstruse technical stuff rather than doing something useful.
That is such an awful take. There are so many professional-looking LaTeX templates online, associating it with "willingness to waste time" and actually ditching a candidate shows that you likely don't know how to recruit anyway.
It's the least painful way to create a high quality PDF. And "fiddling around with abstruse technical stuff" (not that I agree with the characterisation) is something probably 80% of HN enjoy.
For me I would have to buy/pirate and install Windows and buy/pirate Office. Or make a Google account and learn to use Google documents for the first time. Both of those are companies I think are unethical and will violate my privacy. Libre Office doesn't make documents that look nice to me. I used LaTeX for hundreds of hours at university so it is really not hard to me. The laziest option to me is definitely LaTeX, and I am a lazy person that doesnt like to waste time fiddling around with abstruse technical stuff
What they mean is that you should use the Computer Modern font, which causes everyone to assume that you used LaTeX (and then were too lazy to pick a non-default font).
"You based your resume tips on a sexual grooming chart?"
"As a joke!"
"I'm gonna go work somewhere else..."
I know cultures are different in different places, but in corporate America this post is all red flags. Always Sunny is hilarious, but I sure wouldn't want to be sitting in HR explaining "the implication" to someone who has never seen the show.
Many successful managers are people who blindly follow processes without understanding or caring why they're doing stuff. And many companies (and especially government) want wind-up dolls, not mavericks who think for themselves.
Sorry if that came across badly. I'm fairly new to blogging and still trying to strike the right tone with my content - trying to get a decent balance of informative and entertaining.
If it helps, I'm working on a 6-part series about unit testing with the new asynchronous features in Swift that's dry as fuck
I didn't read the article (so hopefully you aren't advocating something nasty), but will give you a piece of advice I have read somewhere a long time ago which is attributed to Bill Cosby (I know!) and has helped me immensely.
`I don't know the key to success, but the key to failure is trying to please everybody.`
So write with your own voice. Maybe you will rub some people the wrong way, but that is the path you should follow to resonate with your target audience.
Get the hiring manager on a boat with you on international waters. Then they'll have to hire you... because of the implication.
yeeaah, this post is simultaneously hilarious (because the show is hilarious) and also demonstrates that the author is more interested in being edgy than promoting an inclusive environment for people who aren't tech bros.
This speaks to company culture, and to be fair, the more inclusive end of the spectrum isn't a given. There are plenty of companies like Kraken and Basecamp that have made it known they value just focusing on work rather than identity politics, and the author is waving a flag that signals he's part of "their tribe".
To some companies and people (such as myself) this flag happens to look red, but I don't think you can generalize to corporate america, because I think more companies are more interested in cultural homogeneity and having their worker bees looking similar and falling in line than they are in celebrating individuality and promoting diversity/inclusivity in their workforce. Even if most don't make this as explicit as Basecamp/Kraken.
I think it’s worth reading this post as a championship level ecosystem parasite getting his host to spread his resume widely within the ecosystem. If the message wasn’t itself a strong advertisement not to do business with this person, I’d suggest it doesn’t belong here, but as it is, this post is a valuable community service.
This seems like a wild overreaction to me. The author just used the DENNIS system as a humorous starting point, but the advice doesn't have anything to do with manipulating women. I'm not sure how inclusion or diversity applies at all -- this isn't a corporate learning presentation, it's a blog post. He's allowed to reference a sitcom.
Frankly, your comment also reeks of the tribalism that's pervading modern political thought. Because he referenced a risqué joke from a sitcom on his blog, that means he's a "tech bro" who's anti-diversity? Come on.
Perhaps it's a bit harsh. I wouldn't judge anyone for joking about the DENNIS system in private. Blogging is a public platform though, and someone who is a hiring manager sharing their DENNIS system on a public platform with an explanation of why it's a useful thing seems like exactly the type of thing that would put some people on edge.
This is the culture war I'm talking about, there are different camps, and while I understand why some people want to be in the camp where joking about things that upset "sensitive" people is just fun and games, I think there are also a lot of people who see it as inappropriate in a professional context, and those kinds of jokes can feel exclusionary to them.
I'm really not trying to say anyone is right or wrong here, just that my own preference is to work in environments where most people who would lean towards passing up an opportunity for a joke that might make some group of people uncomfortable. I really hope you can similarly understand that.
My point was that this is _not_ a professional context. It's a personal blog. This would be inappropriate if he were giving this talk at his job, but... he's not. So I'm not sure how you can make any assumptions about how he behaves in a professional setting.
Celebrating individuality and getting offended at this blog post are mutually exclusive. There is no individuality without being offensive, because everything is offensive to somebody.
Why would you have to explain that in an interview? How would that conversation even happen? First they would have to ask you to explain the process of improving your resume, then you'd have to get into a conversation about how you read some tips from a blog post, then you'd need to tell them the blog post used the DENNIS acronym for humour, then explain the DENNIS system in its always sunny.
There's a really tiny niche case where someone might notice or, if you point it out, be impressed or amused and have some say in the hiring process, but these will be weird rare situations that you can't predict anyway. I think you should do your resume with your most comfortable tool, and that might be LaTeX (in which case you can expand on it) or it might be Google docs and you know what? That's a pretty common documentation skill to want to have, too.
Is LinkedIn often used as a resume? LinkedIn to me is a social media platform. At least in the software companies I've worked for, and applied to, I've only ever seen actual resumes around.
Effective communication is absolutely something I'm looking for in a candidate. The ability to communicate clearly and succinctly in writing is critical. I've worked with far too many people who'll respond to a question with paragraphs of narrative and reasoning and background information without actually giving a clear answer to the question.
I don't have a LinkedIn, and it doesn't let me view a profile without an account, which forces me to pass on applications that don't have a CV attached.
I de-emphasize lists of languages and technologies but there's a reason to put them there, and that's for searching and indexing. When I'm looking at a resume I want to see concise and accurate descriptions of accomplishments at the beginning, but I don't think it's a detriment if somewhere there is a list of technologies.
Just make sure that everything on your resume is justified and you're able to answer questions about it. Don't put SQL if you can't answer interview questions about it.
I thought N: Name Recognition was going to go in a different direction. Frankly, what makes a bigger difference than having a known company on your resume (though that probably helps with respect to big Tech companies with known difficult interview processes, albeit for mostly the wrong reasons) is N: Networking. Getting a job through people I've known has worked for me since the last century.
> Getting a job through people I've known has worked for me
Maybe I'm the odd one out, but I've worked at 10 different places since 1992, and I've gotten roughly half through referrals and the rest through recruiters/monster/linkedin/etc. By far the more pleasant experiences have been the "cold" ones that I didn't get through a personal referral.
I'm sure it varies. But the three different places I've worked since the mid-80s have been (post-grad school recruiting) through personal contacts. But then that's a lot different from 10 jobs in 10 years.
For some reason, networking seems to be a dirty word in tech. I went through the same rigorous tech screening as anyone else would for a recent job, despite knowing from previous work experience a colleague that I would be working with in the new position.
I understand wanting to be able to cross your Ts and dot your Is, but why not save everyone a boatload of time and just go off a recommendation? I ended up getting the job of course but it wasn’t without jumping through hoop after useless hoop. It’s like they don’t even trust the people they hire.
One is that having a network of people you know and have worked with gets conflated with "networking" events where people looking for work mostly uselessly pass around business cards or whatever the modern equivalent is.
The other somewhat related thing is that people who don't have or don't like to make connections see people waltzing into jobs and resent it. (In my experience it really can short-circuit the interview process, but my sample size is pretty small in that I've tended to stay with jobs a long time and the connections I had were at the highest levels.)
> The other somewhat related thing is that people who don't have or don't like to make connections see people waltzing into jobs and resent it.
I suppose then they don't make the connection that this person didn't just "waltz in", but instead was actually interviewing for this job for years prior by showing competence enough that their colleague felt comfortable vouching for them.
There is value in connections, far beyond getting jobs. People who are unwilling to do that are just hobbling themselves. Why let them hobble everyone else in the process.
Disagree with the latex point. If you are using latex just to put your resume together, you are wasting your time. Just do it in google docs or word. Anyone reviewing your resume won't even care unless you brought it up for some reason.
Why is it a waste of time? With LyX it goes really fast.
I use personally Asciidoc and asciidoctor-pdf to generate my resume as PDF. It's easier and less prone to funny formatting shifts typical of Word documents.
Speaking from experience, Applicant Tracking Systems (ATS) work only ideally with Word. Don’t use LaTeX unless you know for sure the individual receiving appreciates it.
Came here to say this. It’s definitely a bad idea given that so much first stage screening is automated these days. If your CV parses badly you’re just as likely to be silently binned by an algorithm. I say this from personal experience, and now having begrudgingly rolled my CV back from LaTeX to Word.
But regardless of whether you wrote your resume in word or LaTeX, 99% of the time you'd send it as a PDF, correct? So are you saying LaTeX pdfs will parse worse than Word PDF's in automatic systems?
What I am saying is when I last ran this experiment a few years back word .doc formatted files (didn’t check .docx) returned the most calls from recruiters in comparison to .txt or .pdf or .html.
I don’t know but I’ve noticed too. For me it’s a feature, I’m invisible to companies that use shitty ATS software where I likely would enjoy working anyway.
Naw fuck that. LaTeX is the shit for resumes. Doesnt take very long at all especially if you start from a template. Its actually easier then word because word is super unintuitive when it comes to formatting spacially.
It's definitely a case of, me and probably 1% of hiring managers are super opinionated and will be massively biased towards it, and the other 99% who aren't nerds will just think I used a nice template
agreed that I don't think it makes you stand out particularly just by virtue of using latex, but it does look nice, typically much nicer than most word templates. And it is also much easier to get looking consistent and well organized imo.
I used to have a flow where I wrote my experience in a master yaml file, then when I applied for a job I'd copy the yaml, delete everything non-relevant, and then feed it into pandoc. It worked great and I could just paste everything into those terrible "enter it twice" web forms. I even had a git repo with my job experience and I'd make a commit after major projects.
Last time I was job hunting it occurred to me I could just dump all that info into a Pages document and do the same process with instant WYSIWYG feedback, which I now do.
How does it waste time? There are hundreds of templates you can use and they tend to look nice without much work.
I’ve once seen a résumé where someone meticulously crafted something out of multiple nested tables in Word - you could tell because the spacing was always a little different.
It really made me question their competency, not because proficiency in Word matters, but they obviously wasted so much time with something they had no idea how to do and could have just left out and the result would be better.
I don’t want to know what they’d do to the codebase.
While in undergrad I wrote a modular resume script that picked a set bullet points based on the tags I gave them, rendered those bullets into a LaTeX template, and then spat out the customized result with a PDF. With this I could quickly spin out slightly different resumes that showcase different tech stacks, emphasize/de-emphasize military service or defense contractor work, drop (or add) bullets that imply I was an older-than-usual grad, etc.
I still use the script out of habit, though I wouldn't write it now.
Latex is a shibboleth that will get you points in the minds of certain types of engineers looking at your resume. Its a bad signal to evaluate candidates on, but it probably does have some effect.
You don't need to use latex to benefit from this though. Just use computer modern.
Every resume I've ever touched that was set in Computer Modern was from an academic type that was headed back to school in a year or two. Didn't matter if they knew it or not, their head was still in that game. They always go back.
I make my CV with LaTeX (and compter modern) and a handmade template. I got an undergrad in business over a decade ago. I’m never going back to school.
I used to have a resume in fine-crafted LaTeX, and it even once led to a discussion with a designer interviewer about typography.
But I noticed that applicant-tracking systems tended to not know what to do with the PDF, and I started to suspect that some companies weren't actually seeing my resume as a result. So I redid the resume in LibreOffice, and using a boring layout intended to be parsed easily by lousy ATSs.
> I noticed that applicant-tracking systems tended to not know what to do with the PDF, and I started to suspect that some companies weren't actually seeing my resume as a result.
That’s a feature as far as I’m concerned. Companies that use these monstrosity ATSs that can’t be bothered to parse a valid PDF CV and that require hoops just to apply (create yet another account in their ATS, copy my cv into hundreds of text boxes, can’t proceed without a salary expectation or past salary history etc are places I want nothing to do with.
I had a sick 2, and for a second 3 column resume, and that always got mangled.
Even the single column LaTeX resume had challenges.
Never had an issue with MS Word. If I'm sending a resume to a person I know (e.g. met at a Linux User Group, etc.), I'll go with the LaTeX resumes, but otherwise you gotta get past ATS and that means MS Word.
I have my LaTeX resumé on GitHub, and I have a GitHub Action that rebuilds it on a PR, allowing me to see a "staging" version of it. Then it gets deployed to its final destination on merge.
Actually I've used my CV but also its deployment pipeline to sell myself!
Imho the problem with LaTeX CVs is that they all look bleak and the same because it is (on purpose) tedious to create anything except the standard format.
I needed a sample LaTeX vita file in the early 1980's. I had logins on various math department servers, so I searched from root on each machine, and decided to base my vita on David Mumford's vita source file.
That says something about privacy in the era. I felt that what I did was entirely in the spirit of the default file permissions. Various people were nevertheless horrified when they learned that this search was even possible.
LaTeX for your resume?! If someone sumgly sends me a .TEX resume I have to (struggle to) compile instead of a .PDF, then I'm deleting the email and never responding. Yeah, I know LaTeX, but you've totally over-engineered the solution to the problem of writing a resume, and you've already increased my workload instead of decreasing it, even before getting on the payroll! Hard pass.
I took this as meaning that it should be obvious from the layout that it was a LaTeX document, but I agree, this is not something that i've ever considered when filtering CVs.
Yeah, it's more a case of, "me and probably 10% of hiring managers are massively biased in favour of LaTeX if we see it, and the other 90% won't care either way"
Uhhh..probably you and .2% of hiring managers. I've never cared when hiring, and have never heard this advice anywhere but this post. No offense, but if it was as common as 10%, recruiters and bloggers would be suggesting it left and right.
10% is being exceptionally generous I think. Anecdotally I've never heard of a single manager getting a crap how your PDF was produced, and a lot of the hiring and recruiting agencies will probably end up snapping the data out of your PDF and converting it to some standardized format, so the Latex will be completely rendered out.
To me this feels like a case of a publisher passing on a novel because the author wrote it using notepad.exe versus vim.
Everyone seems to be missing the main benefit of using LaTeX: it creates professional-looking documents. That is its whole purpose. I use Adobe Garamond Pro in my LaTeX résumé, and while I'm sure nobody recognizes that it's LaTeX, the document just looks sharp.
Perfectly aligned paragraphs on the left and the right. Other packages produce ragged line ends and/or ridiculous spacing between words (Word’s justify)
> but I agree, this is not something that i've ever considered when filtering CVs.
As a proficient LaTeX user, this is the stupidest take I ever saw on resume tips. I mean, your skills and experience do not vary with the document system you used to generate your CV. Some hiring managers swear by MS Word templates, other hiring managers ask for Europass, others ask you to fill in a form and request a cover letter. It would be stupid to assess the suitability of any candidate on this sort of bullshit.
Oh, okay. I just see LaTeX as a math academics thing, about as useful and difficult as writing HTML by hand. Now, if someone had leveraged LaTeX in a real system or automation, I'd find that interesting.
> LaTeX for your resume?! If someone sumgly sends me a .TEX (...)
I'm not sure you got it right. You still have a LaTeX doc if you compile it to generate a PDF. LaTeX can have a very unique and peculiar look and feel that pops up to those in the know.
I don’t think that is the message the author is sending. He is giving you tools to better augment the outcome. But not every organization gets 1k applicants. Some do not spend money on recruiting tools or advertisement. Some people might find tex funny or entertaining. Just saying. It is not intended to tailor to everyones needs.
No one cares if you put your resume together in LaTeX. Hardly anyone working in the software industry even knows what that is.
The other tips are fine, but all pretty generic. Moreover "work for a big brand name company" and "don't do short stints" aren't exactly resume writing advice.
Fair comment. I did try to add tactical things someone could do in the short term to make it less "by the way you're screwed if you didn't do this", but I'll make sure to frame it more specifically in my next posts
I definitely notice if a resume is written in latex, and while I wouldn't hire someone solely based on that, it's definitely a slight positive in my mind. IMHO it shows they understand the value of visual presentation, using the right tool for the job, and aren't afraid to learn a new programming language.
This seems to be common advice. Whenever I'm reviewing resumes, I can always tell when someone's been given it because their past job descriptions are littered with "...causing a 30% drop in whatever" or "...thus doubling our blah blah blah."
Honestly, I've always found those to be pretty content-free. I have no idea if those numbers were actually measured or if you're just guessing. I have no way to know if that project was actually your idea or if you were just implementing someone else's initiative. I have no idea what the team was like and what your actual contribution to the project was. The numbers are meaningless without a ton more context.
Sure, I can ask about all of that context in the interview, but I'd do that anyway. It doesn't add anything (for me as a hiring manager, at least) to have it on your resume.
Agree with this to some extent - I was careful not to parrot the common advice of "use numbers as much as possible" because I always smell some level of BS. But qualitative stuff gives you enough to go on to ask about in the first-round interview.
> I have no way to know if that project was actually your idea or if you were just implementing someone else's initiative. I have no idea what the team was like and what your actual contribution to the project was. The numbers are meaningless without a ton more context.
is there anything that isn’t meaningless, then?
their idea of knowing X, Y and Z likely differs from yours, as well. what will you believe or trust from a resume?
(personally i don’t trust any specific element and just look for an overall tone, and then ask about the specific interesting bits.)
I wish there was a job board where the interview process only entailed actual context specific take-home tests (think create a real-time analytics board consuming an example internal API), instead of these leetcode games which I can memorize and then spew out like a mindless robot.
Once I sunk a day into a take-home test. It went well, and I got to chat with a manager for half an hour. They said they weren't interested with no added context. Setting aside that take-home tests favor people who have time on their hands, the time investment can be very asymmetric, and it doesn't scale for the candidate.
But that's just fine. "Meaning" doesn't have to be some big ol' thing. So the whole universe is meaningless; so what? Big whoop.
And in this big, empty universe, maybe all that matters is finding something beautiful, something rare, something brilliant and destined for greatness, something like... a candidate who can code a few lines worth of decent code on the spot.
The truth is, if you give the candidate a moderately realistic problem and a blank canvas, the first 5 minutes of watching their hands on a keyboard (or equivalent, if they don't have hands) will probably tell you 80% of what you need to know. If you know what to look for.
I find percents bad, hard numbers are much better.
- Automated process 'x', saving company x thousands/millions per year
- Automated process 'y', reducing engineering time from 1 month/year to minutes per year.
"Automated process 'x', saving company $10,000 per year" is meaningless without knowing whether $10,000 is a significant figure or a drop in the bucket. Also, if they paid you $100,000 to automate it, it'll be 10 years before they see a return on that investment, and by then your code/process/system may have been rewritten.
I'd much rather see percentages, and if they can want to clarify with hard dollar amounts, so much the better.
“The numbers are meaningless without a ton more context.”
Just keep thinking in this direction and apply it to any and all hoops you make employees jump through.
It’s the same with coding challenges, quizzes, and any other evaluation you give. They are meaningless without more context and the only way you can get those is working with a person for a few months.
* Why this metric and not another? How was this number related to the overall goals of your company?
* What was the initial benchmark for how much you wanted this number to change? Did you meet, exceed or fall short of this benchmark? What do you think was the reason for that? In particular, what did you learn about your org's benchmarking process from meeting, exceeding or falling short of the benchmark?
* What resources were required to make this number change? Who were all the people involved? Why was it logical for their involvement to be a part of this number changing? More crucially, were there any people not involved that, in retrospect, you wish could have been involved and why?
* Knowing what you did now, if we were to put you on a similar effort within our company, what do you think you would do differently and how much do you think that would have an impact on that number?
The bullshitters will quickly wilt under the pressure of not knowing enough details to give well thought out answers while the people who drove real impact will get excited to talk it through and lay out both what went well and poorly.
edit: A big part of what I'm looking for with "Impact is King" conversations is the ability to take ownership of impact even in the face of dysfunctional organizations because, surprise, all organizations are dysfunctional!
I don't care about the actual impact you made because that's driven much more by the environment you were placed in than your individual performance. I care that you have a good mental model on how to drive impact and that you can perform at a reasonable baseline where you're significantly above average vs peers at your experience level.
You have enough of these interviews with people across a range of experience levels and you kind of get calibrated to what to expect at however many years into a career. Usually you get a small group of people who are operating far and above the level of their peers and it's pretty obvious.
> I have no way to know if that project was actually your idea or if you were just implementing someone else's initiative
This is huge for all resumes, especially product manager resumes. I've seen some PMs get through interviews by talking in depth about their previous company's product, just to end up flopping on the job because they can't function without top-down hand holding.
These sorts of claims tend to appear on the lowest quality CVs I've reviewed, often with suspiciously round and large numbers that suggested guess work.
> It doesn't add anything (for me as a hiring manager, at least) to have it on your resume.
Sadly without it it doesn't get through the recruiter / HR before it even reaches the hiring manager. Recruiters will tell you to edit your resume and add all sorts of things also.
Ironically, "Separate Entirely" (from the D.E.N.N.I.S. used in the Always Sunny episode) was changed to "Short Stints are Dangerous". From my point of view, "Separate Entirely" is better advice and it's justified by the given advice of "Short Stints are Dangerous". I "separate" my ego from the process because I know I'm being judged by someone's arbitrary system. "Short Stints are Dangerous" is the irony because it's actually part of someone's arbitrary judgement system. (I also understand that my interpretation is different from the episode of this comedy show. I mean to present it with this other interpretation.)
Some of the advice is pretty good, so it's not worth throwing it all out. Just take each piece of advice in turn rather than all or nothing. The "Drive Initiative" advice is solid, especially in terms of discovering what you'd like to accomplish in your job.
No LaTeX. Use Word like a civilized person. Everything goes through an ATS now, and those like Word documents. Hiring managers, HR, and recruiters will thank you.
I don't think using LaTeX for the resume matters. I've been using Markdown to build my resume for ages, and I've seen resumes that are handcrafted HTML, and I've seen resumes that are just a text file. The format only matters as much as it display something about you (if you're a web developer/frontend person, you should have a high quality web resume) and how it affects readability. Otherwise, I don't care as a hiring manager / interviewer.
If LaTeX helps you get it done and lets you generate multiple formats easily, go for it. I use pandoc + markdown to generate mine, and it supports LaTeX inputs as well. Don't expect the person reading the PDF attached in the hiring system 10 minutes before the interview call to care whether you used LaTeX or not, or even to comment on it.
Several points are things that have nothing to do with writing a resume:
'Name Recognition' - You should have worked at FAANG or large companies.
'Short stints' - You should have worked for 1.5+ years at each job.
'Drive Initiatives/Impact is King' - You should be driving features and taking ownership.
Those all take years to cultivate and are things you would obviously add to a Resume if you could. I guess the point is to not add in any fluffy BS. The authors point seems to be that people who have impressive credentials are good candidates?
I did do my best on the re-drafts to try and ensure I was suggesting workarounds for the name recognition piece; but you're right that a lot of the points do boil down to "be very hireable".
Yeah no problem, I think every 'how to resume' article has a similar issue.
I have tried writing before and it is a huge pain so props for putting this together and getting it out there. Your style is fun and your writing is clear.
> In the recent round of tech layoffs, sometimes it’s unavoidable to have one or two shorter tenures - hiring managers are aware of this, and so this generally doesn’t count against you. But giving the appearance of job hopping in ‘peacetime’ is another thing entirely.
> If you’ve worked more than 4 jobs in the last 4 years, you’re in the danger zone. Many companies will discard a CV quickly if we don’t think you’ll stick around until next year.
I am so tired of this conversation. At this point, all I can do is shut up and be grateful to be rejected by these people if I ever have a spotty resume.
Regarding the Latex suggestion, how would someone know if it was created using Latex? I’ve looked at many hundreds of resumes and have no idea if any of them were created using Latex.
A company that cares about your whether your resume using latex is probably a company I would not want to work for. They would probably spend all day in meetings arguing about tabs vs spaces and other geek minutiae instead of business outcomes.
Hey, from one engineer to another, from a place of trying to be helpful, the resume looks very nice, but in the second sentence of your intro you write “use to” rather than “used to”.
258 comments
[ 3.4 ms ] story [ 294 ms ] thread> While senior engineers are individual contributors; the best engineers’ best work is rarely code.
Aside from technical non-code tasks, like diagrams, knowledge sharing, etc., presumably code is the reason an engineer is hired. I understand there are leadership responsibilities as you get more experience within an organization, however it seems common for organizations to push engineers towards more and more admin and business related tasks as they gain seniority. Is this common across all or most industries? I'm wondering what is the underlying incentive for companies to do this, is it the perception that younger people should do most of the contributions?
I studied computer science because I love coding and not even a decade into my career it feels I'm supposed to do something completely different I didn't train for and personally I strongly dislike. I kept moving towards more and more technical companies, but it seems there is no escape from this in the software industry.
All of these things multiply the work of everyone else. They make what everyone else is doing faster/more effective/easier.
Then there is the other kind of senior engineer -- the one that can output well structured, efficient, self documenting, code quickly. The one that you give the thorniest problems and they surprise you with a solution a few days later. Solving things that junior engineers simply couldn't.
There is value to both kinds of senior engineers. The first kind is much more valuable though because most orgs aren't doing the deep tech that the second kind of engineer is good at solving.
The best is a senior engineer who can spit out the skeleton of B for junior engineers to work on; at the end of the day, sometimes parallel workstreams are more effective, and relying too heavily on a senior engineer can create a bad bus problem.
That's what person A does.
Agreed that having a super senior engineers is bad for the bus factor (FYI people are calling it the lottery factor now, as in "what if they won the lottery and retired") but sometimes you don't have the luxury of having backup people.
If I won the lottery I wouldn't stop working immediately, I'd give notice and could do some hand over.
Bus factor though - if a bus hits me I am immediately gone and people have to catch up without hand holding
But sure, go with the "other" lottery.
That's why we called it a Truck number.
> Sorry, but no - my current team relies on me, and I should help them transition
as a reason to allow a transition period is setting themselves up for failure. Isn't that the kind of engineer you want?
Maybe this is a cultural thing, but here it's pretty well understood that people have notice periods built into their contracts. Absolutely no employer would be hiring any staff with any expectation that they be able to start the next day if that person is already employed.
Probably the more relevant framing is “what if person just suddenly quits/takes leave?” Which has a whole host of valid reasons for happening.
That leads us to wider communication problems for hiring:
1) pay is usually searched by title
2) job postings are also posted with titles
3) with those titles as ambiguous, you have to dig in to find out what kind it is
The link from title to pay and the confusion around it is advantageous to companies because it means calling someone a Senior Engineer, but giving them more responsibilities, still justifies a lower pay range
That said, I also do not think the author means admin/business related tasks, but non-"coding" things like software design, technical vision, etc.? You might want to look at earlier stage start ups that don't need the management/pseudo-management positions (if it fits your life). Warning that you'll have to jump ship as the startup becomes successful and you get pushed into non-technical roles. :)
As an example, senior devs can be spending time mentoring, teaching, and guiding the junior devs in their team/org. Bringing up those around them will often, again not always, provide more business value than what they could have done on their own in that time.
In many companies they aren’t tied to anything besides a meaningless title someone negotiates
How do we measure business value? Do all those new products that Google launch and kill off add value? But they create promotions...
It's more like the illusion of business value.
The other replies have told you already this broadly isn't true, so I will ask this: Do you have an example of a company where what I quoted is the truth? Normally promotions are almost entirely political, I'd love to see some examples (or even one) where this isn't the case.
One of the most obvious ways of doing this is writing reusable code. Maybe you know the ins and outs of reliably spawning a child process in OS/2; you write a spawn_child_process_os2 function which does it, so others can take advantage of it.
But there are less obvious, and sometimes more powerful ways to do this.
The example of an RFC process externalises the engineer's understanding of how to rigorously think through and effectively communicate large changes.
The example of security check-ins externalises the engineer's understanding of how to write secure code.
The example of a platform team externalises the engineer's understanding of all sorts of code and build details particular to the organisation.
I tell people about a senior plateau - after this point, the growth gets smaller. Everything is just another framework, just another language, just another pattern. At this point, unless you are a spectacularly proficient programmer, there's a limit to how much further you are going to improve.
Further, as organizations grow larger, there are more implications to every extra feature. That is, all of the easy stuff is done and the hard stuff means a change in multiple parts of the system, introducing fragility and cross-team coordination.
In some cases, the effort in coordination outweighs the effort in code. And that's what I need a senior developer to do - can they understand multiple systems, work with multiple teams, or do they need engineering managers to figure it all out and give it to them bite-sized?
And that is the impact that engineering leaders look for - someone who can code faster than everyone else just means there's a giant bottleneck everywhere around them.
> Everything is just another framework, just another language, just another pattern. At this point, unless you are a spectacularly proficient programmer, there's a limit to how much further you are going to improve.
I believe this is mostly a business decision, although one that could be justified. In theory, systems can be built such that changes and updates are simple configuration changes, including new features. Another example is using advanced techniques to guarantee no bugs. So while any given feature could be coded by multiple teams of mid-level skill, it could also be coded by a small team of high level engineers. As the system matures the cracks become visible and unless there are sophisticated techniques, codebases tend to deteriorate and that introduces otherwise unnecessary business costs to fix issues or even build a new system. The main reason I can think of why this is an accepted "sacrifice", is that a team of high level engineers cannot be as transparent as multiple teams with lower level engineers and managers. High level engineering is often opaque to everyone except others that have the knowledge.
> And that is the impact that engineering leaders look for - someone who can code faster than everyone else just means there's a giant bottleneck everywhere around them.
So yes, this makes sense but I think it's only a bottleneck if others are not as technically proficient. Speed comes as a result of more technical knowledge, and it seems to me at some point software companies are cutting that off in favor of using that experience to get everyone else up to speed, instead of continuing to leverage the direct skillset and building teams of highly proficient engineers, which in my opinion would deliver exponential business value (by coding sophisticated systems that can do virtually anything).
Taken to the extreme, that's a low code platform. However, the complexity I am speaking of is the intersection of what a product should do today, what it does do today, what it should do tomorrow, and what technical debt prevents this from being obvious.
(For example, if the system has grown in a way that what was one team is now four and they are all trying to work in an intermingled codebase that made sense in a smaller organization.)
The solution may be 1,000 lines of code, but it takes the analysis from someone who provides a 1,000 line rather than a 10,000 line solution. That 1,000 lines might even be obvious once the problem is defined.
A senior developer, in this case, is someone for whom the mechanical translation of an idea to code is not the limiting part.
> So while any given feature could be coded by multiple teams of mid-level skill, it could also be coded by a small team of high level engineers.
That's entirely true. However, there are more organizations than high level engineers. And how do you manage to build those high level engineers if all we (as an industry) do is keep hiring from a small group?
Right, scaling teams would be a problem. The alternative would be a company entirely led by engineers since most projects would eventually become too complex for others to manage. Great points, thank you.
That's a really good point - I suppose you could rephrase to say "the work that's easiest to discuss achievements in the first round interview is rarely code"
Basically, it's hard to explain, even to a technical person, how hard a code problem was, even if your solution was brilliant. But being able to do stuff that isn't code is a really easy way to showing you can 'getting shit done'
I actually cover this in my follow-up post, around the difficulty in detecting strong technical proficiency in a short first-round interview.
I think this is more common than you’d think.
Also in most countries devs don’t get paid enough to solve business problems. American tech wages are the exception.
I’d rather be managed by developers, and you only get that by promoting developers into management.
You can stay an individual contributor if you want, and the pay is still very good. If it doesn’t work at your company, you can find others that will let you stay an IC.
That's the cult at where I presently work. Engineer-led org.
I think my favorite were projects that just didn't have any metrics. Or that claimed to have metrics, but somehow they were never shared...
I mostly agree, but I think 2 jobs in 4 years? Probably fine. There's a line, and I don't think it's very clear cut.
> There's a line, and I don't think it's very clear cut.
is spot on. I would also say 2 jobs in 4 years is ok, but if you have nothing but two year stints - I treat that as a negative.
Furthermore, the company is rarely/never accountable for swiftly laying people off individuals that may otherwise be excellent workers.
Frankly, if a company is discarding CVs based on perceived loyalty, then I perhaps those same companies to provide candidates with a contract reciprocates that loyalty via generous raises and job security.
You won't even get to the "good questions" phase (i.e., get past the screening) if your resume is full of <1 year stints.
> Furthermore, the company is rarely/never accountable for swiftly laying people off individuals that may otherwise be excellent workers.
I've seen tons of resumes where people have done 12 companies in 10 years. think it's unlikely that was due to constant layoffs.
> Frankly, if a company is discarding CVs based on perceived loyalty, then I perhaps those same companies to provide candidates with a contract reciprocates that loyalty via generous raises and job security.
It's not about a noble ideal of loyalty. A person who leaves companies in 9-12 months is unlikely to have anything significant done in years (due to ramp-up time, etc). Not worth the risk to bring them onto your team, knowing their pattern is to be gone soon.
Leave a job per year for 4 years is at least a yellow flag to me.
"judging individuals without (enough) context" is basically what resume screening is, sadly. There may be 10 resumes that are otherwise equally strong, but one has this "issue". Then that issue might cost the opportunity to give more context. That's just how screening works.
* Startup ABC: 3 years -> Quit for a job that allowed me to break into a niche.
* Company BigCo: 9 Months -> Got asked to return to ABC as a leader, related to niche. "Great opportunity", didn't have a record of job hopping at the time, took it!
* Startup ABC: (Another) 3 years -> Got tired of the grind and quit for a job at Startup XYZ. Seemed reasonable at the time.
* Startup XYZ: 3 Months -> Toxic work environment, quit for mental health reasons. Requires the most explaining, but I felt totally justified and have since been vindicated by semi-public info about the org.
* Company HugeCo: 6 Months -> Got an offer from Meta that represented a 2x increase in comp (plus prestige of Big Tech). Hard to say no.
* Meta: 1 year -> Saw the writing on the wall my team was going to get crushed in layoffs and opportunistically jumped while I could. Ended up being correct about my team's fate btw.
* Startup JKL -> Been here for 4 months with no plan of leaving.
So all in all, in the last 4 years I've had 4 jobs, the "danger zone" as the OP put it. I don't have any desire to change jobs again soon. How would you view my story? Would you see me as a serial job hopper? Someone who can't commit? Or someone who made a series of reasonable choices in isolation that resulted in a disjointed resume? Most of this took place between 2019-2022 when the job market was on fire, and I don't necessarily regret it (after all, my salary tripled during this time). But I know how it looks.
Also, if you job hop a bit and then spend at least 2-3 years in a single job, you're totally fine. Nobody faults someone for hopping early on.
That said, doing recruiting, I tend to look at the longest stretch. If someone's not chalked up 1.5ish years in one organisation that's definitely a flag.
How does a hiring manager know that a resume was created using LaTex? I downloaded the author's PDF resume and it pretty much looked like any other PDF.
I actually write my CV in markdown and use pandoc to generate a PDF from that, but pandoc uses LaTeX to produce PDFs and I've had interviewers comment on it.
You can also check the pdf metadata and see:
Creator: LaTeX with hyperref
Producer: pdfTeX-1.40.24
This rule only applies to a certain percentage of people, but I've benefited from it as well. For my first internship, I later found out that the only reason they interviewed me was because I used LaTeX. On paper, I was a generic student, but using LaTeX for my CV made me stand out.
I think it creates an unconscious bias. If you've gone to university and read some papers, chances are all the papers were written with LaTeX. You spend hours reading and re-reading these papers and it creates an unconscious bias where you read things in the font more carefully because you're used to the content being insanely dense.
Personally, i find the use of LaTeX a small red flag. Using it certainly does send "a subtle but clear message", but it's not that you love software engineering, it's that you're willing to waste time fiddling around with abstruse technical stuff rather than doing something useful.
Yeah, having an easily versioned plaintext format is such a waste of time. So much better to deal with constantly changing GUIs instead. /s
Cough cough K8s/microservices cough cough jira cough
"As a joke!"
"I'm gonna go work somewhere else..."
I know cultures are different in different places, but in corporate America this post is all red flags. Always Sunny is hilarious, but I sure wouldn't want to be sitting in HR explaining "the implication" to someone who has never seen the show.
https://www.youtube.com/watch?v=THvCDn8mGwo
https://www.youtube.com/watch?v=GTKZ9Gyqiyo&t=29s
Anyone who read the article would see they're different in all but acronyms.
If it helps, I'm working on a 6-part series about unit testing with the new asynchronous features in Swift that's dry as fuck
`I don't know the key to success, but the key to failure is trying to please everybody.`
So write with your own voice. Maybe you will rub some people the wrong way, but that is the path you should follow to resonate with your target audience.
yeeaah, this post is simultaneously hilarious (because the show is hilarious) and also demonstrates that the author is more interested in being edgy than promoting an inclusive environment for people who aren't tech bros.
This speaks to company culture, and to be fair, the more inclusive end of the spectrum isn't a given. There are plenty of companies like Kraken and Basecamp that have made it known they value just focusing on work rather than identity politics, and the author is waving a flag that signals he's part of "their tribe".
To some companies and people (such as myself) this flag happens to look red, but I don't think you can generalize to corporate america, because I think more companies are more interested in cultural homogeneity and having their worker bees looking similar and falling in line than they are in celebrating individuality and promoting diversity/inclusivity in their workforce. Even if most don't make this as explicit as Basecamp/Kraken.
Frankly, your comment also reeks of the tribalism that's pervading modern political thought. Because he referenced a risqué joke from a sitcom on his blog, that means he's a "tech bro" who's anti-diversity? Come on.
I see what you did there
This is the culture war I'm talking about, there are different camps, and while I understand why some people want to be in the camp where joking about things that upset "sensitive" people is just fun and games, I think there are also a lot of people who see it as inappropriate in a professional context, and those kinds of jokes can feel exclusionary to them.
I'm really not trying to say anyone is right or wrong here, just that my own preference is to work in environments where most people who would lean towards passing up an opportunity for a joke that might make some group of people uncomfortable. I really hope you can similarly understand that.
No, it did not. The author linked his resume as an example: A PDF generated from LaTeX.
I'm not convinced resume editing is a skill correlated with anything I hire for.
Just make sure that everything on your resume is justified and you're able to answer questions about it. Don't put SQL if you can't answer interview questions about it.
Maybe I'm the odd one out, but I've worked at 10 different places since 1992, and I've gotten roughly half through referrals and the rest through recruiters/monster/linkedin/etc. By far the more pleasant experiences have been the "cold" ones that I didn't get through a personal referral.
I understand wanting to be able to cross your Ts and dot your Is, but why not save everyone a boatload of time and just go off a recommendation? I ended up getting the job of course but it wasn’t without jumping through hoop after useless hoop. It’s like they don’t even trust the people they hire.
One is that having a network of people you know and have worked with gets conflated with "networking" events where people looking for work mostly uselessly pass around business cards or whatever the modern equivalent is.
The other somewhat related thing is that people who don't have or don't like to make connections see people waltzing into jobs and resent it. (In my experience it really can short-circuit the interview process, but my sample size is pretty small in that I've tended to stay with jobs a long time and the connections I had were at the highest levels.)
I suppose then they don't make the connection that this person didn't just "waltz in", but instead was actually interviewing for this job for years prior by showing competence enough that their colleague felt comfortable vouching for them.
There is value in connections, far beyond getting jobs. People who are unwilling to do that are just hobbling themselves. Why let them hobble everyone else in the process.
I use personally Asciidoc and asciidoctor-pdf to generate my resume as PDF. It's easier and less prone to funny formatting shifts typical of Word documents.
Alles that you’re very technical, might even offer engineer any solution I want.
Hiring managers are usually not this kind of nerds.
Why won't a PDF generated by LaTeX get into the ATS?
Last time I was job hunting it occurred to me I could just dump all that info into a Pages document and do the same process with instant WYSIWYG feedback, which I now do.
I’ve once seen a résumé where someone meticulously crafted something out of multiple nested tables in Word - you could tell because the spacing was always a little different.
It really made me question their competency, not because proficiency in Word matters, but they obviously wasted so much time with something they had no idea how to do and could have just left out and the result would be better.
I don’t want to know what they’d do to the codebase.
I still use the script out of habit, though I wouldn't write it now.
You don't need to use latex to benefit from this though. Just use computer modern.
I bias against those resumes now.
But I noticed that applicant-tracking systems tended to not know what to do with the PDF, and I started to suspect that some companies weren't actually seeing my resume as a result. So I redid the resume in LibreOffice, and using a boring layout intended to be parsed easily by lousy ATSs.
That’s a feature as far as I’m concerned. Companies that use these monstrosity ATSs that can’t be bothered to parse a valid PDF CV and that require hoops just to apply (create yet another account in their ATS, copy my cv into hundreds of text boxes, can’t proceed without a salary expectation or past salary history etc are places I want nothing to do with.
I had a sick 2, and for a second 3 column resume, and that always got mangled.
Even the single column LaTeX resume had challenges.
Never had an issue with MS Word. If I'm sending a resume to a person I know (e.g. met at a Linux User Group, etc.), I'll go with the LaTeX resumes, but otherwise you gotta get past ATS and that means MS Word.
Actually I've used my CV but also its deployment pipeline to sell myself!
That says something about privacy in the era. I felt that what I did was entirely in the spirit of the default file permissions. Various people were nevertheless horrified when they learned that this search was even possible.
(And yes I won't quit my day job!)
To me this feels like a case of a publisher passing on a novel because the author wrote it using notepad.exe versus vim.
As a proficient LaTeX user, this is the stupidest take I ever saw on resume tips. I mean, your skills and experience do not vary with the document system you used to generate your CV. Some hiring managers swear by MS Word templates, other hiring managers ask for Europass, others ask you to fill in a form and request a cover letter. It would be stupid to assess the suitability of any candidate on this sort of bullshit.
Don't get me wrong, I would also not open a TEX file in the ~10 seconds I give each CV
How else do you write html? I haven’t used dreamweaver in 20 years by now.
It was clear. You even linked your PDF resume as an example. The GP's interpretation is just bizzare.
nobody is doing or suggesting the thing that you’re freaking out about.
I'm not sure you got it right. You still have a LaTeX doc if you compile it to generate a PDF. LaTeX can have a very unique and peculiar look and feel that pops up to those in the know.
The other tips are fine, but all pretty generic. Moreover "work for a big brand name company" and "don't do short stints" aren't exactly resume writing advice.
This seems to be common advice. Whenever I'm reviewing resumes, I can always tell when someone's been given it because their past job descriptions are littered with "...causing a 30% drop in whatever" or "...thus doubling our blah blah blah."
Honestly, I've always found those to be pretty content-free. I have no idea if those numbers were actually measured or if you're just guessing. I have no way to know if that project was actually your idea or if you were just implementing someone else's initiative. I have no idea what the team was like and what your actual contribution to the project was. The numbers are meaningless without a ton more context.
Sure, I can ask about all of that context in the interview, but I'd do that anyway. It doesn't add anything (for me as a hiring manager, at least) to have it on your resume.
is there anything that isn’t meaningless, then?
their idea of knowing X, Y and Z likely differs from yours, as well. what will you believe or trust from a resume?
(personally i don’t trust any specific element and just look for an overall tone, and then ask about the specific interesting bits.)
Invert a binary tree.
I think you just explained extremely clearly, why hiring managers aren't really into that sort of candidate.
Well, now that you mention it... no.
But that's just fine. "Meaning" doesn't have to be some big ol' thing. So the whole universe is meaningless; so what? Big whoop.
And in this big, empty universe, maybe all that matters is finding something beautiful, something rare, something brilliant and destined for greatness, something like... a candidate who can code a few lines worth of decent code on the spot.
The truth is, if you give the candidate a moderately realistic problem and a blank canvas, the first 5 minutes of watching their hands on a keyboard (or equivalent, if they don't have hands) will probably tell you 80% of what you need to know. If you know what to look for.
- Automated process 'x', saving company x thousands/millions per year - Automated process 'y', reducing engineering time from 1 month/year to minutes per year.
I'd much rather see percentages, and if they can want to clarify with hard dollar amounts, so much the better.
Just keep thinking in this direction and apply it to any and all hoops you make employees jump through.
It’s the same with coding challenges, quizzes, and any other evaluation you give. They are meaningless without more context and the only way you can get those is working with a person for a few months.
* Why this metric and not another? How was this number related to the overall goals of your company?
* What was the initial benchmark for how much you wanted this number to change? Did you meet, exceed or fall short of this benchmark? What do you think was the reason for that? In particular, what did you learn about your org's benchmarking process from meeting, exceeding or falling short of the benchmark?
* What resources were required to make this number change? Who were all the people involved? Why was it logical for their involvement to be a part of this number changing? More crucially, were there any people not involved that, in retrospect, you wish could have been involved and why?
* Knowing what you did now, if we were to put you on a similar effort within our company, what do you think you would do differently and how much do you think that would have an impact on that number?
The bullshitters will quickly wilt under the pressure of not knowing enough details to give well thought out answers while the people who drove real impact will get excited to talk it through and lay out both what went well and poorly.
edit: A big part of what I'm looking for with "Impact is King" conversations is the ability to take ownership of impact even in the face of dysfunctional organizations because, surprise, all organizations are dysfunctional!
I don't care about the actual impact you made because that's driven much more by the environment you were placed in than your individual performance. I care that you have a good mental model on how to drive impact and that you can perform at a reasonable baseline where you're significantly above average vs peers at your experience level.
>significantly above average
I don't mean this in a confrontational way, but I am curious how you establish what a reasonable baseline is.
This is huge for all resumes, especially product manager resumes. I've seen some PMs get through interviews by talking in depth about their previous company's product, just to end up flopping on the job because they can't function without top-down hand holding.
Sadly without it it doesn't get through the recruiter / HR before it even reaches the hiring manager. Recruiters will tell you to edit your resume and add all sorts of things also.
Some of the advice is pretty good, so it's not worth throwing it all out. Just take each piece of advice in turn rather than all or nothing. The "Drive Initiative" advice is solid, especially in terms of discovering what you'd like to accomplish in your job.
No worthwhile ATS system is going to have trouble parsing a PDF generated from LaTeX. This is a myth that just gets trotted about.
If LaTeX helps you get it done and lets you generate multiple formats easily, go for it. I use pandoc + markdown to generate mine, and it supports LaTeX inputs as well. Don't expect the person reading the PDF attached in the hiring system 10 minutes before the interview call to care whether you used LaTeX or not, or even to comment on it.
'Name Recognition' - You should have worked at FAANG or large companies.
'Short stints' - You should have worked for 1.5+ years at each job.
'Drive Initiatives/Impact is King' - You should be driving features and taking ownership.
Those all take years to cultivate and are things you would obviously add to a Resume if you could. I guess the point is to not add in any fluffy BS. The authors point seems to be that people who have impressive credentials are good candidates?
I did do my best on the re-drafts to try and ensure I was suggesting workarounds for the name recognition piece; but you're right that a lot of the points do boil down to "be very hireable".
I have tried writing before and it is a huge pain so props for putting this together and getting it out there. Your style is fun and your writing is clear.
> If you’ve worked more than 4 jobs in the last 4 years, you’re in the danger zone. Many companies will discard a CV quickly if we don’t think you’ll stick around until next year.
I am so tired of this conversation. At this point, all I can do is shut up and be grateful to be rejected by these people if I ever have a spotty resume.
Are these hiring managers in danger??
If some recruiter or department asks for a PDF, I tell them to print the page or figure out a way lol
It has probably been worded as such for about 8 years and no one has corrected it.