This is not an entire IT department

Once in a while, someone posts on X, or another platform, something along the lines of:

Dear recruiters, if you are looking for:

• Java, Python, PHP

• React, Angular, Next

• PostgreSQL, Redis, MongoDB

• AWS, S3, EC2, ECS, EKS

• *nix system administration

• Git and CI with TDD

• Docker, Kubernetes

That’s not a full-stack developer. That’s an entire IT department.

Looking at the comments below such posts, a lot of people seem confused. Two common misconceptions:

1. They think a recruiter is looking for someone who has all of these skills.

2. They think you are a full-stack developer without having (most of) these skills.

While it is not my style to include a list of technologies in job postings, I do discuss them during the screening call or follow-up interview.

Let’s unpack the list and review why I think you should actually have all (or most) of these skills (or similar ones) and why I think it’s not that big of a deal to learn them.

Let’s get three easy ones out of the way:

• If you don’t know (a bit of) Python (or Ruby), then I can wholeheartedly advise you to study one or two. For example, tinkering with machine learning often benefits from a bit of Python to glue things together.

• Obviously, you must have a good deal of experience with PostgreSQL, MySQL, or SQLite. Teach yourself how to install and use a relational database; these are useful skills.

• When you can’t easily explain how Git works and how you’ve set up your local environment (shortcuts? perhaps using a TUI/GUI?), then I’m afraid the call ends here.

Let’s strike a few more:

• It would be very odd if you couldn’t tell me about your general experience (pros and cons, for example) with AWS, GCP, or, if you insist, Azure.

• I will ask you about S3, how you’ve used it, or which alternative you prefer. I seldom speak to candidates who haven’t worked with a cloud storage service.

• We will talk for a bit about Elastic Compute Cloud (EC2), Elastic Container Service (ECS), and Elastic Kubernetes Service (EKS), or their GCP counterparts: Compute Engine, Cloud Run, Google Kubernetes Engine, etc. Again, I don’t care what you’ve used, but I do like to hear about your experiences and preferences.

Now let’s discuss *nix system administration. These days you will spend time in a terminal: running unit tests and linters, working with CLI code assistants, Docker containers, Git: so much is controlled via the command line. Additionally, many system designs are modeled after the basic Unix principle that “everything is a file”, another reason to build some *nix-fu. I often pair this discussion with the Twelve-Factor App, which touches on the Unix philosophy without explicitly mentioning it.

Let’s talk about Java and PHP. Suppose you haven’t programmed in either of them, but you are applying for a job that requires, say, proficiency in PHP. Here is where it gets tricky, since the language requirement is likely the strongest “must-have”. If you have strong proficiency in another language, try a bridge course or book like “PHP for C# Developers” so you can provide the interviewer with a solid explanation of how you can become proficient quickly. Lay out the steps you’re going to take to ramp up quickly. But realize this may be a bridge too far for the interviewer (sometimes they need people to hit the ground running).

You do need (some of) the skills that remain, but I doubt an interviewer will insist on having them all.

• React, Angular, Next.js: obviously you need to know at least one, and it’d be a bit odd if you haven’t taken the time to study competing frameworks. If you use React, for example, then I’d recommend you study Angular, Vue, Next.js, or another framework to learn the pros and cons of each. As preparation for your interview, this seems a fairly logical approach, right?

• If you have not used Redis, then just install it on your local machine and play with it, perhaps by hooking up the caching mechanism of your favorite web development framework. It will literally take less than an hour to run some basic tests (production use involves more: persistence, security, clustering, I am not talking about that).

• Regarding MongoDB: I’m completely fine if you haven’t used it, but I’d like to hear why you haven’t considered adopting it. You must be able to articulate a few pros and cons.

• Since I assume you’re writing tests, and since you may have automated your tests, the step to a solid story on Continuous Integration is not that big of a leap. And if you use GitHub Actions or something similar to help you automate CI, then that’s perfectly fine: you don’t have to write everything from scratch, certainly not the plumbing parts.

Down to the last two skills: Docker and Kubernetes. Not having any experience with containers would stand out negatively during an interview: get some experience! Whether you’ve used Kubernetes is not a big deal, as long as you can state what it does, but more importantly, why you think you don’t need it (and what you’d like to use instead), and when you think you would begin to need it.

The statement, therefore, that knowing all this takes “a whole IT department” is frankly a bit silly. You would do yourself a disservice by not trying to achieve some level of proficiency in all or most topics.