A helpful tip for finding a new job that uses technologies you don't have professional experience with, but you want to learn...<p>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.<p>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.<p>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.
I'm getting pretty tired of seeing 5 ("Establish and showcase an online presence").<p>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.<p>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.)
> Avoid ‘false accomplishments’. These are your responsibilities, described in the past tense. Until you’ve shown an impact, it’s not meaningful.<p>That's just wrong. These are talking points and are the basis for your "experience", which is important to discuss.<p>> 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’.<p>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).<p>> Omit the Summary and Objective sections. In 9 cases out of 10, summaries and objectives are not impressive.<p>It's not supposed to be impressive, it's supposed to be informative and a talking point.<p>> Use modern fonts.<p>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 <i>gasp</i> copy-paste it (like web forms and other large-company-process-nonsense) in an intermediate form. Don't be an ass.<p>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.
As an engineer I’ve resigned to making my resumes simple text files written in monospaced Menlo with manually wrapped columns at 80 characters. Very little adjectives are used, I stick straight to the facts.<p>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.
You know, if a resume came my way that was in comic sans I’d definitely read it, thinking “here’s a wiseass who’s confident in their abilities. I’d probably like working with them.”
<i>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’.</i><p>How many people are actually in positions to know how much revenue a feature of theirs brought in?<p>Unless I'm supposed to read between the lines and it's actually telling me to make something up.
> <i>Led the development of [X] feature, integrated it across [Z] products, resulting in extra [Y] in revenue</i><p>The example isn't apt. "<i>[Y] in revenue</i>" has no connection with the engineering function, "<i>[Y] in revenue</i>" is a responsibility of the product, marketing and sales functions. (This then contradicts pt. 3: <i>"Avoid false accomplishments"</i> of the article)<p>I'd wager technical hiring managers would be more interested in technical metrics (QPS, incident response times, etc.) than business metrics (revenue, MAU, etc.)
Re: ‘Your potential employer will objectively evaluate your skills and knowledge during the technical interview or a test task.’<p>Please remove the word ‘objectively’.<p>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.