If you were looking at automation or SDET roles, how much does the tech stack that the team is working with factor into your decision to apply or accept?
For example, if a company had a great team, great benefits and some of the tech stack appealed to you, how much would the bits that didn’t appeal to you weigh in on the decision to apply or accept a role?
I literally made a choice like this last week. Both companies were in the same industry, both teams were lovely and both companies would involve heavy automation. I chose the tech stack I was familar with as opposed to a tech stack I had not worked with before. This has been a factor with the last two roles I have had. I do keep picking the familar stack but I am at a point of my career where I’m not sure of myself in relation to automation. Once I have more experience I think the tech stack won’t affect the decision as much and it won’t be as high up on the requirements.
Interesting, your experience mirrors my own in that I’ve usually gone for roles where the majority was a stack I was familiar with but there were some things that offered me learning potential.
Tech is easy, it can be learned. Once you know one language/tool/framework, it becomes relatively easy to see the similarities. Learning a new one is then usually a matter of getting familiair with the new syntax and structure and you’re good to go.
Company culture is way more important in my opinion.
I must admit I haven’t ever worked with PHP but one of the companies I interviewed for lately were 50/50 JS and PHP and I could not get this out of my head
I’d be more influenced by company/team culture and conditions than the tech stack - even if there’s something in there that’s an utter pain to deal with, it’ll be a lot easier to cope with the pain if you’ve got a good supportive team around you. On the other hand, working on familiar tech with people you don’t get on with, or within corporate structures that make your life a misery does not counterbalance being in your tech comfort zone - I’d far rather deal with unfamiliar or troublesome tech and boost my experience than be stuck in an unpleasant work environment.
Echo most of the others - tech stack is low on the list, and generally not a deal breaker. I’m more interested in things like the culture of quality, what opportunities/challenges there are are for the test role, how big the org is, etc.
Sure, there are things that would make me cringe a bit, but unless you’re going to work for a FAANG or a startup, it’s rare that you don’t have legacy systems and similar pain points.
I guess this means the QA tech stack and not the Dev tech stack. I think that the importance of the tech stack depends on where one is their career and what are their next career goals. It might also depend on one’s financial goals and desired work locations.
The QA stack matters a lot to me now. I feel I am still early in my career. So, I want to be in a tech stack which has been around for a long time, continues to be improved, has lots of learning material, stack overflow questions etc. Once I figure out “general problem solving” with one tech stack, then I will feel more confident to try others. Additionally, I avoid tech stacks which have low code or no code tools. It generally feels like we work for the tool instead of the tool working for us.
As an aside, if you want to convert to Dev, then tech stack can matter. If you want to be a backend dev, then maybe you should not take a frontend tech stack. Remember that you also have to pay your bills. So, maybe avoid tech stacks which are dying or likely to die. If work location matters, then probably avoid an uncommon or exotic tech stack. Its most likely to be used in big city companies & hence a problem if you want to move to a small city.