Agile / XP hiring pair programming

Better Hires Put Out Bigger Fires – How to Build Great Engineering Teams engineers get the opportunity to work on some really cool projects. From web apps and mobile apps using the latest and greatest frameworks, to entire smart data platforms and containerized infrastructure. When you’re working with such cutting edge technology, sometimes even the documentation hasn’t yet caught up to its full feature set. This is how we like it. This keeps us on our toes and always working towards the next big thing, we’re always ready for the next step. This forces us to dive deeper into the technology ourselves, ultimately resulting in a very advanced granular, but broad skill set.

However it takes a certain type of person to work in this area of emerging technology. The question I get often as one of the leaders of — how do we build such effective teams on a project by project basis?

When beginning the new journey of working with a client, it’s imperative that we identify two things: is this a consulting project or is this a staff augmentation project?

A consulting project typically involves a scenario where the client doesn’t know what they don’t know. It’s paramount that the leads on this team, typically the Technical Project Manager (TPM) and Engineering Anchor (Tech Lead), are both extremely capable and adaptable to changing context, pivoting, and identifying empathy for the business and stakeholders. Early on within the project journey we’re making sure that these two roles are in more or less constant communication with stakeholders as they complete their discovery and framing process. Engineers have more flexibility in consulting projects, but that also introduces new risk.

Staff augmentation usually isn’t as complex as consulting projects because there are already established processes, existing infrastructure, and the projects themselves are typically brownfield scenarios. But that doesn’t mean that they don’t need similar attributes that we reserve for TPM’s and Engineering Anchors in consulting projects.

Now to the meat and potatoes — how do we choose who to hire and staff our projects? Currently, since employs about 30 full-time engineers and growing at a steady rate, leadership hasn’t had to micromanage or delegate hiring to third parties or dedicated internal teams. This means that our small cohesive leadership team ultimately has to sign off on who is hired. Our leadership team effectively plays the buck stops here part in the hiring process. This affords us the ability to apply our experience based non-quantifiable templates and expectations to all incoming candidates. This model must scale for enterprise situations, but not by much, at least in my experience. As a leader, taking 30-45 minutes out of your time to chat with a potential new onboard is always worth its weight in gold. In fact, I’d argue that this is one of the single most important things you as a leader can do in an organization of any size. What is more important than taking the time to vet candidates that you expect to effectively evangelize your company? In services, where relationships are so important, this is critical.

Like any tech company, resumes and skill sets are the starting point. When we create a job description (JD), we have two methods:

  • Skill set based job description (JD) for specific project
  • Broad JD, we’ll talk more about this in a future posting

Skill set JD’s we rely heavily on experience initially. This means, to make any initial forward progress whatsoever the candidate will have to meet or exceed the minimum number of years of experience in certain technology, but they do not have to map 1-to-1.

For example, suppose my client is requesting candidates with the following skill set, and they expect each candidate to have 2+ years in each category.

  • Java
  • Spring Framework
  • ElasticSearch
  • Apache Kafka
  • Google Functions
  • Google Cloud Platform

Sometimes you get lucky. Sometimes a candidate will fall into your lap that lines up perfectly. We call these unicorns. Unicorns are rare, and because of that scarcity they are naturally pretty expensive. I could go on about this, but suffice it to say that unicorns are very very rare so it doesn’t behoove us to go into much detail here.

More than likely your sourced candidates will line up with maybe 20-25% of what you express in your JD. That’s OK, that’s what we expect. This lines up with the typical ask for the whole loaf of bread, but expect half, the only difference is we expect much less than half the loaf, in fact on average we get 80% less than the whole loaf.

So our skill set based JD has in turn produced hundreds of potential candidates, and they all line up with 20-25% of the requested skill set in the JD. How do we now go about vetting these candidates?

To vet the remaining portion of candidates we have to identify our make or break skills within the remaining 20-25%. What in that remaining bucket do we absolutely expect the candidate to have experience with? In the hypothetical JD skill set requirements above, we would rely heavily on the Java and Spring Framework experience. To identify this you’ll need to be somewhat engineering focused or you can discuss this with leaders in your existing engineering teams. Just pose to them the question:

What’s more important to you? To have a team member that is extremely well versed in Java and Spring Framework, or a team member who shows excellent Cloud Native and ISV use experience?

Invariably they’ll respond that the programming language itself and the framework you’re building applications with is the most important quality. Existing members of the engineering team the candidate is potentially joining have no problem teaching service features of something like ElasticSearch or Kafka, but they don’t necessarily want to teach core programming fundamentals. And they shouldn’t, they’re engineers, not comp sci professors.

That in turn means that any candidate that doesn’t have at least 2+ years of Java and Spring Framework are out. That doesn’t mean they’re out of, that just means they’re not a right fit for a skill set based project, but we’ll get to more of that later in our broad based JD blog post.

So at this point the candidate we’re looking at now has the make or break experience within the remaining skill set to move forward. Next we look at past projects and technical stacks within their resume. After reviewing their resume, we note that the candidate hasn’t directly had any experience with Kafka, but they do have experience working with Apache Hadoop in the past, and they also have message bus experience working with ActiveMQ and RabbitMQ. As an engineering manager I can immediately identify that they have ingredients in their resume and past experience that when stewed together essentially create Kafka; for example, Hadoop experience means that the candidate is no stranger to distributed data environments and processing techniques, but they’re also no stranger to how and why we would use a message bus because of their work with ActiveMQ. As an engineering manager, I know that at a very high level, that’s essentially what Kafka is, a combination of a message bus (or log) within a distributed environment.

That gives me, the engineering manager, a good predictor that even if the candidate doesn’t have direct working experience with Kafka, I know that because of their past experience working in adjacently related software and services that the capacity is there to learn Kafka at a rather deep level with some reserved ramp-up time.

As I’m reviewing their resume I also notice that they’ve only worked within AWS (Amazon Web Services). Does this mean that I cannot put them on a Google Cloud Platform or Microsoft Azure project? Absolutely not, in fact, it means that I am more encouraged to put them on a GCP or Azure project. Our experience working within cloud environments over the years, we’ve seen first hand how great general cloud knowledge and in-depth experience in one particular cloud environment transcends to other existing cloud platforms. In our first conversation with this candidate, we’d drill down a bit more within their AWS experience and check to see if they’re knowledgeable with AWS Lambda functions, and if so, then that checks our Google Functions box but also an Azure Function box.

What about ElasticSearch? How do we vet the resume to see if there is potential to learn that service? The prior hadoop experience certainly helps, since that gives us that distributed data knowledge. But we also see that the candidate has worked quite a bit with MongoDB, and it could be argued that while not quite there the ingredients to learn it effectively are present.

The next step we take with this skill set based candidate is an initial RPI (Remote Pairing Interview). This is where we hop on a zoom and we write code together, exactly as we write code on real projects with real clients. It’s important to note that this isn’t a coding test or a white board type interview. This is a representation of how we work everyday, and we want to expose the candidate to that working structure immediately. At we pair program, which means that we’re always working with another engineer. Some people like this, and some people don’t. Our worst case scenario is that we make a hire and add a team member, only to find out 3 weeks into the project that the team member has decided that they don’t like pair programming. Pairing is a core value of that we employ with every project we work on, whether it’s application development, devops, mlops, etc. In a typical project setting, engineers pair program with client engineers to continuously transfer best practices through creating software together.

We expose the candidate to pairing by doing it with them at the very beginning, and we let the candidate decide if it’s something they’re attracted to or not.

I have engineering friends and colleagues that are some of the best software developers in the world, but they do their best work at 1 AM in their loft, music blasting in their headphones, totally in the zone. And that’s great, they’re excellent at what they do, and some of them are literally moving certain industries in directions we’d never even anticipated. But I’d never hire them to be part of Why? In our industry you must be able to work together, not only in a team, but also on a day-by-day pairing basis with different engineers every day.

After the initial RPI we’re able to truly vet if the make or break skills are present. If their resume is talking the talk then during the initial RPI we make them walk the walk, but we do it together, it doesn’t fall solely on the candidate alone. Since we’re driving the session and the candidate is navigating, we’re working together. If we hit a speed bump and run into something that the candidate doesn’t necessarily know that well, we hop on Google and Stack Overflow to research it together. Now we’re beginning to see how the candidate goes about mitigating blockers, how they express empathy, and we can begin to measure the capacity they have for growth. The world of technology is so huge that it would be ridiculous to expect every candidate to know everything all the time, so we do what we do in real life situations, we research the hell out of the blocker and attack it together.

The RPI gives us a wealth of information about the candidate in a real time basis. Does the candidate really know what they say, and if they don’t, how to they process that with another engineer? How good are they at researching and debugging their issue? How do they react to criticism and feedback? How quickly can they mitigate blockers? And to what length will they go to before requesting internal or external help?

After the RPI, assuming everything went well, then we move on to our soft skills interview process. The soft skills validation check is either held utilizing small 15 to 30 minute meetings individually with each member of our leadership team, or the group as a whole. The best results we’ve seen from this are through small, individual leadership meetings with the candidate.

Personality if everything. I don’t care the size of your organization — startup, mid, enterprise, it doesn’t matter to me — never put skills above personality. In other words, avoid hiring assholes. Typically a gut-check will suffice. This can often be called the non-quantifiable part of the hiring process. It’s not easy, especially with tight deadlines and obvious openings. But setting yourself up for long term success, especially with smaller teams, avoid introducing candidates with undesirable personality traits to your team and organization.

With every person we bring onto our team, internally throughout the entire process, our leadership team knows to consistently ask themselves the question, “Could I work side by side with this person for 8 hours a day?”, and if the answer is no, then it’s a full stop to the hiring process. This transcends all roles and positions at, whether it’s engineering, TPM, or operational candidates. If throughout the entire process, for any reason any of our leadership team even has to ask themselves the question more than once, then it’s a red flag and deserves deeper attention.

Why are soft skills and personality such an important piece to our hiring process? The answer to that is simple: Our team members and clients deserve it. Not only are we creating production software everyday, but we’re doing it side-by-side with client engineers. So the tech portion has to be there, the capacity to learn has to be there, but the emphasis on customer service is above all.

Our leadership team consists of folks that have years of boots on the ground experience working as software engineers, architects, project managers, and more. We know what it’s like when an existing team brings on a new engineer with an arrogant attitude, or who silos information, or has terrible relationship building and soft skills. Far and away the number one most important quality a candidate can bring to the table — a present and pleasant hungry optimism tinged in curiosity and enthusiasm. Many might ask, is it even possible to find people like this? Obviously the answer is yes, they make up our entire engineering and TPM team at But it doesn’t happen overnight.

Finding and hiring great software engineers is an art, not a science. interviews well over a thousand engineers every year, but we hire maybe two or three engineers a month. In order to find great engineers you’re going to have to put the time in and your going to have to stay strict to your process.


Cahlen Humphreys