Most job descriptions want X years of experience in {language or framework}. Unfortunately, they rarely care how many technologies you know. They're looking for years of experience generally, and experience in their tech stack specifically. I'd recommend picking the tech you feel most comfortable with and building out a couple of bigger projects. Maybe put them on GitHub as part of your portfolio.

To be honest, if I were a hiring manager my concern wouldn't be that you don't know Ruby or Elm well enough to build something valuable; it would be that you haven't been deep enough into any one project to understand the pitfalls and roadblocks associated with an enterprise-level, long-running product. I see programming skills as mostly portable from language to language, but you definitely need some kind of specific experience.

If I were you, my goal would be "Jack of all trades, master of one."

I'm in a very similar position but rather I moved out of development a good few years ago however I still have the developer bug. My current work is still within IT but I sit more in a solution architecture role now utilising my broad knowledge to help integrate IT solutions into new and existing business environments.

With that being said, I spend a great deal of time working on my own personal projects whilst at home which invariably result in the picking "the right tool for the job" and learning something new. This has resulted in precisely what you describe, I know a bit of everything and I'm not afraid to jump into a new language, framework or concept if I think it is the right tool to use. This has led me on to learning and experiencing great products and services, I've learnt back end and front end work, dev ops and a good amount on security and enterprise set ups. I wouldn't trade any of this in for the world, whereas I used to be a purely c# .net developer who built web apps. I now have days working on automating server provisioning and program deployments with ansible, building out logging solutions using kappa architecture, catching up on vue.js and its fast front end development or quite happily working away at my next node.js app or python deep learning scripts whilst at home. When I'm at work (contractor) I utilise all of this knowledge daily because the clients rarely care about the latest trend, they want a working solution.

This broad knowledge has been a real asset and I consciously made the choice to switch my career in this direction as I hit a lot of self doubt in my c# days where I felt I would stay as a junior developer, never being able to learn "everything" to move high enough up the food chain (I was young and hungry for success). I decided to use the skills I had and the general interest I had in new technology to continue my career in the direction I am going right now. I have to say, sitting with various "IT roles" across the many organisations I've been able to now work on and talk shop at level of detail that shows I know what they are on about just as much as I am able to convey what I need from them has helped me out a great deal. Cutting through the product names that are thrown around by many tech heads and understanding what process they are discussing has allowed me as an architect to offer alternatives or to validate their thinking.

Even quite recently I ended up in a discussion around re-platforming my clients website away from Sitecore to what they felt would be better served with static files. One of the front end developers was hell bent on the new project being all in React and there was no one else there to question why other than at a high level. Due to "being a master of none" I was able to talk through with the relevant users and indeed the developers themselves what React was, it's history and it's alternatives. The pro's and con's from first hand "messing around" experience and whether I have seen other frameworks in the market which are emerging to play in the same space.

Don't ever doubt that a master of non is not a useful tool. You just play a different role in the organisation/your career than what you believe is the route you should be taking. The "Specialists" will always be better at their chosen subject, they will always know more about a deep aspect. That's why they get paid for their specialist knowledge, however for me, they are a weapon to be utilised and aren't the answer to every solution. Be comfortable in knowing that whilst the "market" may not appreciate your generalist skills, an employer will love them. The bang for the buck out of a generalist in the right role is way better than requiring numerous specialists if the tasks are varied.

This thread also has some good answers

raises hand

Yes because I have a job. However it does make it harder in the interview process. I would recommend focusing on being really good at one language you love to work in and that's reasonably popular. I choose JavaScript. The funny thing is after I have a job people love that I'm well versed in many things. It's just a weakness in the hiring process.

Jack of all trades is who companies hire.

Sure, they tell you they need a front-end developer, but in all the years you'll be working there you'll probably develop what ever is needed, not only UIs.

For sure you'll have issues when switching jobs, but then again you'll want to work at a company that doesn't care to upgrade their recruitment process?

You can also differentiate the positions from their title, "react developer" means they have no idea what they doing and what does it mean.

I'm thinking of ways to enforce the word "generalist" on my resume.

Yes. And no at the same time. As others pointed out in the comments it is a pain to deal with during the selection process but an interesting skillset to have during actual work time.

My advice is to get a core set of skill you are confident and good at (not especially awesome, just good) and keep a wide panorama of knowledge about other technologies.

For example, I'm a Java and Kotlin developer. I work as such and I know the language very well alongside many of the top open source frameworks for it. But I'm skilled in Ruby, NodeJS, ReactJS, Angular and Go too. Not very skilled, but enough to keep projects going.

That makes it easy to pass interviews for Java development positions while pleasing my employer with a more versatile skill set.

I can't speak for other CTOs, but when I'm hiring developers to be part of the core team I primarily look for two things, 1. having worked on complex problems and 2. having worked on more than one platform/language/framework.

Almost anyone can learn some basic skills and throw together a simple mobile app, or a CRUD web application and such. It's when you get beyond that that real skill and creativity comes in... when you run into problems of scale, when you run into the limitations of the framework and so on. Solving those kinds of problems is what separates a good developer from a mediocre one, not how many languages they know or how many trivial RoR apps they've built.

That said, it takes the perspective of having worked on more than one framework to really understand that there's more than one way to solve a problem, and to actually know the strengths and weaknesses of platform X. That's why I am wary of one-trick ponies, no matter how good they are at that one trick.

Programming languages are not THAT different from each other, and a good programmer in language X can typically figure out the basics of language Y in days and learn the idioms and patterns in a few more weeks.

My advice to you would be to work on more complex problems rather than just scratching the surface of a lot of things. It hardly matters what it is, what platform it's on or what tools you use. For example, you could try to solve some pending issues with a popular open source project and get a pull request accepted which will teach a lot of valuable skills---working with other people's code, navigating large unfamiliar codebases, writing code that other developers can easily understand etc.

I'm kind of all over the map, and I know there are businesses that like that sort of thing. I try to concentrate on something I really like, mostly front end, with some back end skills to "hook up into" if required (if this even makes sense). I have the same education as many back end devs, so I understand the full stack... but I chose specifically more front end if possible. I started at as a print designer back in the day (I'm now super old, maybe?). Marketing folks tend to like me for web work.

Essentially I try to find a place where it works for me. What do you like to work on? I like deving more on the front end, talking to end users and people a lot and being involved in decision making on features and paths to be taking with business need. I tell them how many years spent on a language working, tell them where I'm comfortable with what, and then branch out from there, talk soft skills and other aspects, too. It takes all types. I've been all over different types of sites from CMSs to large enterprise to software-as-a-service that is a large codebase, adding new features, fixing bugs, etc. I like to think I traveled. :)

If I was seen one dimensional for just my tech stack... well, they're missing a lot on the hiring process. I try to have conversations when I'm being hired to get a good idea of why I might be brought on board, too. I have certain project sensibilities, certain culture considerations and team ideas. I'm more curious of the business side and how it runs. Sometimes it's not a technical issue, sometimes it's a mix and I try to suss it out and find the fit. I steer conversations to the benefits and differences between me and potentially other hires -- what my strengths are and some blindspots (we all have them!)

I have done a remote position before -- and also managed a remote person before. Remote means there are different metrics they may look for to ensure output and certain personality -- I'm not saying you're not, but it's kind of part of the concern at the hiring table. What concern would you have if you were hiring for overseas and remote?

Feel like we are forgetting that the saying goes jack of all trades master of none, *but oftentimes better than a master of one. *