How to Recruit and Build an Effective Team of Developers

Hiring great developers is one of the top challenges cited by many technology startups, if not THE top challenge. It doesn’t have to be that way. Here is a technique that will help you put together a high-performing, cost-efficient, and loyal team of technical engineers. I’m writing this from the standpoint of software engineers, though I have been told it could apply to hardware engineers as well.

The premise is to have the right mix of junior developers to veteran developers (perhaps a 80/20 mix), because:

  • New developers are relatively easier to find, especially from schools and development boot camps.
  • New developers can be easily trained and don’t come with a lot of baggage.
  • New developers can bring new ideas to the team that may challenge traditional ways of thinking.
  • Veteran developers can act as mentors and share best practices.

From a recruiting standpoint, it is easier and less expensive to find and hire novice developers than experienced ones. A lot of large corporations already know this. That is why you often see Google, Facebook, and Microsoft on college campuses. Startups need to do this too.

Changes to Recruiting and Team Building

This has repercussions in the recruiting process and team dynamic though.

Recruiting Senior Developers

  • Strong technical skills are of course required. System architecture and design skills may also important, though it depends on your needs.
  • Interpersonal skills are especially important in this model, specifically the ability to coach others and communicate abstract concepts clearly.
  • Including other developers on your recruiting team to help you attract senior developers will really help.
  • This person does not necessarily need to be a manager or team lead. There can be separate manager/lead and senior developer on the same team, where the manager/lead handles more of the interpersonal tasks and the senior developer handles more of the technical tasks. The key is to have someone experienced enough to coach and guide the junior developers. This is both good for career progression and recruiting ease, because good developers are attracted to teams from which they can learn.
  • A person that embodies the first two points well is not easy to find, though you will have an easier time having to find a few of them vs a whole team of them. If you find one, compensate that individual well. You can also train someone for this role with a combination of opportunities within your company and workshops outside of your company.

Recruiting Junior Developers

  • Interviews need to be more about assessing potential, innate talents, and the ability to learn, than gauging existing skills. These are traits that interviews would assess anyways, but most technical interviews aren’t set up that way. Most interviewers may find it difficult to assess such traits, but this is an interviewing skill that can be learned.
  • Include your senior developer on the recruiting team. Junior developer candidates will get to meet their potential mentors right away and both sides can ascertain if there is a good fit.
  • As a startup, you won’t have the same salary and perks a large corporation can use to attract candidates, so sell them on your mission, impact, team, and learning opportunities instead.
  • I should add that “junior” does not mean “young.” Age has little correlation here. Some of the best developers I know changed careers later in life and still share the same energy and ability to learn as recent college graduates.

Training Junior Developers

  • Both the manager/lead and the senior developer (or the same person, if one individual has both roles) hold a key role in training the junior developers. Work with them to set up training plans for each of the junior developers.
  • Establish an environment for constant learning and collaboration. This can include code reviews, paired programming sessions, informal brownbags, formal mentoring programs, etc. For informal brownbags, encourage the junior developers to host them and share something they learned, even if they aren’t considered the “expert” of that particular domain. Teaching a topic is a great way to learn that topic.
  • Such an environment also requires a company culture to match. The culture needs to be supportive, open-minded, and willing to take risks. Setting such a culture needs to start with the company’s founders and leadership team.
  • This also means giving junior developers opportunities to own aspects of the codebase while getting support on their system design and code. Don’t simply throw junior developers into new features all on their own. Have regular check-ins and code reviews to guide them along the way.
  • Training doesn’t need to only be technical. If a junior developer aspires to be a manager one day, offer leadership opportunities and training. And if not, make sure your organization has a technical career path.

With the right environment and guidance, these junior developers eventually became senior developers that can help mentor other new developers and continue the cycle as your organization grows.

By Teaching, We Learn

“Docendo discimus.”
– Lucius Annaeus Seneca

Back to school: USACE engineer interns in Europe to mentor students on academic futures I often want to teach something I just learned. This may not be great for the people learning from me (sorry guys!). But I love to share the cool things I’ve learned from others.

For example, a year after I become a technical manager at a large corporation, I started offering management workshops to aspiring leaders on my team. This was the first time I had been formally managing people, though I had a strong passion for it. I consumed classes, breathed in books & blogs, and met with experienced managers to better learn this craft. I also made a lot of mistakes along the way, and took note of each painful lesson I learned.

Before each workshop, I crafted a lesson plan. I picked a central topic, researched various opinions & approachs for it, and related a personal story of how I’ve seen or tried to implement it. Feedback from the attendees shaped what I taught in subsequent classes, though I loosely followed an overall outline too.

My first few workshops probably sucked. I like to think that they got better over time. I hope they did. My management skills improved though, from both having to think about and explain various topics, to hearing suggestions from the attendees. Ironically, even though I was the one teaching, they ended up teaching me a lot too.

Later, I started offering general business workshops for my entire team. I thought I could make each software engineer more effective by helping them understand the motivations behind the actions of our business leaders.

At that time, I wasn’t formally in any kind of a business role. I was still a technical manager. But I dealt with product, buisness development, and marketing teams often enough to get a sense of their motivations and ways of thinking. That, and I consumed classes, breathed in books & blogs, and met with experienced managers too. This helped a lot when I took roles as a product manager and product director later in my career.

I may not have been the best teacher, but hopefully I imparted my teams with some useful knowledge. For myself, these experiences have been incredibly enlightening. I thought I was the teacher, when in reality, I was really the student.

Photo by: USACE Europe District

How to Find Great Software Developers

I’ve been asked by at least ten people in the last two weeks how to find great software developers. Skills range from CSS & JavaScript to Python/Django & Ruby on Rails. Wherever they are in the technology stack, the plea has been the same:

“How do I find these people? I need more of them TODAY!”

I consider myself damn lucky to know a strong network of great developers. But no, you can’t hire them. Practically all of them have fantastic jobs already. The rest are starting their own companies.

So instead of turning this network over to these hiring managers, I’ve been telling them how I found the developers in the first place. Here is what I told them.

  • First, it helps that I was a developer too. My programming skills have waned a bit, but I understand the programmer mindset and lingo. If you don’t have such a background, have a developer be a part of the technical recruiting team, either as an evangelist & advisor, or full-time member. They will be able to communicate with potential candidates better than non-developers can. This is a key differentiator for your company over other recruiting teams.

  • Next, craft an enticing job description that includes your technical vision describing how you plan on accomplishing the overall vision of the organization. Developers care about the success of the organization because they want to be a part of something great, but I have also found that having a grand technical vision is key. Just stating that the developer will work with XYZ technologies isn’t enough. Draw them in with the technical challenges and lofty aims. This technical vision has to sound immense enough to be daunting, yet exciting enough for candidates to say, “Holy crap, I could never do that myself. I need to be a part of the team that will do that!”

    If you don’t have a technical background, ask your developers to help you write the job description. In my experience, many will give you a plain & straightforward job description. They won’t include any of this visionary detail. To get it, ask your developers to describe the most exciting parts of their jobs. Then ask your technical architects and senior developers about their grand technical vision. You can take this material, edit it for clarity, submit it back to the technical contributors for a sanity check, then publish it as your official job description.

  • Third, search through typical developer hangouts. Github. StackOverflow. Various StackExchange sites. Hacker News. Developer mailing lists. Developers’ blogs. Developers’ Twitter accounts. There are dozens upon dozens out there. Or perhaps someone enterprising enough will build their own way to scour these sources.

    Ask your developers which communities and blogs they frequent. Visit each of those sources. If it’s a blog or Twitter account, check out who they link to, who they respond to, who they mention, who they write about, and who they quote. Blogrolls and Twitter lists can be especially helpful. Not all of these people will be interested, or even qualified, but they make up the peer group of your target audience. Through them, you will be able to find lots of promising candidates.

    For the online communities, it is important to pay attention to their rules. Some frown upon job listings, some welcome them, and many now have job boards. Use those job boards. For an extra bonus, keep track of the number of candidates coming from each, the number that get interviewed, and the number you actually hire. Not all communities are created equal. Some will give you a better return than others. You can use this data to make your searches more efficient.

  • Fourth, identify which candidates are worth interviewing. Like I said, not all will be qualified. If you have a technical background, you can look through their public code or ask for code samples. If not, have the developer on your team help you. The goal at this step is to identify who is at least worth a phone call. Your organization’s procedures may differ, but I generally prefer code samples first, phone call second, in-person interview last. All of this is possible within a week or two if you hustle, depending on the speed of the candidate’s responses.

    For some roles, I have also sent candidates an at-home exercise. If you do this, make sure the exercise looks fake enough that the candidates don’t think you are trying to get free work out of them (and, it should be said, DON’T try getting free work out of a candidate) – while at the same time make sure the exercise effectively tests for the skills you seek.

I should note that this entire process is time-consuming. It is not for the faint of heart. I had a busy schedule while doing all of this hiring, but made it a priority anyways. Other tasks had to fall off my plate. Investing time into an effective recruiting process is worth it if you want to find great developers.

T-Shaped Skills, I-Shaped Skills and Dash-Shaped Skills

The term T-shaped skills – also known as T-shaped persons or simply, T-skills – is a metaphor for the depth and breadth of a person’s skills. What do they mean?

T-Shaped Skills
A person with a deep (vertical) expertise in one area, and a wide (horizontal) yet shallow knowledge in other areas. This person typically excels in one specific domain, and can also do a fair job in others.
I-Shaped Skills
A person with a deep (vertical) expertise in one area and practically no experience or knowledge in other areas. This person is typically known as a specialist. Their expertise is usually deeper than a T-shaped person in the same discipline.
Dash-Shaped Skills
A person with a wide (horizontal) yet shallow base of knowledge, and no discernible specialties. This person is typically known as a generalist. Or, more derisively, a jack-of-all-trades, master-of-none.

It is generally believed that T-shaped people are the most desirable, though this differs with the situation, environment and role. I tend to favor T-shaped people for startups and leadership positions. Some of the best managers I’ve known may not have a deep technical skill, but a deep leadership aptitude.

I avoid I-shaped people in startups because you need an organizational infrastructure in place before you can support I-shaped people well. But once you do, they tend to excel faster than T-shaped people in their particular roles.

I don’t find many people who are true dash-shaped people. Most have some kind of specialization in something, no matter how deep.

This skill metaphor unfortunately doesn’t map explicitly to one’s actual skills. Some of the most successful people I know have multiple vertical lines extending from their base of skills. In other words, they dominant in multiple areas while having a broad understanding of other disciplines. Too bad there’s no letter for that.

Photo by: TooFarNorth

Biz Idea: Software Developer Sourcing Tool

12_resume Here’s an idea I’m surprised doesn’t exist yet. At least, I haven’t heard of one. If you know of one, please let me know!

Back when I was a technical manager at Yahoo! (YHOO), I had to wade through hundreds of resumes given to me by our recruiters. After feeling desponded about the poor quality in the candidate pool, I started looking at the people behind the developer blogs I read. If the person was awesome, I sent that person an email to try attracting him/her to Yahoo!. Sometimes I succeeded, sometimes I failed. But when I succeeded, that person often became a fantastic hire.

I later discovered that this is called sourcing in recruiting parlance. And it was not something hiring managers do regularly, though they perhaps should. However, many are too busy. After all, that’s why there is a recruiting department, right? I was busy too, but I realized that great hires made my work easier. If I spent more time up-front hiring great people, then I could better optimize my time downstream.

To be fair, the HR team at Yahoo! noticed me doing this, then had a dedicated recruiter follow my techniques to scale them across the company. This recruiter and I spent a lot of time fine-tuning our sourcing & evaluation process. She is now a rock-star technical recruiter working for an amazing startup, and I have no doubt she will help them find incredible people.

Target Market

The actual users of such a tool would be recruiters and hiring managers. The buyers will generally be within the HR organization, as they own the vendor relationships for such tools.

Source Inputs

This tool would focus just on software developers. It’s possible this can be extended to other roles though, such as visual designers. More on that later.

There are some great online communities for software developers. A recruiter could look through these communities and pick out a few based on their contributions and participation level. It’s important to note that a developer’s reputation score in a specific community isn’t a direct correlation to being a good employee; many of the best software developers I know have a low profile on these communities. But it’s still a fair criteria. The communities, or inputs into this tool, are:

Then there are some more generic inputs that can flesh out a candidate’s background and personality:

Primary Inputs

This tool would go through these primary inputs and filter out a list of potential candidates using broad filters such as programming languages and location. Further filters could be applied to improve the relevance of the list.

The first input is GitHub, a social code repository popular for hosting open source software. Developers who participate in open source projects have their code and commits shared publicly. This means anyone can look at and evaluate their code. Whenever I evaluate a candidate, I always ask for code samples. GitHub saves me the time spent in asking and waiting for a response. Instead, I can look at a developer’s GitHub account and easily examine examples of their work.

The fine folks at GitHub realized that recruiters & hiring managers were doing this and built the GitHub Resume, an easy way to view the highlights of a developer’s contributions. This snapshot is nice, though it’s still important to dig through a candidate’s code.

There is some debate as to the value of the number of followers a developer has on GitHub. I would use the follower number sparingly. The quality of the code is still my top assessment priority.

The second input is StackOverflow, the most popular question & answer network for software developers. Again, a developer’s reputation on StackOverflow may not map directly to his/her value as an employee, as some great developers don’t put in the time necessary to cultivate a high reputation. Instead, look at the quality of individual answers as an example of written communication and concept clarity. It’s tough to explain complex code, but doing so well is a great sign.

The fine folks at StackOverflow know their value to recruiters & hiring managers and have a great job board. They are also working on a resume builder, similar to GitHub’s.

There are other niches within their StackExchange family, such as ServerFault, Programmers, Mathematics, Web Applications, Android Enthusiasts, Game Development, and more.

Syncing up a members’s profile on both GitHub and StackOverflow would be key. Not all members use the same username, however, so it would take some thinking to map a single member. I would start by trying to match the username and then website. There are also other profile elements, such as profile image and location. This is a tough enough problem that it arguably will be a barrier to entry for competitors.

Secondary Inputs

Once a list of candidates has been sourced from GitHub and StackOverflow, each profile can be fleshed out using information from LinkedIn (LNKD), Hacker News, Quora and Twitter. I personally don’t find Facebook as useful, though other employers may.

LinkedIn can provide a candidate’s education and previous work experience. Getting to this data would require authentication, so some thinking behind the user account structure of this tool would be required. For example, is there a master account that grants access to others? Or does each user create his/her own account? My gut is to have a master account that pays for a certain number of seats, though there are many alternatives.

Hacker News is a forum created by Y Combinator. This community originated around programming and startup topics, though some long-time members argue its focus has widened, bringing down the quality of the overall community. Whatever the case, many non-developers are members here, which is why HN is a supplementary resource rather than a primary one. Once again, a member’s karma on Hacker News isn’t a direct correlation of employee value, but that member’s answers may be useful.

Quora’s value is similar to StackOverflow and HN’s – the member’s answers may provide some insights into the candidate’s communication prowess. Since Quora covers a wider range of topics, this source can also offer a peek into other areas of expertise (if the candidate has many answers) or interest (if the candidate has many followed topics).

Finally, there is Twitter. For me, Twitter provides a glimpse into the candidate’s current frame of mind. All of your research could be for naught if you see the candidate tweeting about leaving this career behind to become a monk. It’s also possible to discern the candidate’s interests via Twitter. For some employers, Facebook can provide similar data if it is publicly available.

Other Sources

If the candidate has a self-hosted blog or hosted blog on Tumblr, Posterous, WordPress, etc, that would be relevant as well. Bonus points if that blog contains lots of entries on programming.

And last, but not least, is the candidate’s contact information. Somewhere amongst all of this information should be a way to contact the candidate directly. Sometimes their email address will be directly visible. This tool should harvest that email address. Other times, the email address will be hidden for either privacy or spam reasons. To reach those candidates, you may need to send them a message via LinkedIn (as an invitation request or through a LinkedIn Premium account) or a contact form on their blog (if one exists). I wouldn’t suggest a public venue such as Twitter for contacting a candidate.

Just about every developer I’ve sourced offers some way to contact him/her. This tool should be intelligent enough to find that information.

Final Output

The final product should be a list of potential candidates. A relevancy score could be added, though I’m not sure about its accuracy. I don’t believe the inputs paint a clear picture of a candidate – they only offer a fuzzy image. But say you build such a tool and notice some patterns of quality. It’s certainly imaginable that a relevancy score could be constructed if you have enough data. This, I would argue, should include data on your organization’s particular needs as well, since every company is different. As is every team. In other words, a good relevancy score should mean: this particular candidate is XX% relevant to this particular hiring manager within this particular department of your particular company.

From this list, the hiring manager can view more details about each candidate. The details would include:

  • Name
  • Current location
  • Contact info (direct email address or link to a contact form)
  • Sample code from GitHub
  • Repository membership on GitHub (own or participating repositories)
  • Programming languages used on GitHub
  • Answers from StackOverflow
  • Topics participated on StackOverflow
  • Answers from Hacker News
  • Answers from Quora
  • Education details from LinkedIn
  • Current & previous work history from LinkedIn
  • Personal website URL (and most recent blog posts)
  • Twitter account (and most recent tweets)
  • Reputation scores on all community sites

These listings could be emailed to the recruiter & hiring manager while the position is open. Ideally, this tool would hook into HR’s existing candidate management tools, such as Taleo (TLEO), Kenexa (KNXA), SuccessFactors (SFSF), Peopleclick Authoria, Bullhorn, Zoho Recruit, Recruiterbox, Resumator, etc. Yes, this is a huge market. There are a lot of players, big & small, old & new, that help manage candidates & employees. But they are all relatively weak at sourcing, especially for the niche of software developers.

Business Model

This sourcing tool would work well as a premium subscription. A free query with limited results could be offered to test drive the product, with carefully placed upsells to promote a subscription.

I touched upon this briefly, but having a master account holder for an organization may be the easiest model for users, since it’s generally a single buyer within the HR organization. The buyer can then purchase a monthly subscription based on the number of seats, or additional accounts, he/she wishes to give out within the company. There should be an easy upgrade path – like a single click – in case the account hits the seat limit.

I would experiment with this model a bit. It’s possible a seat-driven model drives some users to share accounts, thereby avoiding this payment system. I would highlight the benefits of individual seats though, because knowing an individual hiring manager’s needs can aid in the relevancy of the candidates as well as the potential relevancy score.

There are other payment models to consider too, such as number of search results and number of saved searches & positions.

Enhancements

Other inputs could be added, such as GitHub competitors Bitbucket and CodePlex, or social coding game coderwall. Other developer forums could also be added, such as SitePoint, Dev Shed and CodeGuru, as well as niche communities for specific programming languages, like the Android Developer Forums, Apple Developer Forums, Ruby on Rails: Talk, jQuery Forums, etc. The list is vast.

The candidate profile screen can be continuously tweaked and optimized for hiring managers as well. Perhaps they’d like a photo of the candidate. Or not. A/B testing is our friend here.

Other Markets

I don’t have the market size of software developer recruitment handy, but there are many other professions to consider beyond this one. The value of this tool is its ability to use very niche and relevant inputs, sync a profile across all of them, and return the necessary criteria for evaluating a candidate. For software developers, this means code samples and answers in related topics.

What are other roles that have rich online communities and profiles? How about those in the creative disciplines? For visual designers, possible inputs could be portfolio sites such as Dribble, Carbonmade, deviantART, Creative Hotlist, AIGA, Behance Network, Coroflot, etc.

Question and answer sites may not be as relevant for creative professionals, so repurposing this tool for this discipline would require significant customization on the candidate profile UI. But the underlying platform would be the same.

Although professions with definitive online outputs are easiest to source with this tool, others could be aided as well. For professors and researchers, this tool could fetch their research papers. For lawyers, this tool could fetch their previous court cases. I’m not sure what could be fetched for a truck driver, but with more and more information being recorded on the web, such a platform could become a very powerful recruiting tool.

Photo by: wisdomandwonder.com

Five More Great Interview Questions

Want more great interview questions?

  1. What is an area in which you excel? Assume I know nothing about it and explain it to me.

    This tests the candidate’s ability to explain a potentially complex topic. For many people, it is difficult to “un-know” something in which they excel. The ability to break a topic down and explain its most essential components tells you a lot about a candidate’s effectiveness as a communicator.

  2. In what kind of work environment are you most effective?

    Everyone has a particular working style. If the candidate’s working preferences match your organization’s environment fairly well, there may be a good fit. If not, there may be, at best, a rough ramp-up time. Or, at worst, barriers to this candidate’s success in your organization.

  3. What are you deeply passionate about? It does not have to be work-related.

    This question seeks to understand the candidate’s core motivations in life. If those motivations run parallel (or close to parallel) to your organization’s goals, there is a good chance this person will put his/her heart & soul into the work. For startups, this is very important.

  4. What was the last product or technology that got you really excited? Why?

    Somewhat similar to understanding the candidate’s motivations is to have the candidate explain a concrete entity (product or technology) and the reasons for his/her excitement. Where the previous question examines global motivations, this question focuses on a specific motivation. Plus, it gives you another motivation datapoint and tells you how up-to-date the candidate is on current news.

  5. I want to solve problem X. What would you propose?

    Be creative with the problem statement. It can be something entirely made up, or something your organization or industry is actually facing. The solution(s) the candidate proposes are a test of his/her on-the-spot creativity and thinking, though the real value here is the follow-up questions. Probe into the candidate’s solution. Question it. Ask how it would be designed, built, marketed, measured, etc. Offer constraints that could change his/her solution. This is a good way to see how the candidate solves product problems.

These questions can work for most roles. Or you can tweak them a bit to fit your particular needs.

Comic from: Dilbert

Dealing with Bad Coworkers in a Startup

It’s important to get the right people into a startup. The size alone requires it. One bad apple means a huge percentage of your barrel is spoiled.

But what do you do if it’s not your startup? If you don’t have firing authority? What do you do if a colleague is a bad apple?

In a large corporation, you have many options.

  • Talk to the colleague and see if there are ways to make him more effective.
  • Talk to his manager to express your concerns.
  • Talk to the company founder(s) about the colleague.
  • Transfer to a different team.
  • Leave the company.
  • Do nothing.

In a startup, transferring someplace else isn’t an option. Sometimes, neither is leaving, especially if you care deeply about the company’s mission. Caring deeply means doing nothing is not acceptable either.

There are no clear-cut rules for the first three options. They would be more clear-cut if you were at a large corporation, but startups are different. Your course of action depends on the culture of the startup and your relationship with the various parties.

Talking to the colleague directly is usually the best option. The individual may not realize how his behavior is effecting others. He may be a great employee, but not have the right tools or information to do his job well. It’s entirely possible that this bad apple can be mended.

I’m generally not an advocate for going to someone else’s manager before speaking to that person first. It’s a bit disrespectful. But if you’ve already spoken to the colleague, involving his manager is a viable next step.

Going to the founders is a last-straw option. Typically, founders are busy people and may not be able to react effectively, though that depends on their personalities and priorities.

And as a founder, I would want to know about a trouble employee. However, it would need to be something particularly egregious. If your complaint turned out to be unfounded or just a personal grudge, I would label you a complainer. Also, you were hired because you’re a self-starter, and I would wonder why you can’t handle this problem yourself.

With that said, there’s really no room for bad apples. If all other avenues have been tried, sometimes the best way to handle bad apples is to toss them out of the barrel. That would be a call for your colleague’s manager or the founders. If it’s clear that the colleague is that kind of apple, hopefully they will do the right thing for the startup.

Looking Forward to Mondays

I used to tell my team, “If you go to sleep on Sunday, dreading to wake up Monday for work, something is wrong here. As your manager, it’s my job to help either discover what is wrong, or to fix it.”

Sure, everyone loves weekends and has some measure of trepidation upon returning to work. But in the dot-com world, it’s not unusually to find many people loving their jobs. I personally loved my work so much that I looked forward to Mondays, if you can believe that. I’m also a workaholic, so take that as you may.

I’ve hired many workaholics too, I think. Or, at least, people who considered working on technology as a personal interest. If they weren’t in this field, they’d probably be tinkering with this stuff in their free time.

And therein lies the kernel of my Monday statement. This is a field with many employment – or self-employment – possibilities. If you don’t like what you’re doing, you can change it. You can talk to your manager, find another job, or start your own company. Good managers realize this and, if you’re an asset to the team, they will do whatever they can to keep you engaged and looking forward to Mondays.