Hired, along with our partner Exponent, recently completed a video series exploring such as what the best programming languages for software developers to get a job. The series featured three of our talented engineers: Nico Thiebaut, Prakash Patel, and Dan Baker, discussing subjects such as:
Dan Baker is a former boot camper, now an Engineering Manager at Hired, a tech marketplace that matches talent with employers for roles around the world. He’s currently leading the work on the Hired Assessments product, helping candidates show their skills and find their dream jobs.
Based on the Hired State of Software Engineers report, these “top” skills or languages are taken from data on more than 360,000 interactions between companies and candidates on the platform.
Here’s a quick summary of the conversation Dan Baker had with Lucas from Exponent. To watch the full interview, scroll down to the bottom of the article.
Based on the report data: Go, Ruby on Rails, Scala, Ruby, and React Native.
Ruby on Rails, Scala, AWS, Google Cloud, and Ruby.
When I got started, Ruby was the main language that was normal. It was easy for people to understand. It was the first language for a lot of people. It’s no surprise to me that Ruby on Rails, as the first usable framework, has so much popularity.
Today there are probably not that many projects getting started in Ruby but there are many being maintained in it. That really speaks to the legacy nature of coding.
What stands out to me are languages like Go and Scala because they seem to be newer languages on the rise. People aren’t learning Go and getting Go engineers because they have to. It’s because they want to build new things with Go.
To an extent, that’s the truth with React Native but it’s more so the nature of React dominating the front-end framework landscape.
I frame my advice to my direct reports around:
Usually, it’s less about the technology and more about solving a business case. That’s what will matter to the hiring manager in the future. The technology is usually secondary.
One of my engineers is deep in Terraform right now, another knows more about React than anybody it seems, and then another knows the ins and outs of Django in a way that probably very few people know. When I’m suggesting people learn new skills it’s really catered to the use case, 100%.
If I was speaking to somebody who is just starting to code, I would recommend learning Rust. It’s exciting because it’s a new language approaching programming from a very type-centric point of view and is very low-level control while having high-level usability.
There are often technologies probably best suited to solve a particular business case and are extremely important to learn for that reason. There are also technologies probably always very popular amongst engineers, maybe because they scratch an itch and they’re kind of technically interesting but maybe they are the wrong puzzle piece or are a bit too new for whatever you’re trying to solve on the job.
Many times I’ve seen companies make the wrong decision by supporting engineers to do things they’re curious about that don’t align with the business case. Then, the current business case they need to move forward is not addressed so they have to pivot to something that does make sense. The engineer maybe gets a skillset but it isn’t even that sellable – why? It never was usable at the business.
The top five skills are interesting because you get an idea of the heavy hitters and what languages people for the most. It depends on where you are in your career and how much you understand about where you want your career to go.
For an engineer who has a little bit of experience but has a good idea of what they want to do, I would say, look in that subset and maybe it doesn’t matter which is the top language.
Maybe it’s more so, which programming language do you have some experience in – and will it be viable to enough potential employers? Looking at this list, I guarantee the people who are best at Scala don’t know much about React Native.
Most engineers won’t become an expert in all of these. You definitely want to assess where your own experience is and take it based on that.
My advice to any potential client using the product is to understand what an online technical assessment can do and what it can’t. The biggest value add is not that you’re going to get an automated answer to whether this candidate is right for the role.
You’re going to have an asynchronous interaction. A candidate’s going to do the assessment when it makes sense for them. The employer is going to review their work when it makes sense for them, that’s first and foremost.
Employers can review their work, and playback how they completed it. They can see if the candidate is within an acceptable range of performance, and how they executed problems. See what kind of approaches they took and if it makes sense to you (the employer). See if they are using coding patterns successfully demonstrating a level of expertise.
Candidates have the opportunity to show their thinking more than simply trying to solve the problem. In some cases, employers are looking, getting so many good candidates that they’re only able to look at the top one percent of them.
However, in these cases, no one really enjoys or does well in a game where only the top 1% are winning. You want to find a smaller pond where you can actually show a connection to the employer and show that you thought out your work.
For candidates, unfortunately, with the state of the industry and in online assessments, LeetCode reigns supreme. I recommend brushing up on that because that’s what most of these products are geared towards.
I do see a trend slowly moving away from purely LeetCode questions to framework-based questions that include a file system to find the bug, fix the bug, create a new file, and add a new pattern.
That’s where we see candidates thinking creatively and how they actually interact within an existing structure. That’s going to be more valuable – showing employers how you’re going to actually perform in the role. rather than you can do Fizz-buzz or bubble sort.
In my own experience, I have seen more interviews where the company crafted a test case that more closely mirrored a real-world coding situation in which you had to diagnose a bug in a code base that probably looked like their actual code base.
With that comes the impression that they care about your time and like to test skills that closely match what you’re going to do on the job. This is a bit different than the more esoteric LeetCode tests that you may be doing. I think it feels more valuable from a candidate’s perspective.
I think that’s something candidates need to be aware of as they choose which companies they engage with. As somebody interviewing a candidate I know I am selling as much as I am evaluating. Candidates should get a sense of how well the company they are interviewing with is selling them.
If they’re not selling you at all, what does that tell you about the company and the culture you’d enter? On the other hand, if they’re selling you 100%, they’re not really evaluating. What does that tell you about the mess you’d enter?
There’s a healthy balance where employers care about you and the experience you’re having, while also asking meaningful questions relevant to the role.
Candidates should know who they want to interact with but it’s also really important for employers to ensure they’re creating an experience that makes a candidate feel safe in the context of their whole life cycle, from candidate to employee, to ex-employee.
The technical interview experience you go through is, to some degree, a proxy of the engineering culture you may enter. It can be the best signal you have before you sign the paper.
One takeaway from looking at this is to understand where the demand is and how important it is to find the right demand/supply ratio. That could be one. If there’s one person that needs one engineer of one type, then there you go. You can get that role and you can be happily ever after at that company.
If you just choose the one most in demand, it also might be the most candidates going after that skill set as well. What you see yourself doing matters most because ultimately when you get the role you have to show up and do the work. So find something you’re interested in. That’s where you’re going to thrive and succeed long term.
If you have spent the last five years working in databases and think you need to learn React to be employable but your passion is databases, then that might not be the technology to learn.
It’s easy to think back on when you learned the language that you actually made your bread and butter with, it was hard to learn and you probably don’t want to do that again. The truth is that with every year that passes, the way people learn coding languages is better and easier than it was the year before. Remember when Stack Overflow changed the game? There’s a time that didn’t even exist. You couldn’t ask a question – you’d get an odd forum and esoteric responses or you’d have to open a paper book. So, learn a little bit about more languages and realize you’re never pigeonholed to one.
The first language you learn is going to be the hardest but after that, you establish mental models and understand how to read documentation. It’ll be much easier to pick up new technologies after mastering one or two.
Understanding deeper patterns will make you a stronger programmer and enable you to do more powerful things. When an interviewer looks at a submission and says, “Oh they’re currying a function. That’s an interesting approach.” Even if you aren’t able to do it, if employers watch it (which we really encourage our clients to do), they’ll see you know your chops. At the end of the day, no business is making money by having a programmer who can write fizz-buzz the fastest.