I don’t find that the topic of “insert specific tech here” developer vs, well, just software developer, is discussed a lot, possibly because nobody cares about it, but it’s something I think about from time to time. So, even if no one cares, I’ll write about it anyway, to get my thoughts out of my head 🙂.
(Note that I’m using developer as a kind of generic term, considering these thoughts hold for other related roles, for example, architects).
My thoughts are around does it make sense for developers to put themselves in little boxes like this? Likewise, does it make sense for companies to be looking for such specific skills in developers?
Before proceeding, It might be worth clarifying what I mean by “insert specific tech here” developer. I’m thinking about folks that associate their job with a particular tech stack, in more or less broad terms, for example: .NET developer, Java architect, etc. This also applies to job posting, e.g. company XYZ is looking for .NET developer.
From a job seeker’s perspective
Let’s start thinking from a job seeker’s perspective: does it make sense to specialize and market yourself in a particular tech stack? Does it make sense to only consider jobs in that particular stack? Well, it depends (don’t tell me you weren’t expecting this answer 🤣).
Starting with the specialization topic. I wouldn’t say specialize, but I do think it’s relevant to have at least one tech stack or language where we have a bit more of a deeper level of knowledge. This helps not only with that stack, but also if we need to do things with other stacks, as it’ll be easier because we know what parallels to try and draw. If we just have high-level knowledge on one or multiple stacks, it’ll be harder when we need to do something more complex than we’re used to.
As for self-marketing and only considering jobs in a particular stack, that comes down to personal preference, so the best I can do is share my own, with an example: given the choice between developing the most boring and/or irrelevant applications in C#, versus working on interesting distributed systems with, let’s say, Python (which is a language I’m not particularly interested in), there isn’t even a contest, just sign me up to write some Python.
Of course there are stacks I’d rather not do. For example, it’s unlikely I’ll touch PHP (again), and I’d probably flee from a C++ situation like the plague, but other stacks? If the overall context of the job is interesting, that won’t be my biggest concern. Ruby? Meh, but if we’re solving relevant problems with interesting technical challenges, whatever. Elixir? Hell yeah! I’ve been more focused on object oriented, but I hear there’s also fun to be had with functional languages. You get the point 🙂.
Coincidentally (or not), the most interesting job opportunities I’ve come across lately, are exactly the ones where it’s clearly stated “we use language X and Y, but anyone with relevant experience with A, B and C is also welcome”. As an example, if someone is experienced with C#, it’s shouldn’t be particularly difficult to jump into something like Java, Kotlin or even Go, so this kind of approach makes the most sense to me.
Also, massive bonus points when tech stacks aren’t imposed. If I’m being hired as an experienced developer or architect, that should be the kind of topic where my opinion should be important (that’s not to say it would make sense to get a new job and replace the whole existing stack 🤣).
From a hiring perspective
Just like there’s no simple yes or no answer to this question from a job seeker’s perspective, I also think there are different things to consider from a hiring perspective.
As you might expect, given what I’ve written in the earlier section, in general, I don’t think it makes sense to only consider candidates with knowledge on the particular tech stack(s) that are used on the job in question, but I concede that there are situations where a different approach is required.
For example, the hiring/contract type (e.g. freelancing, short-term contract/consulting, long-term/permanent, etc) can be a deciding factor. If we’re hiring someone for a short-term role, it makes sense to try to get someone who can hit the ground running. The problem I often see though, is companies hiring for long-term roles, and even then being fixated in hiring people with a close to 100% match with the job requirements.
In my opinion, for a long-term role, pre-existing knowledge of a specific programming language or tech stack shouldn’t be a major factor. As long as folks are interested in learning, which should be the norm in our profession given how fast new technologies pop-up and other ones fade away, evaluating this kind of specific knowledge while valuable, shouldn’t be the priority.
An example: if we’re hiring someone to build microservices with C#, .NET, ASP.NET Core and related, at first glance, which would you think would be the better positioned candidate: someone with experience working with microservices in Python, or someone with experience building Windows applications with C#, and maybe some simple ASP.NET web applications? I’d tend more towards the Python developer, as the complexities associated with something like microservices are far greater than with learning a new programming language and associated ecosystem.
But I think we could go even further. For more senior folks, sure, relevant experience in the types of applications being built on a specific job, architectural patterns and things like that are important (though not “you need to know it all” important), but for more junior/mid roles? Knowledge of development fundamentals, as well as willingness and ability to learn is more important, as well as understanding if that translated into them being strong in the specific area and tech stack they’re working on, which should be a good indicator that they’ll be able to reproduce that success working with us.
As an anecdote, one of these days I interviewed a strong candidate. In a discussion, I learned that some hiring managers in the company immediately dismissed this candidate just by looking at the profile, because the candidate had not been focused on a single tech stack, and hopped a couple of times to learn new things. I was baffled! So I interviewed a candidate which was clearly above average, considering the ones I’ve been interviewing, and hiring managers weren’t interested based on something I actually consider a strength? 🤐
Just to wrap up this section, didn’t want to forget to note that there are, of course, other things to consider, specific to each job, so there can be situations that can have different requirements. For example, hiring someone to work on operating systems, or maybe even games, there’s very specific knowledge associated with these kinds of roles, so the reasoning I described above might not translate that well to these cases.
Oh, and yet another potentially relevant note: in some particularly complex business domains, it might be that having prior knowledge in said business domain is more relevant than any particular development skills.
Going on a slight tangent on recruiting
Since we’re on the topic, while a slight tangent, it might be interesting to also comment on recruitment approaches, particularly on platforms like LinkedIn (maybe some recruiter is reading this and can adapt the approach based on this feedback?).
By now, you probably figured I don’t think about myself as a .NET developer/engineer/architect/whatever. I think of myself as a software developer/engineer/architect/whatever, that happens to be very experienced with C# and .NET, but I also worked in other tech stacks in the past.
When talking about places where we market ourselves (e.g. LinkedIn), I think that more important than specifics of languages and stacks, is presenting our interests associated with software development (e.g. my main interests are APIs, microservices, distributed systems and other related topics).
I try to present myself in this way, so that when I’m approached to discuss a new job opportunity, the recruiter or hiring manager has a better idea of what interests me and what I would bring to the table in a new company (which is far more than just some programming language knowledge).
Sadly, while this works sometimes, with more competent/interested recruiters, it’s not the norm. More often than not, the approach is more on the lines of: have C# or Java or whatever written on the profile? Send message, even if the rest of the job details don’t match the potential candidate’s interests.
I get this kind of things all the time. Some examples:
- “We need a C# developer with more than 3 years of experience” - sure, I have more than 3 years of experience, but if that’s the main requirement, it’s unlikely it’s a role that interests someone like me, and you should be able to understand that from my profile
- “We need a Java architect with deep knowledge of Spring” - probably didn’t read the profile, cause there’s Java in there, but not Spring (and if we go back to the previous sections, I don’t think that’s what should be looked at anyway)
- “We have this great position, hybrid environment with office in [some random place]” - again, didn’t read the profile, cause it’s written there I only care for full remote positions
In my opinion, good recruiters should understand these things, cause that’s exactly the value that they should bring to the table. Otherwise, shooting messages based on keywords, could be an automated process (and probably is in many sad cases).
That’s it for this post, which I think isn’t a rant this time (though there might be a pinch of ranting here and there 😅).
As I said, it’s not a topic I see discussed all that often, maybe it’s something people don’t care about, but I do, so figured to add my two cents to the blog.
Summarizing, in general I believe we shouldn’t put ourselves in little boxes associated with a particular programming language or tech stack, as, at least for me, that’s not the highest priority when I’m looking for a job.
From a hiring perspective, while there are circumstances where hiring very specific skill sets is the way to go, I consider that in most situations, that’s not the case, and we shouldn’t optimize the hiring process to assess very particular tech stack knowledge.
What’s your take? There’s no comment system on the blog, but happy to discuss on the socials, which you can find linked in the blog’s footer (or maybe header, if you’re reading this at some point in the future where I felt like revamping things 🙃).
Thanks for stopping by, cyaz! 👋