A helpful tip for finding a new job that uses technologies you don't have professional experience with, but you want to learn...
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.
This is blog post worthy, as I think this idea could fleshed out. Here are some questions in no particular order of importance, just curious (and showing some evidence this could be fleshed out):
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).
That's a good idea. I think a blog post explaining the strategy further could be helpful for a lot of devs.
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.
That's exactly what I'm going/trying to do. I have around 12 years of experience as backend dev (PHP, SQL, queues, rest apis, e-commerce, docker - so basically whatever needed in the given company). I tried to apply for a Java (Spring Boot) position, but so far doesn't work. I sent few CVs already, but an answer is always no because of "lack of commercial experience".
Although I say know Java 8 a bit, and basics of Spring Framework. And also being ok to have 30% salary cut.
I'm getting pretty tired of seeing 5 ("Establish and showcase an online presence").
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.)
It is also the reason why we have about 695135 copy/paste blog posts on how to train a neural network on MNIST.
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.
Playing devil's advocate: one trait that is highly desirable in a hire is the ability to explain a technical topic to others. Maintaining a blog with basic explanations serves a similar purpose to a portfolio, but for teaching rather than for project-building.
This is like telling unattractive people to shower and get a haircut if they want to find a partner. Sure, it only works at the margins, but it's actionable and beats doing nothing.
This is because Tech Recruiters are not Interviewers. You first need to pass the Recruiter filter. Tech recruiters are (and I quote) looking for "honey holes" https://www.youtube.com/watch?v=lvpByue1M4E such as GitHub and StackOverflow. There is even a cottage industry of Tools that will Index developers on their public profiles, nowadays.
(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)
It is both truly helpful, and unfair nonsense at the same time.
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.
While that's true for people who have a traditional education from a good university, an established network or live in a tech hub or have the ability to travel to one, having an online presence is very helpful as an alternative to real-life networking for people who lack those things.
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).
It is probably nonsense if the whole point of "establishing an online presence" is to be marketable.
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.
Because most of the code you write at a previous job is not going to publicly available. So I have no other reference point as to your current skills.
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.
Eh, I’ve never really found that candidates I’ve interviewed with an established open source presence are any better than those without. It does not impress me as an interviewer at all anymore.
Agree. All it tells me is that you either worked at someplace that already open sourced something, or you have lots of time and don’t have hobbies outside of programming.
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.
Every bootcamp teaches it’s students to fake a Github. Unless a person’s repos are substantial original work now, it’s a strong negative signal. It tells me this candidate is trying to game the filters. Which they are.
> Avoid ‘false accomplishments’. These are your responsibilities, described in the past tense. Until you’ve shown an impact, it’s not meaningful.
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.
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.
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 usually try to submit a resume in html format. One time I applied for a job, and their online application rejected my upload, telling me it had to be PDF, Word, or plain text format. In frustration I copy/pasted the text content into an emacs buffer (not the html itself, just the text shown in the browser). I tried to pretty it up a bit, but forgot to save my final draft, so the interviewers got a resume that started like this:
;; 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.
What followed was extremely poorly formatted plain text.
Needless to say, I felt really embarrassed to find this out during the interview, and was baffled that the internal recruiter had even considered me.
One of the interviewers said he thought I was "trying to be all retro hipster".
My HTML resume has a print stylesheet. If someone asks for a PDF resume I tell them to print out the HTML page to PDF or do it myself and send it to them.
I wouldn't reject it straight away but I'd be wary, I would make assumptions:
- 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
Forcing your personal brand of silliness/quirkiness on someone before you have established enough of a rapport with them to know what they’re likely to find funny is a sure-fire recipe for annoying them.
I wouldn’t automatically reject such a resume but it would absolutely be a negative signal.
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’.
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.
Related question: How does one balance objective, numbers-driven reporting like this with the terms of an NDA? I imagine that most companies would consider the financial impact (or other similar statistics) of many features to be a trade secret.
Revenue is just one example, probably not a great one, the point is to have anything quantifiable. “Optimized web server” has a lot less punch than “reduced home page median response time from 10s to 1s”
> Led the development of [X] feature, integrated it across [Z] products, resulting in extra [Y] in revenue
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.)
Yeah I agree. This makes sense for a managerial role, not for tech roles. From the perspective of a hiring manager such a line looks like hiding behind the accomplishments of the team.
It's content marketing. I have no clue if the advice is any good. But that's how the game gets played, basically.
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.
Re: ‘Your potential employer will objectively evaluate your skills and knowledge during the technical interview or a test task.’
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.
I think you could send your resume with any of those fonts to a couple hundred recruiters, none of them will notice that it's not Times New Roman (and I don't blame them).
Yup, you can definitely see a web developer bias here - those are all popular webfonts because Google offer them free on their CDN, and it is easy to drop them into any website by just pasting in the CSS, but they are probably much less familiar to those outside frontend web development. They're also not necessarily the best fonts to use for the same reason.
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.