My regular readers (both of them) may remember that, at about this time last year, I was hired at Amazon. But this year, on January 18th, Amazon j...
For further actions, you may consider blocking this person and/or reporting abuse
From personal experience, probably the best single advice to getting hired in tech when it's overflowing with Amazon, Facebook, Google, and Microsoft laid off developers is to go vertical (i.e., proficiency in niche languages & platforms). I would argue that hiring managers get so many superstar resumes these days that your resume doesn't matter no matter how stellar it is because a ⭐ in a sea of 100k other ✨ is still just another ⭐.
Jobs are much easier to come by if you have a specialty. For example, you are a Solidity guru who can whip up blockchain apps in your sleep; or you not only know Lua, you are intimate with the Roblox flavor of Lua; or you have built e-commerce sites for big brands on the Magento, SFCC, or Shopify Plus platforms; and so on so forth. Be the surgeon's scalpel, not the Swiss army knife.
I don't disagree with your sentiment in any way. But I will point out that this highlights two competing (and possibly "equal") theories on how to make yourself valuable in the workplace. These theories are the "generalist" versus the "specialist". Neither approach is "right" or "wrong". But they both have benefits (and problems).
In the world of frontend devs, I'd argue that being a JS/TS/React "expert" probably makes you a "generalist". Because those technologies are massively used. So when you concentrate on those skills, you're concentrating in a fairly "generalized" skill set. The benefit to this is that there are a ton of jobs/employers out there who are looking for those skills. The downside is that there are also a great many other people who share your skill set and are competing with you for the same jobs.
If you concentrate on more "esoteric" endeavors (e.g., blockchain or Lua), you're going more down the "specialist" road. The benefit to this is that you have a very specialized skill that many others cannot match. The downside is that, at any point when you find yourself wanting/needing a job, there may not be a ton of options out there for you.
Years ago, I gained a lot of expertise working on Sitecore (a .NET CMS). Since that time, I've had soooo many recruiters reach out to me looking for someone with Sitecore knowledge/experience. In this case, it didn't really help me much because, honestly, I don't really like working in Sitecore. But it's definitely a "specialized" skill set.
To be frank, I don't know that either path is "better". They both have pluses-and-minuses. But this isn't meant to downplay your point. I get it. It can indeed be powerful to have that kinda "specialized" knowledge. But I don't know that either approach is a "solution" to the problem.
Regardless, I sincerely appreciate the insightful feedback!
Hi Adam, thanks for your thoughtful reply. The reason I commented is because after 20+ years in tech, I have noticed a stark pattern: I almost always get rejected for generalist roles that I apply for (even ones I spend serious effort on for the cover letter), and I never seem to have a problem getting offers for specialist roles that I didn't even apply for (they come via recruiters).
Again, this is just from my personal experience, but I know which camp I prefer: the specialist camp. It is more practical, for it facilitates landing a job in a relatively short timeframe, which can be a literal lifesaver if you are in dire need of money fast. Even if the specialist roles offered to you are not to your liking, it sure beats being unemployed.
Haha, I totally see your point. But I also think a key part of your response lies in "I almost always get rejected for generalist roles that I apply for" and "I never seem to have a problem getting offers for specialist roles that I didn't even apply for".
Whether you're going the specialist or generalist route, there's always a much better response when you're not the one trying to get their attention - but instead, they're coming to you. That's why the job market feels so different to me now. Because even though I'm swimming in the big pool of talent (meaning: JS/TS/React folks), previously I didn't have to go out and submit applications. Recruiters contacted me. And in those cases where I said, "Yes", they then promoted my resume/candidacy and I was far more likely to at least get an interview.
But now, the supply of recruiters blowing up my inbox seems to have mostly dried up...
Funny how a lot of what you've described matches my recent experience with the Software Developer job market here in NZ. Contract work has mostly dried up and while permanent roles are paying more than they used to (mostly due to inflation), contract work seems to be paying less. We've also had layoffs here. I myself got laid off last December and went from being in demand by recruiters to worrying about where I'd get my next contract. I eventually landed on my feet but it was a rough ride. Hope things work out for you too mate.
Take care Adam, i wish you the best and to find a fulfilling job as soon as possible.
Here in Europe those jobs ADR are the norm.
But we have everything with it: health care, life insurance, pension retirement, unemployment compensation...
Yes, this is a good point. Salaries in the US tend to be far higher. But the benefits are far lower.
Your experience mirrors mine. Not a FAANG employee but a specialist in a very narrow market: probably one of only 4 people in the UK who really know this niche product and are prepared to contract. Since Xmas the market has been just crickets... And I am in a recession-protected market of social housing.
Like you say, it will likely come back but whether it takes 3 months or 2 years, who can tell
Hi Adam. I love this article. I'm an entry-level web developer and I was wondering if you have any suggestions for someone like me who is entering the workforce. I also love your portfolio.
Entry-level is tough. Most places don't have the patience or the bandwidth to deal with "junior" devs. (I've often been on teams where every developer had at least 5 years of experience.)
Aside from the obvious advice that you simply need to be persistent, I'd say that it's also critical that you do everything you can to ensure that you're not seen as "junior". Now, you may be thinking that this is useless advice because you can't just make up a rich work history out of whole cloth. So to some extent, it's unavoidable that your experience will be deemed as "entry level". But you must strive to show that your knowledge is not entry level.
When I've encountered "junior" devs, my first instinct is to find out what kinda coding they do in their free time. What kind of projects have they built on their own? What activities do they do that keep them learning new languages / techniques / patterns / etc.?
That may feel a little unfair. Because some people think, "Well... I haven't really built anything yet - because no one's hired me yet." But if the only coding exercises you've completed are those you received as class assignments, or in coding camps, then there's a good chance that you'll simply drown in the environments I'm accustomed to working in.
In fact, I wrote an entire article that talks to this. You can read it here: dev.to/bytebodger/one-crazy-trick-...
Let me be absolutely clear here. Some of the sharpest coders I've met had little-or-no "real world" experience. Their resumes were sparse. But they coded all the time. They thought in code. Hell, sometimes they dreamt in code. Those are the diamonds in the rough who can bring massive value to a dev team even though they have little "experience".
I hope this helps (somewhat). Best of luck to you! I'm sure you'll get a foot in somewhere.
Take care.
I had the same question as Serenity and I’m very grateful for your response. So, constant practice it is, for us? How much of continually coding do we need to do to get noticed? It’s been a sea of rejection mails, and all I’ve done is wonder: I’ve been coding for more than two years, how much longer before I’m good enough to get to a “junior” role?
You also mentioned this interesting point: “What kind of projects have they built on their own?” We are still talking about beginners here, right? They should have somewhere to start from right? I’m curious as to how beginners should be designing things on their own without any influence or ideas from “questions from courses or coding camps”. In the absence of real-world experience to sell themselves, what else is the determinant of their abilities, besides proof of their understanding of the languages involved with those projects from coding camps? (Noting that lots of people are self-taught these days)
I’m curious though, you said that you’ve seen juniors who are so good they “dream in code”: does this mean the tech world is expecting every beginner to be that good? There are many indications out there saying that the answer to that is yes.
I wouldn't personally call it constant "practice". I'd call it regular "coding". Maybe that's semantic. But the word "practice", to me, conjures images of doing nothing but coding exercises. I'm talking more about building stuff. Stuff that will result in a usable/workable site/app/product/whatever.
I don't have a perfect answer for you. When you're self-taught (as I am), breaking into that first "official" role can be difficult. For me, I took a job as a "web content editor" (meaning that I wasn't specifically hired to code), and then, once I was on-staff, I was able to show them that I could solve some of their problems by... writing code. But the path everyone will take will be different on a person-by-person basis.
Part of the intention of saying that you should be doing more coding is to demonstrate your skills. From that perspective, you may also need to craft a resume / portfolio / etc that doesn't highlight your work history, but instead highlights your projects / skills. There are examples of these different types of resumes on the web. Granted, I'm not claiming that will magically open doors for you, but when you have scant experience and (hopefully) lots of skills, the key is to de-emphasize your experience and emphasize your skills.
This is the critical point of my "Write more code" article. Beginners can design things. They can build things. And in building/designing their own stuff, that's how they cease to be beginners. Sure, the code they write may be far-from-ideal. And their design "instincts" may be lacking. But that doesn't mean they can't build things.
You don't need someone to show you how to build an app in order to build an app. What you "need" is some problem you want to solve or some feature you'd like to build - and then to start building it. If it's not on-par with what a 20+-year vet would build, that's fine. Build it anyway.
When I was frustrated by severe limitations in Spotify's client, I used their API to build my own utility that allowed me to manage my Spotify playlists in the way that I desire.
When I wanted to match a digital image to my inventory of paints, I built an online utility that does a ton of image/color manipulation.
Anyone can do these things. You don't to be "senior" to make those things happen.
No, I don't honestly believe that anyone expects you to "dream in code". But for someone to even be able to contribute on most dev teams, they must at least be comfortable coding. To some extent, entirely on their own. So if someone's considering hiring you, they probably want to know that another dev won't have to sit with you, constantly, for months showing you how to do every little thing. They need to have at least some confidence that you can jump in and figure some things out on your own. (Or at least, know when to ask for help.)
And to be clear, I do understand that, when you're trying to "break in", it may feel like everyone expects you to be a genius up-front.
Keep at it. You'll get there.
I am so grateful that you took out time to give such a detailed response. I've learned much. Thank you!
Thank you. I appreciate your quick reply.
Seems like there's more going on from the other side that you didn't touch on, taking the high road. Good luck and happy hunting.
I have considered blogging about my most-recent experiences in more detail. And I will probably do that at some point in the near future. But I've also scrapped a few putative articles because, as I was writing them, it became apparent to me that they probably just sound like "sour grapes". And I don't think it helps me (or anyone else) to write something that sounds like I'm just griping about recent experiences. So... give it a little time. I'll probably put it all "out there" in due time. But for now... I just don't think it serves me to lay all that crap out there.
Regarding some job listings offering as low as $50,000 - $80,000, I'm not surprised. As the number of suitably experienced workers looking for jobs expands, the economic motivators and pressures inherent to a capitalist system are going to start to push down salaries, sadly. And some people will feel the need to accept them.
Don't worry :)))))
I will politely disagree with your take on percieved "TypeScript snobbery." The language has passed 10 years old, has huge benefits for large teams, and is generally more popular than JavaScript at this point. There are certianly features of TypeScript which I dislike & avoid, but there's a difference between pointing out TypeScript's specific weaknesses in an appropriate context and outright avoiding TypeScript entirely.
I'm going to gently push back on this. Your professional track record is excellent and the blogging is impressive. That said, there is some to be desired on the public side:
I know this is harsh, but I believe the above could actually detract from your overall application. I would recommend doubling-down on your paid professional achievements on a resume.
Good luck with your job search!
I think you've missed the point. When did I ever say that I avoid TS entirely??
As for the observations on the NPM packages, deployed sites, and GitHub repos, I gotta say that if those things detract from someone's opinion of me, then I'd never ever wanna work for them anyway.
There are many very strong devs who don't have any NPM packages. Some don't even have public repos. But now someone's gonna hold those things against me because what I do have out there isn't complex "enough"??
As you've pointed out, you don't build overly-complex stuff just for the sake of saying that you've built complex stuff. The tools I have publicly available are relatively simple. Of course they are. They perform targeted functions. I can't for the life of me fathom how someone would, in good conscience, hold them against me. But if they do - then good riddance to them.
Finally, I'd mention that, while spotifytoolz.com and paintmap.studio aren't large apps, that doesn't mean that they're simple. The logic behind them is robust, given their targeted functions.
As an example, if this "detracts" from my overall application - github.com/bytebodger/color-map/bl... - then I really don't know what else I'm supposed to show. No, it's not in TS. (Newsflash: Code doesn't have to be in TS to be a solid example of your skills.)