Trends Suggested by 2024 API Job Listings
Net API Notes for 2025/02/11, Issue 248
State of Hiring Uncertainty
The state of software employment is weird right now. In 2024, several high-profile layoffs occurred in otherwise stable, coveted workplaces. Ghost profile accusations and counter-accusations filled hiring subreddits. Then, there were the stealth layoffs disguised as Return-To-Office (RTO) mandates.
If that wasn't bracing enough, hyperbolic AI claims started impacting 2025 hiring plans. For example, Salesforce attributed a software engineer hiring freeze to AI productivity gains. Mark Zuckerberg suggested that Meta could replace all their mid-level engineers with AI.
Can you tell I'm rolling my eyes? I'm totally rolling my eyes.
Last January, I analyzed the API industry from the perspective of companies' open job listings. Since then, I've continued to collect data, significantly improving the refinement and analysis processes to ensure more accurate insights. I even built a custom frontend in HTMX to further explore that data, which led to several follow-up pieces:
- What 'Economic Headwinds' Mean for Your APIs
- Inside the Hiring Funnel: Truths and Tactics for API Pros Seeking Jobs
- Mid-Year Check-In: What API Employers and Job Seekers Need to Know
With a full year of collection, I want to share an update on what the data suggests.
Methodology
All job listings were accessed via Google Jobs Search through SerpAPI. Google Jobs Search aggregates job postings from individual business websites and job board aggregators (e.g., Indeed, ZipRecruiter). Data was limited to open API positions in the United States to keep the project manageable.
Data is saved to a PostgreSQL database. Subsequently, I run multiple scripts to de-dupe, extract, and enrich each job description's metadata. One of these steps involves calling the OpenAI's API for additional summarization and inference.
Tech Centers Remain (Mostly) Consistent
% of Jobs Where the Geographic Region Could Be Inferred
The geographical location of API jobs remained consistent for the most part. Only Denver and Baltimore rotated out of the top 15, to be replaced with Los Angeles, CA, and Austin, TX.
API Work Arrangement (Remote, Hybrid, or Office Only)
Note: The percentage listed is where the job arrangement could be inferred from the job listing. In nearly 56% of 2024 job listings, the work arrangement was not explicitly stated enough to be confidently inferred. For hiring managers posting open positions, make it clear what the onsite or hybrid policy is in your listing!
Unlike office or hybrid roles, which often suffer from vague or missing descriptions, remote jobs are a significant selling point for employers, making them more likely to be explicitly stated. If a company offers remote work, it's often framed as a competitive advantage—attracting talent across geographies, appealing to workers seeking flexibility, and differentiating from companies requiring office attendance. As a result, remote positions are frequently labeled as such in job descriptions, and thus are why they account for such a high percentage of identifiable work arrangements.
API Role Mix Changed Significantly In 2024; Are My New Inference Models to Blame?
API Role Type Where Role Could Be Inferred
Interestingly, the listings in 2024 were almost exclusively related to software developer-esque work; less planning or managing and more doing. It will be interesting to see if this trend continues or if this is due to current macroeconomic conditions.
API Experience Where Experience Level Could Be Inferred
As for the experience level sought, my only guess is that when I updated the models, there was significant reclassification of what comprises "senior" responsibility versus "mid-level" when I updated models. I will need to investigate this further.
API Architecture and Tools Remains The Same from 2023, With a Few Surprises
Percentage of Jobs Where An API Style Was Explicitly Mentioned
In 2024, event-driven APIs cooled slightly, and there were slightly more mentions of SOAP (and SOAP-related concepts). However, for the most part, architectural styles remained mostly the same. Sadly, there were no job listings mentioning HTMX. Hopefully, that changes in 2025.
Percentage of Listings Where API Description Is Mentioned
Hey, hey! Fewer people use Swagger and OpenAPI (or OAS) interchangeably in job descriptions! Huzzah! Except…. Did we have a huge upswing in Swagger usage? And RAML made a comeback? These results are puzzling and warrant further investigation. The only hypothesis I have at the moment is that the sample size for job descriptions that explicitly list a description format is relatively small. Therefore, if you get an employer that went all-in on RAML a decade ago and then suddenly seeks to hire a bunch of folks last year with explicit job postings, it skews the results this year.
APIs Tools Heavily Influenced By Cloud Choices
Percentage of Language Mentions
Lua, Scala, Perl, and Cobol are not listed in the chart but each have less than 1% of mentions. I look forward to next year's list; hopefully, we can get a Fortran guest appearance.
The programming language breakdown was incredibly stable year to year - in the thousands upon thousands of language mentions, it's mind-boggling that a language like GO would end up with the same percentage.
Percentage of Explicit Platform Mentions
Other gateways or platforms mentioned but with less than 1% of related data included Axway, Software AG, WSo2, Tyk, Akana, and Workato.
There are some big shifts with the platform table. Do I really think that there are massive marketshare shifts away from Google's Apigee to similar offerings provided by Microsoft and Amazon? Perhaps. However, my gut suggests this has more to do with my service identification and classification changes. When you talk about APIs on AWS, you might be talking about Lambda, ec2, or any one of hundreds of other services. And Amazon isn't the only one that has this rapidly expanding product catalog. So, whereas there may be only one entry for "Tyk", there might be hundreds of individual service or product names that suggest an API developer will be building on Oracle Cloud (for example). And then each one of those references may have numerous alternate spellings to aggregate ("azure apim", "microsoft apim", "microsoft azure apim", "microsoft api management", "microsoft api mngement", etc.). All of which to say, I spent much more time this year carefully collecting and aggregating these items than last year.
This is another area where I will have to do additional testing of hypotheses.
Percentage of Explicit API Tool Mentions in Job Listings
Developers love their tools, and any developer listing often takes great pains to list them. The aggregated data references log4j and postgres and kubernetes, kubernetes, and even more kubernetes. However, like last year, I was keen on comparing mentions of tools that were explicitly API related.
It should be noted that SoapUI, SwaggerHub, ReadyAPI, and Stoplight are all owned by SmartBear Software. I have presented them here as individual line items.
Other API tools that were mentioned but had less than 1% of the overall total mentions were TSlint and zally. As an overall percentage of job listings, programming language far and away exceeds explicit mention of API tools. Does a small percentage of companies use dedicated API tooling? Or aren't they seen as worthy of inclusion?
I'd guess that APIs are still too often treated as projects and developers use whatever tooling they have on hand - or what comes bundled with their cloud vendor contract. Support for specialized tooling - to the point where it would be mentioned as a desirable skill set in a "help wanted" listing - remains the exception, not the rule.
Looking Ahead to Next Year's Tracking
In addition to the hypotheses to test I mentioned above, several operational updates are worth doing.
- After watching an incredibly persuasive talk about building long-lived software, I'd like to migrate from a PostgreSQL database to SQLite.
- In 2024, I updated the previous ChatGPT model I consumed through the API to the latest, GPT-4o. The way I process and store data makes it relatively easy to rerun all prior results to infer important metadata with an upgraded model. I anticipate there will be additional advances in model reasoning and high-precision aggregation - including high-quality models run locally for less power than what currently is consumed by a European city-state (I've got Ollama-mini running on my laptop, and it's close).
- I need to find a more affordable Google Jobs Search intermediary. I use a third party because every time I attempt to call the Google APIs directly I end up lost. But for the volume of requests I make, there's no reason I should be paying what I do monthly to scratch an itch.
- There's been much debate about companies posting "ghost jobs". Could I use the accrued dataset to name and shame bad actors? It would be an interesting data engineering problem.
That's it for 2024's API job review. Was there anything that surprised you? Are there things that you wish you could see? Let me know in the comments.
Milestones
- Under milestones, I usually like to list recent developments or newsworthy items in a rapid-fire fashion. The "OpenAI Cuts Off Engineer Who Used API to Create Voice-Controlled Gun" is a bit on the nose, natch.
- Software Defined Talk remains one of my favorite industry-related podcast listens. In a recent episode, the crew asks, "Whatever happened to Service Mesh?" Having gone through this newsletter's archive over the holiday break, I can attest that Service Meshes, like Istio, were supposed to be the next big thing circa 2017 (and 2018, and 2019, etc.). But, as the Software Defined Talk hosts conclude, "Service Meshes are a solution to a problem no one wants to have." Which… damn, that's too good of a line to not repeat here.
- DeepSeek, the Chinese AI model that sent markets aflutter recently, also has an API angle. Sohaib Tariq, writing on LinkedIn, observed that, "By mirroring OpenAI's API design, they've hacked developer adoption," and "The AI [API] industry just quietly standardized." I've written previously about imitators of AWS's cloud service APIs and pontificated about whether that was a good thing for the industry. And there was that drawn-out legal exercise as to whether Google could copy Oracle's interface that went to the U.S. Supreme Court before coming to a, rather, unsatisfying conclusion. It is fascinating to watch history repeat itself, though.
- Some of you, like me, may have been following the IT changes happening in (to?) the U.S. government. There's a lot there, but this story also intersects APIs. As reported by 404media, part of the new administration's initial desire was to redesign Login.gov to connect information held by various agencies to a single identity via APIs. A civil servant pointed out, "The Privacy Act forbids agencies sharing personal information without consent," and, therefore, the request was illegal. The response was, "we still should push forward and see what we can do". Lovely.
Wrapping Up
Thank you for reading to the end. One of the joys of writing this newsletter the way I do is that I'm not bound by the grind of traditional industry news sites. These places are under increasing pressure to churn out content; after all, the more pieces, the more ads. The mill's demand for grist often results in small stories being stretched into tall tales and derivative work being propped up as new thought.
I really have no interest in contributing to that pollution, so thanks for letting me do this my way. I hope you continue to find value in it.
Till next time,
Matthew (@matthew in the fediverse and matthewreinbold.com on the web)