Meteor interview questions?


#1

I’m interviewing a few people for meteor projects and wondering if anyone has a set of questions on meteor specific topics?

for internal devs i’m generally not huge a fan of very domain specific knowhow, but this is for some outsourcing work and it’s quite a burden to bring people up to speed on meteor remotely.

It maybe also useful training to go through such a list of meteor topics myself, I’m sure I’d learn something!

If we have a thread with various questions, I can compile into some type of document.

I guess there are many good resources that could be used jeopardy-style to turn into questions, like http://www.meteorpedia.com/

What else would you ask people? Questions graded beginner/intermed/advanced?


#2

I believe if a meteor dev can craft a custom publication using observeChanges or at least can walk you through the offical docs’ example (room counts) then I believe they either know how to solve, or at least know how to learn how to solve about any meteor task.

If they can’t do that, I think it is just a waste of time.

Because, it takes a decent developer who has not written a line of javascript less than a few weeks to get to learn javascript and meteor enough to do that.

Otherwise they are either not good devs, or not interested enough in meteor development.


#3

First I would advertise you are looking for people with at least 5 years Meteor experience. :wink:

I think the best coding interview question is always “show me something you’ve built.” And “if you don’t have anything to show, build this:” If you are picking an athlete for your team, their knowing the rules of the sport matters a little, but not nearly as much as a demonstration of what they can do with the ball.


#4

It probably depends on what you are building, but we look for strong JavaScript developers with some kind of experience using a node.js framework. Candidate should be strong with underscore and jQuery. Mongo a plus. If they claim Meteor experience we want to know what packages they can speak intelligently about. We’d like to know what they think of some of the packages we use, or why they aren’t using them. Also if they’ve made any packages of their own (we’ve made many) we’d like to see what they created. Some packages we use include:

jquery
reactive-var
reactive-dict
amplify
random
aldeed:template-extension
nemo64:bootstrap
aldeed:autoform-select2
natestrauser:select2
aldeed:autoform
aldeed:collection2
lepozepo:accounting
useraccounts:bootstrap
natestrauser:animate-css
pfafman:font-awesome-4
mizzao:jquery-ui
chrismbeckett:toastr
iron:router
momentjs:moment
enteye:spinner
sanjo:jasmine
gadicohen:messageformat
anti:fake
konecty:mongo-counter
msavin:mongol

One good type of question to ask is, “if you could change anything about x, what would it be?” x could be Underscore, JavaScript itself, their favorite Meteor package, or something about Meteor. People who aren’t really using and thinking about these tools have a hard time saying anything coherent when it comes to thinking about how they could be improved.

Also if you want to watch them code to see how proficient they seem, Codio and Nitrous (collaborative coding environments) are great. You can quickly setup a Meteor environment on Codio with a few clicks, pull in a GitHub repo and give them a task.


#5

you know how oDesk etc will have “javascript top 5%” and other badges, be nice to have a “Meteor” one too.

it would also be helpful to have some type of online test people can take that had timers, since its so hard to make up questions people can’t just google right away. which would be fine except they’re really just represeting their randm findings on google and not their consistent knowledge level.

For that reason I generally prefer a little bit open ended stuff, but that becomes hard to evaluate objectively or quickly.

I know Arunoda has meteor hacks which runs with interactive questions. Another site called FreeCodeCamp gives you a public profile of what tests you’ve passed. That would be much more useful…

It might be nice to have some type of wiki way of building out this thing, and it could then turn into a “Meteor University” to answer all the questions raised? Hey, there’s an idea for a startup :slight_smile:


#6

Some off the top of my head:

  • Explain how Fibers make it easier to work with Meteor than MEAN?
  • When should you use wrapAsync or bindEnvironment?
  • What is the oplog used for? Which advantages does it bring?
  • What is a reactive data source and how does it differ from a non-reactive data source?
  • Tell me how to make any data source reactive (let’s talk about observe and observeChanges)
  • How can you ensure that sensitive data is only sent out to authorized clients?
  • What means to implement proper authorization (not authentication) would you use for a multi-customer application?
  • What’s your prefered routing package? Why do you prefer it?
  • How many packages have you built? Can I see them?
  • Where do you put API keys and credentials for OAuth providers? (Do they know settings.json or service-configuration)

There could be so many more , but I’ll leave it here :slight_smile:


#7

Good question about sensitive data!

Been developing with Meteor for two years but can’t answer some of those (fibers/bindEnvironment) :wink:


#8

Wonder how many people know the answer for those questions in a platform that hit its 1.0 version 6 months ago.

I mean, if you really want a cutting-edge developer for a really complex app in a short period of time, go for it (and mind your pocket). Otherwise you may face problems when recruiting Meteor people.

Just bear in mind that besides being a really brand new technology, Meteor also encompasses frontend, backend, database and server management. It’s different from hiring people just for taking care of specific environments of an app.

In short: Meteor is too big and new for everyone to know everything. But luckily has a smooth learning curve and an awesome package system and community. Maybe people could rethink the way they are looking for people.

Just my 2 cents.


#9

Agree. It’s a challenge. There are a lot of amateur Meteor developers out there who are trying to capitalize on Meteor’s popularity and demand for talent by offering their services. In our experience (we’ve launched a half-dozen Meteor apps, some in production since meteor 0.6), many of these developers are charging $65, $100, and $150 per hour and they really suck at Meteor. Several contractors I hired started subcontracting work to other non-Meteor javascript devs and creating “agencies” with developers who they were trying to onboard with crash courses in Meteor so they could capitalize on client demand. It’s a disaster for some unfortunate clients.

I think the best way to really vet someone if you aren’t an expert yourself is to hire someone to do the vetting for you. A bit of a chicken-and-egg problem for many I’m sure.

I’ve worked with 8 meteor devs, for several months each, over the past couple years, and at least half of them produced code which we had to completely refactor because of their harebrained approaches. Hate to say it but buyer beware! Many of these devs don’t deserve even $35/hour wages. You are heavily subsidizing their learning curve. That’s true to a point with nearly all software engineering but especially true with something as new, large and rapidly changing as Meteor web app dev.

Success depends as much on project management excellence as it does on developer skill and experience.


#10

@maxhodges,

I totally agree with what you just said.

I started learning Meteor about 5 months ago. Fortunately, (or unfortunately depending on how you look at it) I lost my previous job as an iOS dev and I have been studying Meteor full-time since then. I have been trying to diligently learn all the best practices as I go. Of course, at first I did things in a messy/complicated way, but I’ve been striving to continuously improve my knowledge of the framework.

However, I actually have been hired by some people who are doing exactly what you describe when they do development. It’s a mess and the more I learn, the more I see how terrible some of the code is and that they don’t care to adhere to the 7 principles of Meteor. It makes for a bad experience and things need to be refactored but they don’t want to take the time to fix it because they’re trying to push products. It totally defeats the joy of what Meteor is and It becomes a chore to work with it.

I have a sincere love for Meteor and I hate to see it being used so horrendously.


#11

Yeah I wish I had a bit more time. I’d like to start maintaining a best practices guide. Its terrible that the popular tutorials use Session and organize files poorly–everyone learning meteor ends up just copying them.


#12

I’d love to see how you organize your files! and a best practices guide would be so unbelievably helpful haha.


#13
[client]
|--[views]
|----[posts]
|------events.js
|------helpers.js
|------templates.html
|------styles.less
|------routers.js

as far as file structure, download and explore a copy of this repo. very clean code.

http://git.libreboard.com/libreboard/libreboard/tree/master


#14

This is not really Meteor related, but this post from Aaron Schwartz is a valuable read if you want to hire devs: blog post. You could easily apply it to a Meteor context…


#15

These questions are great! I guess one more to add on to that would be to have to person describe and/or map out on a whiteboard the way data flows in a basic Meteor app. It shows if they understand how various parts of the platform fit together.


#16

Is even Meteor around for 5 years?! I hate companies looking for Senior React Dev when it’s around for like 1.5 years at most and is usable for maybe last year.


#17

here’s a link to the topic mentioned by @serkandurusoy


#18

last name is spelled “Swartz” actually