Working in a software developer productivity team, how good is that considered?

how good does that look on your resume?

Unless it's a brand name, whatever's on your resume will only be considered for 10-15 seconds tops. software developer productivity team is super specific and won't even cross a hiring manager's mind on what that's all about. backend engineer will be more salient as to what you did at that role.

Should I consider giving interview for this role?

For me, I would use it as practice if it's worth the time. Most roles usually aren't, and it's like the Secretary problem where the chances of your next job being better than your current job—and if your current job is your best job—is statistically low.

If you are not the type of person who's deeply passionate about making development processes faster, I don't recommend this role. However, you could interview anyway for practice, just like Michael said.

Every company is different, but I can say that software development in Engineering Productivity (EngProd) is generally very different from that of an engineer that works on part of the stack for an external facing product ("product engineer"). I was on such team for ~1 year, and it wasn't a good fit for me at the time.

For anyone else interested in knowing what it's like to be an Engprod engineer, keep reading.

EngProd's goal is to help is to improve the the development experience of product engineers and speed up the delivery of product features. As such, a big chunk of your job is to figure out what are some of the issues slowing down the teams you support. It's rare you will be handed well-defined projects, at least compared to produce engineers of similar levels, because EngProd teams don't generally have PMs.

Usually this involves digging very deep into test frameworks, release automation, etc, tools that help your fellow engineers be more productive. You then would need to dig deep and figure out whether these tools can address existing problems. And yes, you would also have to figure out what these existing problems are in the first place. You are basically the PM, the TL, and the Engineer for the project, all at once. This can be tedious (you might have to dig into the internals of build tool) but rewarding work (can save lots of engineers ton of time).

As such, I find being an EngProd engineer really hard for more junior engineers, since it takes a lot of (1) self-driven product exploration and solution specification (2) an inherent understanding of what makes a "good development" process vs not. (2) is especially tricky because unless you know how to be productive already (or at least what productive looks like), it's hard to figure out where the problem might be for your fellow engineers.

But the role could be good for more senior people who already know the productivity bottlenecks and wish to have organizational impact. This would be especially good for those who love building tools for fellow developers more than shipping their PM's next priority, for example.