What The Latest API Job Market Data Predicts

I love me a good API industry survey. I appreciate the vendors and analysts who carefully craft these questions and share the aggregated answers from their customers with the rest of us, often for free. I always learn something.

However, there's also something that has bugged me about this approach. When a tool vendor asks their customer base or social media followers to fill out a form, a phenomenon called selection bias occurs. Not only are those that respond not an accurate sample of the industry as a whole, but the results are only from those with time or inclination to respond.

Surveys and polling can still provide valuable signals or inspire additional lines of inquiry. But as I look forward to 2024 and beyond, I'm less interested in what companies say and more in what they're actually doing. How are companies hiring, and what do those open positions say about the API initiatives they're undertaking in the new year?

Surveys reflect the preferences or experiences of a specific group, whereas job listings provide a more neutral view of market trends. Further, culling details from the help wanted signs could signal emerging trends and technologies that are just beginning to gain traction. This can be more current than surveys, which may lag due to (mostly) capturing what has already occurred. Finally, by analyzing job listings, I aim to identify gaps in the market where demand for certain skills or technologies is not being met, which is not always apparent in survey data.

So, for those reasons, by the latter part of 2023, I convinced myself I needed to analyze some API job data. Getting that data was post-worthy in its own right. Months of vendor selection, script development, and data engineering followed.

I'm excited to share this first set of insights as part of the 2024 APIFutures collaboration. APIFutures is an API community project to identify the biggest challenges and upcoming opportunities in the API space. The new year is the perfect time to rediscover the paths before us. It is also a wonderful opportunity to discover a wider, bolder, and more diverse set of API thoughts to enrich your 2024 initiatives. (Just promise to finish this piece first before exploring the other Futures waiting for you. ) ;)

The Premise/Methodology

I sourced all job descriptions from Google Jobs Search via SerpAPI. Google Jobs Search aggregates job postings from both individual business websites and those large job boards with tens of thousands of listings (Indeed, ZipRecruiter, etc.). To help stay within the project's budget, I limited data retrieval to open API positions in the United States.

I then saved the raw search result job descriptions to a PostgreSQL database. During the save, I apply a series of data engineering scripts to de-dupe, extract, and enrich each job description. Part of that process includes calling the OpenAI API for additional summarization and inference. Given the per-call price, this was also the source of ongoing optimization to minimize overall costs.

I started initial tests throughout August and September. I then scaled up to capture all posted API positions in 2023's Q4 (October, November, December). Based on who's hiring and for what, here is my analysis on what's in store for 2024.

API Work is Everywhere

One of the first things I wanted to know is where the API jobs are. A challenge in the Q4 API jobs dataset was that not all listings had an easily discernible location. I then plotted the approximately 38% that did on a map, with greater size and deeper color indicating more activity:

Perhaps unsurprisingly, the Bay Area around San Francisco, the Dallas-Fort Worth metroplex, and New York were the top locations for API work. What was less expected was the amount of activity happening in places like Atlanta, GA, Chicago, IL, and around Washington DC - API initiatives that far exceeded the total seen in other "traditional" tech hubs like Seattle, WA, or Austin, TX.

Of course, that was for positions with on-site or in office requirements. Shockingly, nearly 50% of the API jobs with discernable work arrangements listed 'remote work' as an option. And despite the 'return to office' drumbeat throughout much of last year, hybrid arrangements (ones where employees are allowed to work from home several times a week) remained popular.

Most API Roles Are Either Senior-Level Development, Architecture, or Product Management

But not all API work is the same. In my gathered job listings, what roles appeared most often? This required a fair amount of work, as job titles and role expectations are not uniform across companies, let alone entire industries.

After defining a base set of criteria and then carefully evaluating them against each job's listed qualifications and responsibilities, I arrived at the following breakdown:

"Software Developer" being the most sought-after role is not a surprise; in many places, APIs are still primarily viewed as a technical concern, and you'd rely on technical people to implement them. "Software Architect" also makes sense, as somebody with a higher-order, more holistic awareness of how the pieces fit together should be involved in API efforts.

What was a pleasant surprise was the health percentage of API "Product Management" sought. Applying sound product management skills to API development remains a priority for successful API initiatives, and I'm intrigued to watch where this number trends in the future.

That said, the job listings I studied strongly imply that those sought for API development were not entry level.

REST Remains the Top Architecture

When GraphQL first launched in 2015, I remember the consternation caused by claims that it was "what came after REST" or "the REST killer". Based on what companies are hiring for, REST-ish or RESTful architectures remain the thing being built. In fact even SOAP developers were more in demand, albeit only slightly, than GraphQL talent. Perhaps a lagging indicator? I will need to watch how this develops over time.

A surprise to me was the high percentage of job listings that alluded to Event-Driven API development. These mentions of rabbitMQ, Kafka, or cloud vendor message queue imply a very healthy amount of API development happening outside the "traditional" request and response loop.

When working on API descriptions, "Swagger" - referring to how an API is represented, not the SmartBear tool suite - remains stubbornly lodged in developer nomenclature. Not only is it name dropped when the job listing clearly is referring to OpenAPI requirements (ie 'Swagger 3.x'), but the job listings themselves conflate the issue, for example, listing "openAPI (fka swagger)" as a requirement.

JAVA, Apigee, and Postman Are Tops in API Dev Shops

Next, I turned to how companies expected API implementations to be performed. One of the first places of interest was which programming language or frameworks were explicitly called out in developer job requirements. As seen below, the hiring companies still love their Java tech stacks.

Also, an important consideration when hiring API help is previous experience with existing API gateway and management products. While there are many options, they aren't very evenly represented in job requirements, at least not in the United States:

* Others referred to the combined percentages of Axway, Software AG (webmethods), WSO2, Tyk, Solo.io, and Ambassador

Finally, I need to cover the types of tools that were referenced in my dataset. Developing and using APIs including many activities. Actions like design, discovery, documentation and testing often require a suite of tools. Increasingly, a tool that starts out in one area, like a lightweight client, will add features that make it useful in another, like automated monitoring.

Ultimately, trying to maintain rigid classifications in order to, for example, find "the most popular documentation solution" proved difficult. Some IT shops may use Postman collections for their catalog needs. Others may facilitate discovery with a Backstage-powered portal while relegating Postman to ad-hoc testing. Guessing how tools would be used within companies based solely on the job description doesn't seem possible with the data I have, at least not with any confidence. Ultimately, I counted which API related tools appeared most often as part of requirements or qualifications. That said, mention of these specific API tools occurred in less than 8% of the total number of job listings - it just doesn't seem like communicating what gewgaws newly onboard folks have access to is something often advertised in a job description (at least, not yet).

Other API tools seen but were statistically insignificant were cURL, Paw, Tricentis, Up9, mabi, Readme.io, ReDoc.ly, RapidAPI Hub, Backstage, and Cortex.

2024 Is Only The Beginning (?)

Analyzing API-related job listings for software consultants can offer strategic insights for business development, talent acquisition, and market positioning. For technologists, seeing this information could provide direction for skill enhancement and formal training. And, for company executives accountable for strategy, this analytic approach to industry trends could influence talent and vendor management decisions.

That's powerful on its own. However, if I continue expanding on this, I could see several additional threads worth pursuing:

• Expand the scope, both beyond the US and over an extended period
• Dig deeper into posted salary values, in particular how they differ both geographically, by seniority type, and by role (product manager v developer, for example).
• Map company names to industry categories to infer which sectors are heavily investing in digital transformations or API integrations
• Bucket identified companies to general sizes (startup, mid-sized, or enterprise, for example) to highlight how role mix and requirements change with scale
• Correlate tech stacks and architectural preferences to geographical region (from eyeballing, the Pacific Northwest seems like a hotbed for .net/Azure development due to the long influence of Microsoft in the area, but can that be quantitatively demonstrated?)
• Explore how well are the job requirements for roles, like product management, defined. Are HR departments repurposing whatever PM job descriptions they have available and slapping API in them? How many are conflating project and product management?
• Create an interactive geographical map that allows for "drill-downs", rather than just a static image.
• Determine whether jobs are contract versus permanent. This might imply the stability and long-term investment in API projects.
• Infer which types of API work are afoot by analyzing multiple, simultaneously posted job listings for the same company. Can we see legacy modernization initiatives or the development of a new mobile experience in the people sought?

You might have some ideas, as well. What questions would you want answered if you had a database of all API job listings?

Wrapping Up

Thank you, thank you, thank you to all the paying subscribers over the past year whose support has made this project possible!

As I mentioned in the previous newsletter, I am evaluating alternatives to Substack in preparation for a move. Since I published, Substack removed five publications, in what is perhaps the daintiest fig-leaf this side of David:

[N]one of the publications removed had paid subscriptions enabled and accounted for 'about 100 active readers in total.'

I strongly believe we shouldn’t cede public spaces or institutions to those that would use them to do harm. However, Substack, is a private company. As such, it is neither a public space or an institution. Refusing to “cede ground” and staying on Substack is not a noble stance. Rather, it is an empty gesture that only continues to contribute to an organization with different priorities than those held by a majority of rational 21-century people. As Ryan Broderick says, it is time to leave Substack.

As for alternatives, I've considered Beehiiv, Buttondown, WordPress, and several others. Currently, the non-profit Ghost is my leading choice, but I haven't begun the migration process yet.

In the meantime, I've paused all recurring monthly payments from paying subscribers on both Patreon and Substack. I've also noted the annual supporters - one of the challenges is how I manage the transition of annual members to the new system. Most have some concept of 'passes' to exclusive content, which I would extend to annual members until it was time for their renewal. However, ensuring that all works as seamlessly as possible is graying more hairs than I care to highlight at the moment. And then there’s all the link updating that will need to be done… *sigh*.

More to come on that front. Until then, check out some of the other intelligent, engaging visions of the future! You just may find your new favorite API writer or show host. Check the fascinating, thoughtful, and pressing insights on API trends over on the APIFutures hub.

Till next time,

Matthew (@matthew in the fediverse and matthewreinbold.com on the web)