I know how to start a product with a wide spectrum of languages/frameworks/tools, but I don't excel in any. I can make a good native android app with medium functionality, but I don't master the design and layouts. I can make a minimal Ruby on Rails app, but nothing more. I can make a small game in Unity 3D. I'm learning Elm, JS, and ReactJS, but I can't really build anything with them right now.
I usually learn technologies when I need them.
I'm trying to get hired overseas or work on a remote position, but it seems like a bit hard.
Should I just quit applying and focus on learning a narrow set of skills, or do companies hire learners like me?
Top comments (16)
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.
This thread also has some good answers
Liquid error: internal
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."
Sometimes roadblocks and bottlenecks I've found to be team and people problems at times... nothing necessarily to do with programming. Ever had a group project where things just went sideways at school?.... lol
Thank you Isaac!
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 is quite encouraging! thank you!
It's worth pointing out your comment: "Should I just quit applying and focus on learning a narrow set of skills, or do companies hire learners like me?"
The world changes, markets change, the desired skills change. Someone who is capable of learning will never fail, they will adapt. I've been contracting now for 3 years and I often visit a contractor forum, especially a thread titled "state of the market". I see so many posts from people who have specialised in a particular skill that have sat on the bench for 6+ months unable to get a job, especially a job close to home because their skills are no longer in demand.
Sure, there's going to be a few die hard businesses out there who need a cobol or fortran developer but let's be realistic one day that need will vanish and the jobs with them. For someone who specialised in just this one area, they will need time and a lot of it to re-develop themselves. They will sit at the first rung of the ladder all over again where other "specialists" have been keeping up with new frameworks and have years of knowledge ahead of them.
The generalist has adapted and found a career where the generalist skills are best utilised, which for me is architecture but for you may be something else. But the important fact remains, you are a learner and have the drive to adapt. Do not paint yourself into a corner when others have no other choice but to do it, whilst it appears you have options.
I am wondering how to search for such a "generalist" positions, would they have any specific in role title?
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.
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.
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.
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?
raises hand