Practical Tips for Facelifting a Tech Resume
cvcompiler.com
cvcompiler.com
Say you want to learn Rust, but all your experience is in Javascript. Most recruiters will immediately filter out your resume if you don't have the keyword "Rust" somewhere in the document.
Before you start sending out your resume, spend a few weeks hacking on a Rust side project to learn some of the basics. Then on your resume, include a description at the top saying you're proficient in Javascript, but want the opportunity to work in Rust. Then include a "Side Projects" section at the bottom that lists your Rust experience.
I've landed 3 jobs that way, where I'm hired for my experience with X, but under the condition I will have the opportunity to learn Y. Otherwise, it's easy to get trapped working with the same tech at a new job, and your skills eventually become obsolete over time.
1. How many times did you try it?
2. Why do you think it works?
3. How do you find companies that have both technologies?
4. Have you seen a difference in the willingness to let you learn the technology that you'd want to learn?
5. Do you know of times when this approach failed, if so why?
6. Are you of the opinion that if you'd spend 5 years working on JS for 100% of the time vs 5 years 50% of the time and 5 years 50% of the time on a technology that you'd like, that you would be as experienced in JS in both cases? Even if you're not, could people prove that you're not? Should you just say you've had 5 years of XP with JS?
7. Are there moments when this approach is strictly worse compared to a traditional approach despite it not failing, if so why?
8. Are there strategies that synergize well with this approach? Are there strategies that diminish the value of this approach (aka work against it somehow)?
Alright, brainstorm time is over. I'd read your blog post about it, or having an email discussion would be awesome too (my email is in my profile, if you think it'd be fun).
To be frank though, I really don't have time at the moment. My typical blog post takes a few days to write, and I'm completely swamped with work for the next couple months. Like 12-15 hours a day, no life sort of thing...
With that said, I'd be open to chat with you or someone else about it, and they could run with it on their own.
My email is hello --at-- michaelfrye.me
Why? It's substantially nonsense. Many of the best programmers I've worked with don't do, or don't showcase, side-projects. And why should they? They've got families and other interests.
Who wants to be stuck in front of a computer all the time? (He said, ironically, whilst typing a HN comment on a Sunday evening.)
Apart from just the code itself, having side projects is a good sign of valuable, non-technical skills. Such as intellectual curiosity, ability to start/finish things, and if it's a collaborative open source project, can play well / collaborate with others.
People think that somehow interviewers or hiring managers are going to dig through some random repo and assess it, but frankly there’s no time nor motivation. The most I’ve ever done is click some links, and see if the repo is just 3 files, or if it’s more substantial. There’s just not any time for anything more, and it’s all going to become clear during the interview anyway.
It is not nonsense if you are genuinely interested in participating in those online activities (or happen to enjoy contributing to some open-source projects).
And if you do participate, you will leave an online trail that will help your potential interviewer to get to know you better (what technologies you actually know and how deeply; what your coding style is; how good you are at writing code in general; that sort of thing).
Of course, much of that can be established during an interview. But every additional data point helps to better assess the candidate.
So the point is, it’s not that they should, but it helps if they do.
It is an advantage for those who can afford to have side projects. Those who have other obligations, can't afford to spend time on unpaid work, or are good at the job, but not passionate about it, are at disadvantage.
(I ran into that video while I was searching for "tips on searching for specific source code fragments on GitHub" and this title matched, and it was not what I thought it is :D)
Whenever you see a lot of "Hello world!"-esque tech posts on how to do something, you can safely assume that it's 95% about building a online presence / reputation, and 5% about being helpful to the beginners.
I love good tutorials as much as the next person, but this constant CV-building nonsense is getting tiresome.
For someone from a developing country, changing careers or looking for remote work, an online presence can provide them with opportunities they would not otherwise be able to get. Of course, that online presence should actually have something substantial and probably shouldn't take the form of yet another basic tutorial blog post.
Also, there's no reason why a programmer's online presence should be only about side-projects or programming. Running a website related to one of your other hobbies is a perfectly acceptable way to provide a conversation starter (which is all an online presence is doing most of the time, anyway).
That's just wrong. These are talking points and are the basis for your "experience", which is important to discuss.
> Enrich your resume with numbers and accomplishments. Instead of ‘Was building a web application with [X] and [Y], write ‘Led the development of [X] feature, integrated it across [Z] products, resulting in extra [Y] in revenue’.
You probably don't know the revenue at a company of any scale larger than 10 people. More importantly, these numbers likely mean nothing when applying at a different company (even if it's the exact same position in the same industry).
> Omit the Summary and Objective sections. In 9 cases out of 10, summaries and objectives are not impressive.
It's not supposed to be impressive, it's supposed to be informative and a talking point.
> Use modern fonts.
Use courier or some other common plain text fixed-width font. Format it as if it's being read like that, since someone may have to print it out and hand it around and maybe gasp copy-paste it (like web forms and other large-company-process-nonsense) in an intermediate form. Don't be an ass.
Having interviewed hundreds of times and been interviewed hundreds of times (I keep lots of resumes), I would not recommend this blog post as a guide.
People are stunned when they pick up my single page resume and see how simple and straight forward it is. In a time when so many people are making wacky embellishments and cover letters to stand out, here’s a page filled with dense information and a promise to not waste any time.
- They don't even know it's not professional, which seems a basic thing to me. Are they socially unaware? - They know it's not professional and did it to have a laugh with friends ("the face the HR must have made hahaha")? - They try to make a statement "form doesn't matter, only skills do" which I do not necessarily agree on
I could also make charitable assumptions but my point is that it's definitely a risk
I wouldn’t automatically reject such a resume but it would absolutely be a negative signal.
I could imagine using a resume with a wonky font to elicit signal from the employer side.
;; This buffer is for notes you don't want to save, and for Lisp evaluation.
;; If you want to create a file, visit that file with C-x C-f,
;; then enter the text in that file's own buffer.One of the interviewers said he thought I was "trying to be all retro hipster".
I got the job.
How many people are actually in positions to know how much revenue a feature of theirs brought in?
Unless I'm supposed to read between the lines and it's actually telling me to make something up.
The example isn't apt. "[Y] in revenue" has no connection with the engineering function, "[Y] in revenue" is a responsibility of the product, marketing and sales functions. (This then contradicts pt. 3: "Avoid false accomplishments" of the article)
I'd wager technical hiring managers would be more interested in technical metrics (QPS, incident response times, etc.) than business metrics (revenue, MAU, etc.)
I sometimes edit resumes for pay. They are typically very good resumes -- well written, few typos, etc. They still benefit from having a second set of eyes on them.
I'm also a freelance writer and blogger. I know all too well how hard it is to edit your own writing. It's extremely hard.
People tend to see what they intended to say instead of what they actually wrote, thereby glossing over all the typos. It's very hard to catch your own mistakes.
If you are in tech, you can probably afford to cough up a few bucks to have someone review your resume. If you can't, ask a friend or go to a Reddit sub that does this for free or similar.
But get some feedback somehow. Don't just do it all yourself.
Please remove the word ‘objectively’.
Employers have varying types of evaluation, none of which I would call objective. I think a company is doing fairly well if their evaluation is a (1) useful proxy for the work and culture and (2) updated on a regular basis.