"For the purpose
of this report, Hired examined software engineering
candidate interview requests (IVR) and salary data from
January 2021 through December 2022 inclusive.
The data included reflects over 68,500 candidates and
494,000 interview requests between companies and
software engineers on Hired during this time period."
Then, I think, the numbers reflect only candidates and companies that use Hired, as opposed to the industry as a whole. I wonder how many folks land jobs through Hired?
I have had high callback rates from working with hired, as well as multi year engagement resulting from an offer through hired. These were with companies doing interesting work I would have never known I was a match for otherwise. You also need to do your own due diligence on the company, because hired is structured to take as little time commitment from their recruiters as possible (this is actually a good thing because it forces the companies on the website to be upfront).
Yeah there does appear to be bias in their sample since Ruby on Rails was their most in-demand skill. Not to knock it or anything, but it hardly seems like the number one skill industry wide.
I think its naïve to rank skills by a framework or library, but we're talking about a hiring platform website, used by keyword driven recruiters. If they were being more honest and accurate, lumping Django/Node would seem more appropriate. JVM/Java + C#/MSFT seems like it could stand on its own as well.
I have two experiences of using Hired to try to land jobs; I got interview requests, I interviewed, but I never found a role I was committed enough to or qualified enough for.
Both times I came out without any offers. Definitely have my own share of the blame here, but I don't think Hired put a ton of high quality leads on my radar for the effort I put in.
Especially when it's well-known that many engineers, especially senior, are essentially never "on the market". They work through their networks, leveraging referrals, and will frequently vanish from one job and appear in another without submitting a resume, contacting a recruiter, or touching anything on linkedin/gh/etc.
Seems like that alone would put a big skew on results. It's kind of like the "r/cscareerquestions" effect. There's literally only 3 people posting: hapless anxious innocent newbies/newgrads, low-marketability folks who are struggling to find a position, and people who get off on trolling/doomposting and otherwise feeding off the despair of the other two crowds. The result being a forum that perpetually makes it seem impossible to get hired as a software engineer (even during the covid hiring spree!).
anecdotally, i know more people that struggle with the hiring process then these extroverted super connected senior developers that just hop job from job that apparently exist. from the group of people i keep in contact with, i think only one is doing something like that. also the people we hired went through application pipelines and weren't just showing up after being recommended
I know quite a few developers who have a knack for following market trends and jumping on the rocket ship before it is about to launch.
It's actually not that hard if you think about what filter you would apply. The one hard part is finding recruiters who specialize in placing people at these companies, and, of course, passing the interview (or at least enough success that the interviewer doesn't tell the recruiter you are a poor quality candidate).
This isn’t my experience. I’ve interviewed many seniors in my time, and also gone on many interviews as a senior.
Networks fail people all the time. Mine failed me because I was at one company for a decade(switching teams), and my entire network still works there. I don’t want to go back, so I essentially have no network.
We hired an architect who’s entire network was still at IBM, similar to me. There’s other possible failure modes, it happens quite a bit IME.
Ah that's fair, I was being too hyperbolic. I suppose what I mean is "a nontrivial contingent [of seniors]."
Also it's worth noting that while your whole network might be at IBM still, I've found leveraging "I know X, who knows Y, who works at / worked at [target company i want to apply to]". They'll usually only be able to give you a "someone I know but haven't worked with" referral (some places call them just a "candidate lead"), but often it's still miles better than putting your resume in the website intake form. Going 2 degrees out in your network graph is almost always a shockingly large number of people / places.
Almost all the engineers I know get their jobs through random process. They use things like Hired, sending out resumes, responding to recruiters, rooftop slushie (no longer available), and then some actual referrals if they know someone. You use everything available cause you need to get multiple competing offers. You're not going to just interview at one or two friend's places and then get an offer and take it. You're gonna get 5-7 offers and then try to take the best one out of those by making them compete for one another.
This - turns out - requires a lot of companies and interviews and a lot of work.
> It's kind of like the "r/cscareerquestions" effect.
I canceled my ACM subscription in my late 20s because I got tired of ACM basically doomposting about careers. Last night I was going through my Gmail folders and found a bunch of old ACM doomposts I never deleted from their CSCAREERS mailing list.
So, it's not just reddit that doomposts- Industry veterans are just as paranoid and can also serve as Chicken Little.
> Especially when it's well-known that many engineers, especially senior, are essentially never "on the market".
> Seems like that alone would put a big skew on results.
Yes it does. Same with internship pipelines at unicorns or FAANG. Some students intern at the same company multiple times during undergrad and transition full time after graduation. They appear to never be on the market.
>They work through their networks, leveraging referrals, and will frequently vanish from one job and appear in another without submitting a resume, contacting a recruiter, or touching anything on linkedin/gh/etc.
I literally never heard of this, ever. Not even for staff+ positions.
I've read something on the lines of "even Tom Hanks sends his resume to the director when applying for a role". Hyperbolic or not, I've found this to be vastly true.
If I can act like a junior developer, I'll take a salary cut to 145k just so I don't need to do anything but develop, ask stupid questions and be able to clock out after work without worrying about any systemic team, company or other structural problems. Not even kidding!
Ask HN: Do I have to do Hired's coding assessments to get interview requests now?
Question for you all, I've used the same resume and landed jobs twice on Hired before, now I have even more experience. This round I got 0 interview requests during my 6 week promotion period.
The only difference I see is that Hired made some coding assessments that employers could use to filter candidates. I didn't do them.
Has anyone else A/B tested this? Coding assessments = a bunch of interview requests?
I played around with them during the promotion period, put them in line with what other recruiters were telling me (now that base salaries are posted publicly in most(?) job listings)
I have 15 years experience and haven't received any interviews from companies on hired either. I also didn't do the coding assessments.
Another factor is that my experience probably isn't in demand. All of my experience was writing C++ for devices but only in user space. Most C++ jobs seem to want more than just a generalist C++ programmer. They want low level embedded experience, or backend, or distributed systems, or GPGPU, or graphics.
I did the basic coding assessment as a Senior Dev and got around 12 interview requests at around $200k salary average. I'm willing to bet most employers filter for this, since most employers already get a ton of applicants either way.
thanks! that fits my hypothesis. yeah it was hard to prioritize doing that when there are so many other recruiters and companies in different stages of the interview process with their own coding assessments.
>The most in-demand skill was Ruby on Rails, with engineers skilled in this framework and scripting language receiving 1.64x more interview requests compared to the marketplace average. Ruby on Rails bumped Go from first place in 2022’s report to fourth this year.
Woah. That’s an interesting finding.
I wonder what RoR is doing to make it so in-demand?
Many of today's big tech cos, which were unicorns in the 2005-2015 era, were built on top of Ruby/Rails.
Today those companies have diversified their tech stacks but for the most part the core rails monoliths aren't going anywhere. They need engineers to work on them.
It's not necessarily in-demand. It's the ratio of jobs to applicants. Both numbers can be low which anecdotally feels right for Rails. It's not the new hotness anymore but there's still plenty of systems to maintain/expand. Can be hard to hire because fewer engineers want to do it but the systems can't easily be transitioned to a new language.
Yep, I have RoR on my resume/LN profile from years ago (rails 3.x), and I get recruiters spamming me - mostly for legacy maintenance/modernization/porting to another stack type jobs.
RoR enables developers to make a lot of progress on their app in a short amount of time... initially. Most developers have never seen a legacy Rails app, or are still in the self-deluded "this time it'll be different" phase. So they jump wholeheartedly into the Rails ecosystem and build their app the "rails way". Not knowing the pitfalls, they fall into all of them. A few years later, you have a successful Rails app with (1) slow, data-coupled tests (2) spaghetti code in your models and controllers (3) probably dockerized, relies on heavily outdated linux version and no one can update it within a sprint so it never happens. So they hire "senior rails" devs and throw them at the problem (after all, the initial setup speed of Rauls allowed them to be successful and have money now).
I have personally witnessed "legacy" rails apps (were ~4 years old, Rails 5 was around but we were on Rails 3 IIRC) and they are not really unlike normal legacy apps but they definitely let a lot of crap seep in due to loads of contributors and almost zero ownership on the codebase.
I wouldn't say this an exclusively rails problem though. Testing was a complete nightmare, and there was so much random middlewares that were "mission critical" but no one knew what they did. And as you said, scaling was horrible. We had like a hundred servers, each running 20 unicorn instances, to serve our API at the scale we had (~5 million users or so, I forget the DAU)
The whole concept of "middleware" in Ruby server applications was a huge mistake. Your average Ruby developer has no idea how any of that shit works, and it's an unnecessary abstraction over taking request data and passing it through a function, something that should be simple for even a junior developer to figure out. Somehow it was decided that having a standard for the shape of data wasn't good enough; there had to be a demi-standard for modifying request data before it reaches the primary application code.
If you have to tell a middleware what order it's supposed to run in with relation to other known middlewares, chances are the middleware system itself is a poor design.
> If you have to tell a middleware what order it's supposed to run in with relation to other known middlewares, chances are the middleware system itself is a poor design.
That's just the chain of responsibility pattern [1] and I've only seen middleware operate that way. Why wouldn't you want control over the order?
I can't know exactly what the OP means, but I'm guessing they're referring to the tendency for Rails tests to rely heavily on the database and its behavior. This technique is often rationalized for being a partial substitute for end-to-end testing, given that it tests the integration of the app with its services, and that's not wrong per se. It does come with a penalty because constantly building and tearing down the database has consequences in terms of performance and state leaking between test cases. A lot of the time, this reliance on the database is not (or should not) be necessary; it should be possible to test units of the application in isolation, even including the model->controller->view cycle, without needing to include any knowledge about what database or ORM are being used. Just building in-memory data on the fly is safer and faster, and when tests are faster then developers are more likely to run tests frequently and spot issues earlier.
Again, as with many things, it's not a Rails-specific problem. It's an issue in many kinds of codebases, and is an issue with the Ruby community in general. I understand the arguments around coupling tests with the data layer implementation, but I just don't agree when it comes to most of the useful tests being performed.
This describes a lot of my reasoning for why I left Rails for a more frontend/JavaScript focus.
I don't think it's necessarily a problem specific to Rails. It's an issue that the Ruby community that they may never see as a true problem. To their credit, having a system that sucks developers into making simple apps that grow into monstrocities seems to have created a ton of job security for Rails developers. In terms of developer happiness, I really beg to differ once any given Rails application is more than a year old.
Rubyists love object orientation and metaprogramming, which I personally see as massive mistakes outside of some niches. Ruby applications in 2023 still have long chains of inheritance, and still employ lots of metaprogramming, and still use tons of syntactic sugar, and still think along the lines of classes rather than methods/functions, and still allow for side-effects on mutable objects. I've found that at least 80% of issues typical to Rails codebases are related to those styles of software development. Most of those are unnecessary for writing most apps using Rails.
> So they hire "senior rails" devs and throw them at the problem (after all, the initial setup speed of Rauls allowed them to be successful and have money now).
That's the true black-pill of senior-level software engineering. Chances are, as a senior engineer, your job is to figure out the mess rather than make sure anything was done appropriately in the first place. In retrospect, I enjoyed my job as a junior and even mid-level engineer more than being a senior engineer because I often got to work on new and interesting problems while senior engineers had to toil over figuring out some incredibly complicated and boring shit created by the previous engineering regime, as well as by the junior engineers as a whole. Because the business will always be pushing for more features and more deadlines, this problem never gets fixed, hence being a senior engineer becomes little more than an exercise in Sisyphean futility. And the pay is just enough that you don't go fishing instead.
I'm just glad I only spent around 3 months as a senior Ruby engineer before switching to JavaScript, despite all of JavaScript's faults.
Rails provides a sensible and productive pattern for MVP but doesn't provide much guidance past a certain complexity level (Service Objects etc). Once the app grows past a certain size, more bespoke architecture needs to be applied and this will live or die on the competence of the team. Spaghetti code is not inevitable but can result from devs who are used to the hand-holding of less complex Rails apps.
Dunno where you are pulling docker from, that is completely orthogonal to Rails development.
I took the Docker comment as a sort of dig at Rails teams throwing tech at problems in an inappropriate way with the goal of overcoming poor decision making. Not sure how fair that is since the use of Docker et al is often an exercise in cargo cult tech.
Yeah, dragging in docker is perhaps unfair, but Ruby apps suffer in a docker environment especially because of how much native code Ruby gems like to include (and how incredibly brittle they are under slightly different C++ compilers...)
I think there are many RoR projects that continue to run, so probably demand still there - we've been maintaining several RoR projects for 7+ years. Recently we've stepped into several JS projects that have 2-3 competing JS frameworks in the same project. Any project becomes difficult to maintain over time without a continuous and thoughtful investment of time, but at least Rails doesn't have that particular problem of framework churn (even if parts of it may change as a whole it has an upgrade path that is well trodden). We do a lot of React/Next.js etc. work, but for the most part Rails is what we reach for (maybe with a sprinkling of React) when we have a standard web project, ie. most of them.
You'd think there would be an arbitrage opportunity in paying more $$$ for London talent. Still surprises me that this hasn't happened after all these years of huge differences.
Top earning UK dev jobs are usually 200k upwards, already. Those numbers don't account for finance and similar industries, which they hire directly and don't use Hired services.
How common is this? Even breaking £150k seems really challenging - FAANGs aren't hiring in London right now, finance seems to require previous finance experience and/or prestigious education even for experienced candidates (I don't know if they really require it or just like to put it in their job ads); and even companies that pay less (£90-120k) aren't giving me the time of day.
It's not just FAANGs that are offering TC that high in London. Have a look at levels.fyi if you want to see some numbers. Possibly not as prevalent nowadays unfortunately.
I'm making more than that in London. I know similarly qualified people in Bristol who make literally a fifth of my salary yet for some reason do not want to move to London.
Initial HR filter is to weed out the DDOS of a million CVs on a job ad... Look for a backdoor. Friends, neighbors, Meetup, colleagues, online forums such as Twitter or Discord.
I have no special insight into the London market, but the fact that it hasn't happened after all these years of huge differences probably indicates that the arbitrage opportunity is not as large as it appears.
It seems like a mistake to measure productivity through salary. A baker in India will make a fraction of a baker in the EU, even if they're making as many breads or more per day.
It may simply be that the the same product is worth less when developed in London rather than SF, due to relative availability of VC, market access restrictions, cultural approaches to monetary compensation or any number of other reasons that have nothing to do with the quality of the code.
It's good to see that despite all of the astroturfed "Journalism" on the death of remote work the data appears to show otherwise. The engineer market dictates the terms of employment. It seems that, based on this, remote is here to stay. That's good news for myself and others that would otherwise have very little reason to stay in tech. For example, the area I've lived in for the last 25 years has a small tech community. Mostly curmudgeonly old companies with a "tech" wing that is chronically underpaid. Think $90k for a senior a position. Given how expensive my house has become in recent years there's no way that's even possible to choke down.
Rails being the most in-demand skill is relatively unsurprising. It's becoming the web's very own COBOL. Millions and millions of lines of RoR code from over a decade ago needs to be maintained and these people are in high demand. I've seen a lot of new shops spring up that use RoR too. The trend with these places seems to be foreign developers and juniors powering the company. RoR, while it has it's problems, is still the perfect tool to extract any real power a developer has. It's about as close to WYSIWYG as we can come without going to dreamweaver.
It is interesting Python didn't make it into the in-demand skill list. I suppose the language is relatively niche still. It just feels like an in-demand kill to me because I work in data engineering. It's similarly interesting Go scored so high in demanded skills. Even outside my field it's still very niche despite all the posts you see. It leaves me suspect of their data somewhat.
I don't know. Almost every back-end position I see requires Python (with a few exceptions that require Go or Rust). I filter for stuff that hires remotely and/or in France, so there is a bias.
The charts don't call out whether they're showing average base salary, or average TC (including stocks/bonuses/etc.) - I wonder if the actual numbers are higher.
$145k seems too high, $167k seems too low. Weird data - juniors on high rates are more willing to share and seniors in good jobs don't care about these surveys?
On page 21 we see that only 25% of engineers consider a great/exciting product to be an important work priority, and only 24% consider strong mission/vision. Are 3/4 of engineers just not that interested in what the company is actually building for the world?
A very specific survey limited to Hired.com so not sure if this generalizes. Lot of times a percentage change is provided starting from a small base giving the wrong impression (RoR having high demand, NLP engineer top role etc..) With that, some non-obvious observations from this sample that popped out --
1. All remote roles settling to around $160K in the US. This can't be good for those in the high cost areas like SF, Boston etc.. where SOL is easily 2x of the lower cost cities. How will people in high cost regions make remote employment work?
2. How is blockchain engineer still a thing? I would have predicted more than a substantial drop, more like complete wipeout.
3. Rust bottom of the list (least favorite) in engineers favorite/least favorite language. I LOL'ed at this one, since any Rust topic opens with "most admired programming language 7 years a row" statement. Go third least favorite less favored than HTML, Java, C++ and SQL (!). Definitely an interesting sample group.
> 1. All remote roles settling to around $160K in the US. This can't be good for those in the high cost areas like SF, Boston etc.. where SOL is easily 2x of the lower cost cities. How will people in high cost regions make remote employment work?
How else are people not in big cities supposed to make in-person employment work? Well, besides taking lesser opportunities. It seems like tilting the playing field away from big (and arguably dysfunctional) cities is the more equitable outcome. I think the jig is up for a few cities hogging all the tech, and if that changes the rules of engagement for city-dwellers and their living situation, such is life.
> 2. How is blockchain engineer still a thing? I would have predicted more than a substantial drop, more like complete wipeout.
A combination of easy money and surveys such as this one being largely imperfect. Exacty how many blockchain engineers do you know personally? I can't name a one. For all we know, there's 3 developers with the title of "blockhain engineer" working for one company out of the basement of a house and are making ~170k.
97 comments
[ 3.6 ms ] story [ 29.8 ms ] threadThen, I think, the numbers reflect only candidates and companies that use Hired, as opposed to the industry as a whole. I wonder how many folks land jobs through Hired?
Both times I came out without any offers. Definitely have my own share of the blame here, but I don't think Hired put a ton of high quality leads on my radar for the effort I put in.
Seems like that alone would put a big skew on results. It's kind of like the "r/cscareerquestions" effect. There's literally only 3 people posting: hapless anxious innocent newbies/newgrads, low-marketability folks who are struggling to find a position, and people who get off on trolling/doomposting and otherwise feeding off the despair of the other two crowds. The result being a forum that perpetually makes it seem impossible to get hired as a software engineer (even during the covid hiring spree!).
It's actually not that hard if you think about what filter you would apply. The one hard part is finding recruiters who specialize in placing people at these companies, and, of course, passing the interview (or at least enough success that the interviewer doesn't tell the recruiter you are a poor quality candidate).
Networks fail people all the time. Mine failed me because I was at one company for a decade(switching teams), and my entire network still works there. I don’t want to go back, so I essentially have no network.
We hired an architect who’s entire network was still at IBM, similar to me. There’s other possible failure modes, it happens quite a bit IME.
Also it's worth noting that while your whole network might be at IBM still, I've found leveraging "I know X, who knows Y, who works at / worked at [target company i want to apply to]". They'll usually only be able to give you a "someone I know but haven't worked with" referral (some places call them just a "candidate lead"), but often it's still miles better than putting your resume in the website intake form. Going 2 degrees out in your network graph is almost always a shockingly large number of people / places.
Almost all the engineers I know get their jobs through random process. They use things like Hired, sending out resumes, responding to recruiters, rooftop slushie (no longer available), and then some actual referrals if they know someone. You use everything available cause you need to get multiple competing offers. You're not going to just interview at one or two friend's places and then get an offer and take it. You're gonna get 5-7 offers and then try to take the best one out of those by making them compete for one another.
This - turns out - requires a lot of companies and interviews and a lot of work.
I canceled my ACM subscription in my late 20s because I got tired of ACM basically doomposting about careers. Last night I was going through my Gmail folders and found a bunch of old ACM doomposts I never deleted from their CSCAREERS mailing list.
So, it's not just reddit that doomposts- Industry veterans are just as paranoid and can also serve as Chicken Little.
> Seems like that alone would put a big skew on results.
Yes it does. Same with internship pipelines at unicorns or FAANG. Some students intern at the same company multiple times during undergrad and transition full time after graduation. They appear to never be on the market.
I literally never heard of this, ever. Not even for staff+ positions.
I've read something on the lines of "even Tom Hanks sends his resume to the director when applying for a role". Hyperbolic or not, I've found this to be vastly true.
- I have had a satisfying number of leads from my network.
- I have also been approached by dozens of recruiters both through my network, through LinkedIn and through HN "Who wants to be hired?"
- I have a profile on Hired, through which I have had one lead, for a position in which I'm not interested. Zero on HiredSweet.
I made ~190k on my W-2 after first year at Microsoft.
Question for you all, I've used the same resume and landed jobs twice on Hired before, now I have even more experience. This round I got 0 interview requests during my 6 week promotion period.
The only difference I see is that Hired made some coding assessments that employers could use to filter candidates. I didn't do them.
Has anyone else A/B tested this? Coding assessments = a bunch of interview requests?
Another factor is that my experience probably isn't in demand. All of my experience was writing C++ for devices but only in user space. Most C++ jobs seem to want more than just a generalist C++ programmer. They want low level embedded experience, or backend, or distributed systems, or GPGPU, or graphics.
I got a couple of interview requests 3 weeks into my promotion period, didn't take the quizzes.
Woah. That’s an interesting finding.
I wonder what RoR is doing to make it so in-demand?
Today those companies have diversified their tech stacks but for the most part the core rails monoliths aren't going anywhere. They need engineers to work on them.
Must be due to all the "it is dead and forgotten" hate Ruby gets :)
see COBOL for example.
I've moved on, not so interested in going back...
I wouldn't say this an exclusively rails problem though. Testing was a complete nightmare, and there was so much random middlewares that were "mission critical" but no one knew what they did. And as you said, scaling was horrible. We had like a hundred servers, each running 20 unicorn instances, to serve our API at the scale we had (~5 million users or so, I forget the DAU)
The whole concept of "middleware" in Ruby server applications was a huge mistake. Your average Ruby developer has no idea how any of that shit works, and it's an unnecessary abstraction over taking request data and passing it through a function, something that should be simple for even a junior developer to figure out. Somehow it was decided that having a standard for the shape of data wasn't good enough; there had to be a demi-standard for modifying request data before it reaches the primary application code.
If you have to tell a middleware what order it's supposed to run in with relation to other known middlewares, chances are the middleware system itself is a poor design.
That's just the chain of responsibility pattern [1] and I've only seen middleware operate that way. Why wouldn't you want control over the order?
[1] https://refactoring.guru/design-patterns/chain-of-responsibi...
I’m intrigued what this means, or how you’d decouple your tests from all data.
Again, as with many things, it's not a Rails-specific problem. It's an issue in many kinds of codebases, and is an issue with the Ruby community in general. I understand the arguments around coupling tests with the data layer implementation, but I just don't agree when it comes to most of the useful tests being performed.
I don't think it's necessarily a problem specific to Rails. It's an issue that the Ruby community that they may never see as a true problem. To their credit, having a system that sucks developers into making simple apps that grow into monstrocities seems to have created a ton of job security for Rails developers. In terms of developer happiness, I really beg to differ once any given Rails application is more than a year old.
Rubyists love object orientation and metaprogramming, which I personally see as massive mistakes outside of some niches. Ruby applications in 2023 still have long chains of inheritance, and still employ lots of metaprogramming, and still use tons of syntactic sugar, and still think along the lines of classes rather than methods/functions, and still allow for side-effects on mutable objects. I've found that at least 80% of issues typical to Rails codebases are related to those styles of software development. Most of those are unnecessary for writing most apps using Rails.
> So they hire "senior rails" devs and throw them at the problem (after all, the initial setup speed of Rauls allowed them to be successful and have money now).
That's the true black-pill of senior-level software engineering. Chances are, as a senior engineer, your job is to figure out the mess rather than make sure anything was done appropriately in the first place. In retrospect, I enjoyed my job as a junior and even mid-level engineer more than being a senior engineer because I often got to work on new and interesting problems while senior engineers had to toil over figuring out some incredibly complicated and boring shit created by the previous engineering regime, as well as by the junior engineers as a whole. Because the business will always be pushing for more features and more deadlines, this problem never gets fixed, hence being a senior engineer becomes little more than an exercise in Sisyphean futility. And the pay is just enough that you don't go fishing instead.
I'm just glad I only spent around 3 months as a senior Ruby engineer before switching to JavaScript, despite all of JavaScript's faults.
Dunno where you are pulling docker from, that is completely orthogonal to Rails development.
as someone who's been a hiring manager for software engineers in finance: your problem is likely getting past the initial HR filter
they sadly care about all the things you listed
I call that "trampoline". Jobs that are meant to be temporary to jump to the real interest.
The trampoline a year ago was crypto startups. Ponzi, probably.
It may simply be that the the same product is worth less when developed in London rather than SF, due to relative availability of VC, market access restrictions, cultural approaches to monetary compensation or any number of other reasons that have nothing to do with the quality of the code.
Toronto and London should be at 103kUSD and 98kUSD respectively.
Rails being the most in-demand skill is relatively unsurprising. It's becoming the web's very own COBOL. Millions and millions of lines of RoR code from over a decade ago needs to be maintained and these people are in high demand. I've seen a lot of new shops spring up that use RoR too. The trend with these places seems to be foreign developers and juniors powering the company. RoR, while it has it's problems, is still the perfect tool to extract any real power a developer has. It's about as close to WYSIWYG as we can come without going to dreamweaver.
It is interesting Python didn't make it into the in-demand skill list. I suppose the language is relatively niche still. It just feels like an in-demand kill to me because I work in data engineering. It's similarly interesting Go scored so high in demanded skills. Even outside my field it's still very niche despite all the posts you see. It leaves me suspect of their data somewhat.
Since Python is on the top of all of the other lists, I think this is a consequence of their methodology.
Demand for coding skill over the market average... well if every job in the market requires Python you're not going to see a much "over the average".
I have 6+ yoe and all the offers I got from their platform (while living in LA) were around 120k.
$145k for 0-1 years of experience, rising gradually to only $167k for 15+ years?
Is a person with 15 years of experience really worth only 10% more?
Given how many engineers work at basic companies doing basic stuff, probably.
There's only so many exciting opportunities to change the world out there. For the rest of us, it's CRUD stuff for an insurance company.
1. All remote roles settling to around $160K in the US. This can't be good for those in the high cost areas like SF, Boston etc.. where SOL is easily 2x of the lower cost cities. How will people in high cost regions make remote employment work?
2. How is blockchain engineer still a thing? I would have predicted more than a substantial drop, more like complete wipeout.
3. Rust bottom of the list (least favorite) in engineers favorite/least favorite language. I LOL'ed at this one, since any Rust topic opens with "most admired programming language 7 years a row" statement. Go third least favorite less favored than HTML, Java, C++ and SQL (!). Definitely an interesting sample group.
How else are people not in big cities supposed to make in-person employment work? Well, besides taking lesser opportunities. It seems like tilting the playing field away from big (and arguably dysfunctional) cities is the more equitable outcome. I think the jig is up for a few cities hogging all the tech, and if that changes the rules of engagement for city-dwellers and their living situation, such is life.
> 2. How is blockchain engineer still a thing? I would have predicted more than a substantial drop, more like complete wipeout.
A combination of easy money and surveys such as this one being largely imperfect. Exacty how many blockchain engineers do you know personally? I can't name a one. For all we know, there's 3 developers with the title of "blockhain engineer" working for one company out of the basement of a house and are making ~170k.
how good is hired.com's performance? how many jobs they fill per year?
how many candidates get a job on there? how long does it take them?
I ask because there are many job portals these days and I see a lot of flakiness, ghosting, etc.