Ask HN: How to gain a meaningful experience at work?

Dealing with almost the same situation myself I switched from working in mobile to backend recently and having a hell of a hard time getting anyone to sit down with me (I have 8 years of experience).

Frankly it’s making me want to quit. I wonder how this company will succeed with this culture. (Already got an offer with 30% increase in base).

(I suggest you take it).

This is something that you need to discuss with your manager or the tech lead on your team if there is one. Tell the manager that you would like to work on "main service" and would appreciate if you were assigned to sprint tickets related to that, once you start working on those tickets explore from there by asking further questions about the things you don't have context for. For a lot of other things you need to ask-

> Our team unsurprisingly works on one specific service, which is 90% black box to me because nobody has the time to introduce me to the domain.

I am sure atleast one person would be more than willing to do that if you asked, they might even appreciate getting an hour break from their usual grind.

> Dedicated devops team handles all infra/CI/CD, and I have no idea how and where the app is deployed, I only know we use k8s and docker for that.

Again, you need to ask. As someone committing code to your app, there is no reason for you to not know how and where the app gets deployed even if you are not handling the actual deployments. This is not even optional, someone on your team has to walk you through the process otherwise there is a latent background risk of there being an issue due to not understanding the context of the deploys or not knowing what to do when a change you make breaks something (and it will eventually).

Here’s a way that has worked for me.

You’re going to do things hundreds if not thousands of times each year at the job. Each time you do them again, it is a wonderful time to ask “Why?”. Why do we scrum like this? Why do we not make time to share domain expertise? Etc. After asking “why”, then ask yourself “how might I/we” with regards to a better path forward.

You’ll be able to see your own individual path of things you can change to make your life at work more enjoyable, but the most enjoyment I get is challenging the status quo especially if everyone else feels the same way and nobody largely knows why things are the way they are. Talking to people helps you realize that nothing is really set in stone and can bring more meaning into what you want to get out of the job.

I did a lot of challenging at previous job and it was relatively friction free because our team was tiny. Here we have full-house of scrum masters, product owners, business analytics, architects and whatnot, and each raised topic should go several rounds through them, and most of suggestions hit the top management wall who say that we're already behind the schedule and keeps hiring new engineers. I guess I have to learn to play politics at scale

I would venture to say that you're likely working on a distributed monolith rather than microservices. There are many varying definitions but the two key ones are that they have bounded-context/do-one-thing and that they are small built by a two-pizza-sized team or could be rewritten in two weeks. Another property is that they should be able to do what they do without tightly-depending on other services (e.g. calling them and awaiting a response to continue). I would expect to understand what a microservice does and how it does its thing simply by looking at the data/communication schemas, source code, and maybe a little upstream and downstream.

Unless you are very curious about the details of different ways 'microservices' can be done wrong, there's little reason to stay and try to understand what's there. I could be wrong, like if the reason it doesn't make sense is lack of domain knowledge, in which case it may be worth staying and getting a view, but the environment doesn't sound very conducive for learning.

> Dedicated devops team handles all infra/CI/CD

Side-topic: I thought DevOps was supposed to be the opposite to this - but this is my experience too.

On-topic:

If you really can't get someone to sit down with you, you could ask to attend some meetings and try pick up on what senior engineers are talking about.

'"n years of experience" line on my resume would mean nothing. How do I prevent that?'

That's a good question. One that I failed to address in my career. I would say just focus on the tech (AWS, a language, microservice stuff like toggles/versioning). But that's just my guess.