I’m sure this subject has come up multiple times on these forums, but I thought I would explain my specific scenario to see if anyone has any advice.
First, some background. I have been in web development for nearly 3 years now, focusing mostly on front-end, as well as some PHP on the backend.
With Meteor being new, what are people looking for when they hire Meteor developers? Since there are no real experts in the stack yet (especially considering how quickly it is changing), what specific skill sets are desirable? I guess the other issue with Meteor being new is that the few open positions get snapped up quickly, by people more qualified than I. I guess what I mean to ask, is aside from playing with Meteor (publishing packages and/or deploying mini-projects), what can I be doing to make myself stand-out in the current landscape?
Corvid’s points are right on par. Any experience as well with NoSQL databases/MongoDB in itself is also a major plus as well as general knowledge of the stack as that’ll help you resolve issues at scale.
Myself, I can’t wait for the market to mature a little bit because I’m anxious to take a Meteor job rather than just working on it and having a blast with side projects!
Awesome. These response are quite helpful. I think by becoming more active in the community, will also lend me some credibility, so I am going to try to get more active in my participation on these forums and other avenues.
I am very excited for the Meteor community (and subsequent demand) gain
traction across more development shops. Think about how prevalent Rails
is/was. I really love Meteor and think that a LOT of people can benefit
from it. As a developer, it allows me to create kickass apps in very little
time… who can argue with that?
My company is looking for full-time Meteor developers in the Bay Area. If you guys are interested feel free to email me at lucas@qualiaescrow.com We are working on a big desktop, enterprise application. Let me know!
I think a good way to look at experience with Meteor is to not tie it so strongly to Meteor. For example, reactive programming can be used elsewhere, isomorphic code is elsewhere, etc. The theory behind them is more important than the specific implementations. What if Meteor does fade in a year or so (I sincerely doubt this and hope not!), then yourself as as Meteor developer is almost useless, but, the theory that you now understand, and your experience implementing it, is not useless at all.
