By Phil Freo, TechCrunch – December 02, 2012 at 02:00AM
Editor’s note: Phil Freo leads the engineering team at ElasticSales. Previously he was at Quizlet and Google. Follow him on Twitter.
There is often confusion about the various roles of a web engineering team. I have had to explain, even to technical recruiters, the differences between these roles and that the lines that separate them are often fuzzy. I thought I’d share the framework I like to use to evaluate whether someone is a good fit for a startup’s technical team.
In a startup, you can’t afford to have people who are only able to do one thing. Someone could be adept at writing HTML/CSS, but if they don’t have a great eye for design or know JavaScript well, it’s just not worth having them on the core team. Similarly, somebody who knows a little bit of everything but isn’t advanced in anything will just drag the team down.
The size of the company or startup will determine how many different hats each engineer must wear. Many startups get off the ground with a single founder who does a little bit of everything until he or she can grow the team. It’s also possible to outsource some roles completely. Just as cloud-hosting providers such as Amazon Web Services have drastically reduced the need for hardware/network engineers in web startups, platforms like Heroku take it further and (for a price) can reduce sysadmin and DevOps work almost entirely in the beginning.
In pretty much every case, when a startup grows, people will inevitably start specializing. Even those rare gems, who in the early days can spend the first half of the day in Photoshop and the second half scaling a database, will eventually specialize at least somewhat. If you’re hiring well, you’ll always find someone who can outperform you in at least one area.
I’m a big fan of “full stack” people and think specializing too much, too early, is a bad sign for startups. At Elastic, each of our engineers has written CSS and done database/server management. It’s good when a problem arises for there to be more than one person capable of fixing it. That said, I’m spending the bulk of my day writing in JavaScript/Backbone.js because I enjoy it much more than a coworker who’d rather be in Python as much as possible. That’s healthy and it works.
Here’s an overview of the main functional areas on a full-stack web engineering team:
Visual Designer
- Uses Photoshop and delivers PSD or sliced assets of pixel-perfect, beautiful designs.
- Hangs out in Dribbble, Behance, and Forrst.
- Should be judged on their portfolios and their understanding of user needs.
Frontend Developer
- The basic frontend developer can create basic web pages with HTML + CSS + minimal JavaScript/jQuery. Titles include “web designer,” and “web developer.”
- The advanced frontend developer makes web applications come alive in the browser. Writes large, well-organized CSS- and JavaScript-heavy apps. Often uses frameworks like Backbone.js/Ember.js. Titles include “software engineer,” “frontend web engineer,” “UI engineer,” and “JavaScript developer.”
Backend Developer
- Writes server-side code like Python, Ruby, PHP, and node.js, as well as web frameworks like Django, Rails, CodeIgniter, and Express.
- The basic backend developer generates dynamic web pages and interaction with databases (MySQL/MongoDB/etc.)
- The advanced backend developer, beyond CRUD apps, are the all-star programmers who aren’t afraid of big challenges. They understand performance, big data, concurrency, etc., and they intimately know multiple data stores, such as MySQL, MongoDB, Redis, and memcached. Titles include “software engineer” and “backend engineer.”
Sysadmin/DevOps
- Sets up servers and manages config files, monitors server health, sets up load balancers and web servers (Nginx/Apache), manages database scaling and backups, monitors database load/performance, etc.
- Writes Puppet/Chef, bash, and config files.
- Hangs out in Server Fault, Nagios, Secure Shell (SSH) connections
We like to evaluate engineering candidates based on a combination of breadth and depth. Candidates need to be proficient in two or more main areas. And the fewer areas they’re comfortable in, the more of an expert in those areas they need to be. You shouldn’t hire for single hard-defined roles, but rather across a spectrum of skills. For example, some good fits for my team right now could include:
- A designer with an amazing portfolio, who is also comfortable doing frontend implementation in HTML/CSS.
- A frontend developer with tons of HTML5/JavaScript experience and loves Backbone.js, a good eye for UX, and understanding of REST APIs and basic database concepts, but does not need a ton of backend coding experience.
- A full-stack developer who is equally comfortable writing in-browser JavaScript as well as database-backed features on the backend, with at least a moderate amount of depth on both sides.
- A backend-only person who can both write in Python/Flask for the site, as well as manage and scale our server and database infrastructure to be blazingly fast and stable.
Rather than separately trying to fill the four job descriptions that I mentioned earlier, hiring people who have the right blend of breadth and depth across the spectrum is crucial.
There are many other important criteria for evaluating engineering candidates beyond where their skills fall on the web technology stack. People should be considered overall and judged on a team/culture fit, the ability to just get stuff done, product sense, communication and problem-solving skills, and experience with production systems, to name a few. And while having a well-balanced team overall is crucial, remember that technical fit is an important part of it. So figure out how many hats you need somebody to wear, and go find the engineers that will best fit on your team.