Hiring a Ruby on Rails Developer

One of the biggest challenges I’ve run in to as a manager is writing the right job description for the right job title. Get that right, and suddenly the right candidates appear in your inbox (well, at least you’ve got a better chance of getting the right candidates the first time). That being said, let’s presume you’re looking to hire a Ruby on Rails developer. Maybe it’s for a new department or project, maybe it’s to augment an existing team. Either way, there’s three levels (in my mind at least) for a Rails developer. So what are the levels/titles and their qualifications?

Junior or Entry Level Developer

These are the new developers. Call them “entry level” if you will, as that’s what they are, entering the workforce. They’re generally fresh out of school, or they’ve just finished up a coding boot camp and are looking to change careers. Either way, odds are they’ll be great to augment an existing team, especially if it’s a well established team which enforces code reviews. Using the power of the code review to help them learn the nuances of the system and the enforce good coding practices (you did write tests and they do pass, right?) will help them quickly become a solid developer.

At this level you should be looking for someone with under a year of experience, but who has taken classes in the subject and can answer high level questions about the language itself. You’ll want to know that they have a firm grasp of the MVC (Model-View-Controller) architecture that Rails uses. Throw them a coding challenge if you must, but keep it simple, and look for well commented code with simple logic. Trust me, you’ll know if they head off in to the weeds on this.

On a side note here, I’ve taught a few boot camp classes, and some of the students who came out of it were pretty darn good. I tried to “sell” one of my students to a recruiter, who then told me that none of his clients would look at a some for a junior developer position unless they had at least two years of experience in the language. That’s pretty harsh and short sighted in my opinion. If these guys had two years of experience they wouldn’t be junior level!

Mid-Level Developer

To me, this is probably about 70% of the developers out there. They’ve got about two to five years of experience with the language, have probably gained their experience in at least two different companies, and are able to code just about any challenge you throw at them. They may or may not have exposure to multiple databases, but that shouldn’t matter.

They should be comfortable with SQL in general, and should be able to speak a little to the NoSQL side of things (which is pretty much just key-value document storage, so if they’re comfortable around JSON, they’re good to go in that arena, especially if they’re augmenting an existing team). Speaking of data and databases, can they adequately explain when you should consider using seed data, and what the pitfalls of it can be?

Ask about their testing habits. Are they strict about TDD (Test Driven Development)? Do they at least ensure that there are tests for the code they write, regardless of where in the process they write the tests? Ask about their preferred testing languages and why (don’t worry if it doesn’t match what you already use, they’ll adapt).

One key item I would look for here is how comfortable they are in the console. Can they use the Rails Console for debugging purposes? Being able to run around within the console to verify and debug things is a critical skill. Beyond just the Rails Console, do they use the Interactive Ruby shell (IRB?)  I’ve found that sometimes it’s helpful to just jump in a test a theory without having to worry about the rest of the Rails project.

Mid-level developers are great for augmenting existing teams as well as starting up new ones. They can generally hit the ground running after a few days of looking at the code base and can be a productive member of the team in just a few Sprints.  At the same time, they’re perfect for starting a new team if you already have a well documented project, and possibly a software architect who has given an initial thumbs up to the project.

Senior or Lead Developer

Here’s where it gets tricky. At this point it’s not just about how long you’ve been programming in Ruby on Rails. You could easily say that anyone with over five years of experience could be considered a senior level developer. However, it’s more than just the experience level. How much are the willing to help guide the other members of the team? Do they look at the junior developers and see potential and help them to learn and grow? Or do they just sit by and let them struggle? I’ve known some developers who have over a dozen years of experience, but have no drive to help anyone on the team other than themselves. Those guys will never be senior level in my mind. I’ve met others though who are such team players, and such leaders within the organization that they naturally fall in to a senior level even though they’ve only been doing something for three years. I’d be willing to hire someone with only three or four years of experience but shows solid leadership skills over someone with seven years of experience who is more interested in just getting the minimal amount of work done and just collects a paycheck.

These are developers who help make the product owners make decisions when they have questions over if a feature is feasible within the requested time frame. They can help to scope projects because they know what everyone on their team is capable of achieving. They push the other team members to become better. With the right senior developer on the team, the results you get from the team will truly be greater than the sum of the parts.

A senior level developer is perfect for helping get a new project off the ground. They can help make the right choices in the beginning of the project, and will quickly know where they will need the most help within that project, so you know what skills you need to hire in next.

They’re also perfect if you find that you have an existing team that seems to always be struggling to fully deliver. Let the senior developer come in and help try and correct any bad habits that your current team has. Have them help coach the team while they help pull the project across the finish line.

The Ideal Team

If I had to start a new, large project from scratch, I’d look for a four person team. I’d start with one senior level, lead developer. Once they are able to help analyze the project I would have them give their recommendations as to if we needed three mid-level developers, or if we could do a combination of mid-level and junior developers.

If I was augmenting an existing team, I’d look at the current needs of the team and the seniority levels of the existing members to determine what I needed. I know that this answer is a little more vague than all the rest, but it really does depend on the skills and needs of the team as to if you bring someone junior in to train them, or someone more senior to help grow the team for you.

Can I See Your GitHub?

During the interview process I often get asked to share my GitHub account. Of course, then I get chided for not having much in it. In particular, I get questions about why I don’t have work from prior jobs in it.

Um, hello? Has anyone heard of a little thing called Intellectual Property these days? Seriously folks. Every job I’ve held has been a corporate job, and every job I’ve held I’ve had to sign something stating that all of my work is the property of my employer. This is one of the main reasons they pay me; to produce code which does things for them that their competitors are not able to do. If I were to go saving this on GitHub, or any other publicly accessible location, I could be liable for exposing industry secrets (OK, a lot of what I’ve done is commerce related, and a shopping cart is a shopping cart for the most part, but that’s not the point). If those little code secrets were really good (like proprietary algorithms, or better still passwords and hashes) I could find myself in a lawsuit. On top of that, I’ve just potentially exposed their security, making that particular site easier to hack or spoof.

Once I explain this I’ve still had some come back and ask me to share work in another manner. Wow. What part of Intellectual Property do you not comprehend? Even if I did have copies of my prior work (which would technically be illegal, even though we all know almost every developer has some snippets of code in their arsenal) why would I share that with you, once more potentially giving out competitive secrets? All I’m doing is showing you that I don’t care about the IP of any job I work at, including yours.

This is why I don’t share much on GitHub. I’ve worked hard and I’m not going to just hand out someone else’s IP, even if I wrote it, just to prove to you that I can code. I’ve been at this for 20 years. Please don’t insult my ability or integrity.

Curious about just how much I do or don’t share? You can see my GitHub account here: https://github.com/ercubed
(The only real thing shared, is the work I’ve done with teaching, so that all the students would have examples of the work once we were done with it.)

As for you hiring managers out there reading this: Do you really want to hire someone who has copies of, and is willing to share, other employers intellectual property? If they’ve done it with others, chances are they’ll do it with yours as well.

Both Sides of the Table

I’ve been through more interviews in my career than I’d like to admit. I’ve also been the hiring manager. In the end, I don’t know which is more stressful. Sure, as a candidate, you want the job (or at least I would hope you do, otherwise why are you wasting the interviewer’s time?), and if you’re currently unemployed it’s even more stressful. I get it. But stop for a moment and think about it from the hiring manager’s point of view…

The hiring manager is taking time out of their busy day. Time that they could be handling any of their regular duties. Time that very well may now have to be spend after hours catching up. If it’s a smaller company, they’ve already spent time reviewing every resume that’s come in. If it’s a larger company, they’ve still spent time reviewing everything that has already been filtered down for them by a recruiting team.  At the very least, when you walk in that door for an interview, you should have a smile on your face, thank them for taking time out of their day, and I hate to say it, but look like you actually attempted to get dressed to impress someone and didn’t just pull the clothes out the laundry basket.

What? Dress up for an interview? I know… I know… You think I don’t understand. It’s a casual work environment, everyone is in shorts and sandals, so it’s OK. Sorry, it’s not. As an engineering manager, I’m looking for engineers (duh). And what is one trait that engineers are good at? Engineers are detail oriented. When you walk in, all disheveled, unless you apologize because you just changed a tire for a little old lady on the side of the road, I’m going to presume that you are not detail oriented. Is that harsh? Probably. Still, what harm is there in showing up without too many wrinkles in a dress shirt? If everyone else shows up in jeans and a polo, stand out with khakis and a dress shirt. You can always dress to match the environment after you get the job.
(Before anyone goes and chides me for being sexist here, just know that I have never seen a woman show up for an interview in an outfit that is anything less than professional. They have always been smartly dressed. I have yet to see a woman show up for an interview in Birkenstock sandals and dirty feet!)

I know interviews can be nerve racking. Sometimes you’ll stumble, and forget answers to technical questions that you know you know the answer to. Don’t worry, don’t panic, take a breath and approach the answer from a different angle. Explain that you are embarrassed that you can’t remember the actual term, but here’s the explanation over how it functions. Ask to get up and draw it out on the white board. Don’t just say I don’t know or I don’t remember; turn it in to a discussion to show your thought process (as long as you stay on topic!)

What about after the interview? Some people say that you should follow up in a few days to see where you stand. I’d be careful there. Too soon and the manager may not have had time to fully compare you with other candidates. Too late and you may be forgotten (let’s hope not!) Too often and you risk aggravating the manager. I know one manager who would actually reject you if you called too many times to find out the status of your application. I guess the squeaky wheel doesn’t always get the grease…

Here’s where managers need to step up a little. I know things are busy, but as soon as you know the candidate is not the right candidate, let them know. It can be as simple as a form email or, if they’re exceptional, but just not the right fit, you can personalize it to let them know your reasons for hiring someone else or give encouragement over other job types you recommend they look at based off of what you learned about them (nothing wrong with telling someone that the role they applied for is “too junior” of a position for someone of their caliber.)

As a first time manager, remember the pains you had when you were on the other side of the table. Help the candidate feel at ease. Communicate with them before, during, and after the interview process. You don’t have to hold their hand, but you should come across as human to them. If you don’t, you run the risk of them not accepting your offer.  No matter what though, be sure to let the candidate know if they are not moving forward in the process. Under no circumstance should you leave them in the recruiting black hole, with no way of knowing where they stand.

Hopefully this is all common sense to everyone. I just have yet to see this sense in common use.