A a friend of mine said he could recommend me to a junior DevOps role at the company he works in, but I’m interested mostly in back-end development and DevOps is not really something I like. The question is: could I use experience as a DevOps to later switch to back-end? Edit: more detail
In most companies, most of what a devops “role” does would be handled by backend devs anyway. Plenty of crossover between a devops role and a backend dev role. The important thing is to get some work experience anywhere in development to make yourself look way more appealing in future job applications.
It depends if it’s a real DevOps role, or an operations role with a DevOps title because it’s trendy. In the former case, the role should include some kind of backend development.
Devops is a nice skill to have for a backend developer, however I’m not sure it is fair on your friend if you take a role you don’t really want and might not perform well in.
I agree with input’s input, regarding devops skills being highly beneficial for a BE dev. It’s knowledge that has gotten me better pay, and better job security.
Absolutely, especially si if you don’t have a background in software development. Operations tasks a typical “DevOps engineer” does can help you understand the big picture, the concept of a server or service or a batch job. Configurations , environment, initialization, logging, integrations. It will introduce you to a lot of failure points - network problems, load problems, balancing problems etc.even some domain language - what’s this or that service for, what is it doing, for whom. The usual way to come to backend is e.g. from school with very little of such experiences. You would come with all these ideas already as known problems. You would also learn a lot of the dev process, team work, documenting how to run something. You’ll pick up basics of programming through bash and python and similar scripts. Even read some “proper” code once in a while.
After a while when you get settled, you’ll learn a programming language on the side. But you’ll only learn the syntax, standard library, idiomatic ways to loop or something. The problems to solve - which IMHO is often a weak point of many trainings and tutorials - will be a known thing to you, not abstract made up ideas.
So yes, you can use the DevOps role experience in your future work as a backend developer.
You can. But if you aren’t actually interested in devops then you won’t be happy.
deleted by creator
Devops is not a position in itself. It’s supposed to be a software development and operations philosophy.
I suppose you are trying to say this is a operations heavy position. And you are not interested in operating systems. And that’s cool. You don’t need to unless you want to. But if you really want to be a good, or better than good developer, it’s great to know about the systems. How they are operated, how they are constructed, how operators think.
So to answer your question yes. However is that the best way for you? Only you can answer that.
Devops is not a position in itself. It’s supposed to be a software development and operations philosophy
This is the definition I know but unfortunately the term seems to have become a modern synonym for system admin/engineer.
Such a role might still provide valuable experience for a backend dev if there’s an opportunity to write production code for internal tools as well.
Developers at my company need to have a deep understanding of the environments they deploy onto (microservices, scheduled workflows, etc.) which can include configuring canary testing, rolling deployments, status probes, setting up and using monitoring, and very occasionally intervening to restart or redeploy running software. But these are secondary skills compared to writing code.
the term seems to have become a modern synonym for system admin/engineer.
True, but the distinction still holds value. If a company has a DevOps role defined, you can derive from that what kind of a company you are joining. For example, they hire based on marketing and not based on merits, which tells you something about the colleagues you can expect to be working with. It also tells you about how they structure work and that hierarchy and bureaucracy may play a bigger part in getting your work done than you might like.
Good point and an interesting take. As you said this could be a good signal, when taken in context with the other limited information we get as employment candidates, about internal development practices.
Consider that you might have more advantage for future career, as many engineers these days don’t want to tinker with Ops stuffs. But you do need to focus also on programming skills (such as automation scripts) , not only configuration skills (aka YAML engineers).
