How much knowledge of cloud providers (and infrastructure in general) is typically required for a backend role?
Posted by Bozzzieee@reddit | ExperiencedDevs | View on Reddit | 36 comments
I know this depends on the role, but based on your experience, what knowledge is typically required?
For example, with AWS, I can:
- Spin up EC2 instances and manually deploy my app there.
- Use services like S3, SNS, SQS, and Parameter Store.
- Set up a database via RDS or directly on EC2.
I’m also comfortable with Docker and Docker Compose.
However, during recent interviews for regular backend roles, I feel like I’m missing something, even though I haven’t received any specific feedback.
Could it be that I need more experience with setting up pipelines (e.g., GitHub Actions or Jenkins) or using tools like EKS? Or maybe K8s?
In my last role most of this was handled by the DevOps team(excluding S3, SNS, SQS), so I'm unsure what is the general state(if any)
HashMapsData2Value@reddit
What about networking? And serverless, like lambda?
Bozzzieee@reddit (OP)
My networking knowledge is at least decent - I understand the OSI layers, know why TCP exists, how it works, as well as UDP and HTTP.
As for the others..not much.
Spider_pig448@reddit
Networking = HTTP for most SAAS companies now. Anything else is not necessary if you're not actually managing infrastructure
FatStoic@reddit
Damn it is actually true that devs don't know DNS
Spider_pig448@reddit
Sure, you can throw basic DNS in there. Anyone with a nickname already understands enough about A records. A dev has no reason to know anything about TCP/UDP though
FelineEnigma@reddit
I’ve worked on at least two problems where the solution reuses TCP ideas. I’m sure if someone without that background worked on those, they’d spend a lot longer reinventing the wheel and confidently declare later that they’ve never needed to know TCP in their career. Or maybe they’d give up and tell their manager the problem is infeasible to solve.
Spider_pig448@reddit
I mean, two over your entire career? And were these scenarios where you were the only engineer at the company with the knowledge necessary, or could you have easily just talked to a peer? People don't ever want to let go of knowledge they have and they want to believe that every dev should know everything. It's not practical, and it's not necessary. We have to eventually start trusting our abstractions and allow someone to write a REST API without understanding how transistors work.
KallistiTMP@reddit
Honestly man, you should learn at least enough to be comfortable deploying a basic k8s cluster and get a simple distributed web app running on it, from a blank slate project.
It won't help your resume. It might help with interviews, it might not. As many have said, depending on where you work you will likely have an ops team that handles all that stuff.
But having a strong practical generalist foundation will make you a better developer. The context is valuable, even if you don't necessarily need it to work in a junior role.
pheonixblade9@reddit
I'm in this awkward spot where I've worked for multiple cloud providers but never used any of them, really, and now I have to learn from the outside 🤣
rentar42@reddit
I know the feeling. "We're looking for an app developer and you worked on Android, right?"
Well .. yes ... but I worked on a very specific non-framework part that hardly any app development touches and the entire layer on top of it is magic pixie dust to me.
pheonixblade9@reddit
Yup. I've worked on azure, GCP, Android, Chrome, Chromium... From the inside 😅
Mediocre-Ebb9862@reddit
But in this case, why would you want somewhere who just uses that?
pheonixblade9@reddit
Sometimes it's time to move on ☺️
lurkin_arounnd@reddit
I'd like an apology for your part in the existence of Azure
no_life_coder@reddit
That's funny because I'm an android developer trying to learn cloud/backend in my free time 😂
So far I've mostly only done leetcode with Go
ivancea@reddit
IME, none about cloud providers, unless you join a startup. About infra, that's another topic. It would be good for you to know how to do the full E2E of a project, with whatever. For example, GH actions + terrafirm + AWS or hetzner. Anything. But for your own sake more than for interviews honestly
ivancea@reddit
IME, none about cloud providers, unless you join a startup. About infra, that's another topic. It would be good for you to know how to do the full E2E of a project, with whatever. For example, GH actions + terrafirm + AWS or hetzner. Anything. But for your own sake more than for interviews honestly
ivancea@reddit
IME, none about cloud providers, unless you join a startup. About infra, that's another topic. It would be good for you to know how to do the full E2E of a project, with whatever. For example, GH actions + terrafirm + AWS or hetzner. Anything. But for your own sake more than for interviews honestly
noirknight@reddit
When we hire developers, I don't think that any of these things are required, but are merely nice to have. I try to make the "required" skill set as small as possible when I create job descriptions and tend to put the specific technologies we use into "recommended" section. I have the patience for someone to learn our CI process, I don't have the patience to teach anyone C++ from scratch. If there are a large number of candidates knowing these some things might help differentiate you.
I don't think that cloud provider specific services are that useful to understand with the exception of S3, as that protocol has become the de-facto standard for object store access. There are a lot of use cases where you might need to store large objects and files. Object storage also has security and cost implications which can impact the design of a system.
In production, I think most people use configuration management tooling for spinning up instances like Terraform, Ansible etc. If you are not in operations, I don't think you need to know about these, merely that tools like it exist.
The two things you mentioned that I recommend a back-end developer should know about is Docker and Kubernetes. At least at my company building container images and creating sample k8s manifest files is handled by engineering. The reason developers should be involved in containers and k8s is that it impacts the architecture and design of the application.
altrunox@reddit
> However, during recent interviews for regular backend roles, I feel like I’m missing something, even though I haven’t received any specific feedback.
I think you may be lacking some depth, I guess it depends on the work/interviewer/role expectations....
> Spin up EC2 instances and manually deploy my app there.
If you gave me this answer I would think you know just some basics in AWS. The more correct answer would be you would setup ECS (or not) with a autoscalling group with EC2 or Fargate, behind a load balancer (if it's an API).
I know a lot a people say that certs don't matter, and I agree with it, but they give you a nice overview of the plataform and the tools avaliable, after I started my current job almost 3 years ago I decided to study for the AWS Solutions Architect cert and IMHO it gave me an advantage that helped me to get promoted and some extra salary bonuses. Some people also would say that providers are constantly changing, but the basics services usually don't change that much.
Also being able to use kind of IaC, terraform, pulumi, etc, would probably benefit you. It's a pain to start using, but after you get used to it you won't be deploying manually even if it's a simple toy project.
kuhtentag@reddit
It seems like you know how to do the work, so focus more on the why. Rather than focusing on the skills themselves, have opinions and be ready to design a system using those tools. For example, why would you choose Lambda over EC2 for a particular problem? Or you have messages coming in through SNS, how would you ensure they all get processed in a timely manner? How do you detect failures?
Firm_Bit@reddit
Echoing that it depends. In one role we had an entire platform team that would make these things super easy for devs. In another role I had to do it all by myself before even getting to coding.
Ok-Kaleidoscope5627@reddit
There are certifications offered by the cloud providers.
That's probably the most 'correct' answer and what they'll be looking for in an interview.
flagbearer223@reddit
I work in devops and interview people a few times a week for roles at my company. I honestly don't care if someone has a certification from a cloud provider - just if they can talk meaningfully and knowledgeably about how to build and use cloud resources. It all changes so often, and cloud providers are so full of shit when it comes to marketing their products, that I place very little stock in these certifications
xku6@reddit
Second this, certification is practically meaningless to me. Don't have it? Fine. Do have it? Well I'm still going to check you know the stuff, and I'm not assuming you actually know anything.
pavilionaire2022@reddit
Hard to guess what you're missing. Were there questions you couldn't answer?
Could it be system design? It's not just about knowing how to use those systems, but when.
engineered_academic@reddit
Knowing a little is usually enough to be dangerous. Some companies abstract it away so that developers who are not operationally or security-minded don't have to worry about it. However you should know enough to understand what is going on under the hood.
Nofanta@reddit
None to lots. I avoid companies with cloud infrastructure as that doesn’t interest me at all.
Academic-Put-4764@reddit
Would be interesting to see some cloud provider specific questions which you guys ask during interviews.
another_newAccount_@reddit
Depends on the company. Could be anywhere from completely owning the infrastructure and pipeline, to never touching it.
Good questions for the initial interview.
postPhilosopher@reddit
I’m my experience , you need enough to put a record into rds or redshift with a lambda or glue. As entry level. Maybe one level above you know how to provision and expand a iac module
Rymasq@reddit
Most pure developers barely need any knowledge because you will have an infra team that handles it and sets up pipelines.
codescapes@reddit
Majorly depends on your role and responsibilities imo. If you're architecting systems rather than just implementing someone else's designs then you really need to know the different services and how to appropriately use them etc.
If I was hiring a junior engineer for a project already up and running I really wouldn't care that much about their specific knowledge compared to whatever they can evidence as general competency. It's not hard to get to grips with most cloud stuff when it's an existing system.
The difficulty, per first point, is knowing what to choose and how to get stuff off the ground. Bad decisions on choice of cloud services can result in whole teams of people existing who literally do not need to because AWS already offers some solution for the problem.
The more senior you are the more you need to be aware of different options, design patterns, architectures etc.
alyinwonderland22@reddit
As a rule, with areas I'm a bit weaker in, I like to "go on the offensive" and start asking lots of questions in the interview when that topic comes up. Ask about their stack from start to finish, and what tech they're using. If you haven't used their tech, mention a similar one you have used. Like others have said, the requirements vary heavily from job to job, but I think the important thing is to communicate that you're comfortable learning whatever tech they're going to throw at you. Then just move on, start asking about a different topic you're more familiar with that is related, such as what their best practices are for managing database queries.
0dev0100@reddit
For my first job I required no experience
For the second I needed to know how to set up an instance of the product stack on aws using ec2, docker, mqtt, MySQL, DNS, VPN, etc
For my current job I require knowing how to use windows remote desktop manager and running installers.
The knowledge required varies depending on the role.
oneMoreTiredDev@reddit
It depends on the company, some have DevOps teams and will provide a plataform with many abstractions for developers where those only have to do a simple setup to deploy apps, and some leave most of the infra development for developers.
If you want to "proof" yourself, learn some Terraform and how to setup a more modern application infra in AWS (like using ECS and/or EKS), with CI/CD in place. Something about LB, gateways and networking is also a good thing to know.
In the end, if you have to take care of everything, it'll be overwhelming no matter what for most developers.