Tag Archives: Questing

A Better Interview

As interviewing is the first impression a company has of a candidate and the first impression a candidate has of the company, it is important to get right. My goal with this article is to start an open discussion about interviewing and how we can improve it. As a community we need feedback, debate and understanding to create something better. The place I work currently has the best interview process I have ever seen in my 17 plus years in this field. By examining what they do and why, the discussion can open with a solid foundation. We can build upon this to achieve something greater.

Where do we Start

The Hunter Software Development Group is built off of three core rules, and those rules permeate everything we do, including the interview process:

  1. Show everyone kindness.
  2. Show everyone consideration.
  3. Show everyone respect.

These are our foundations upon which we build everything. We believe every facet of an interview process should be executed with these in mind.

Our Objectives

When you consider kindness, consideration and respect as the foundation for an interview, your goals change shape. Yes, you need to know if the candidate is right for the job, but how you determine that changes subtly as your focus changes.

There are three conditions for an interview being considered successful:

  1. The candidate leaves feeling fairly assessed.
  2. We know if the candidate will be a good fit for the team and company.
  3. The candidate knows if the team and company is a good fit for them.

Achieving those Objectives

Each objective is achieved through very intentional means. We examine our process after every interview. We look for any place where the process can be polished, or someone can be better trained. We focus on each objective to better our process and make the interview successful for both the candidate and the company.

The candidate leaves feeling fairly assessed.

It is difficult to judge the capabilities of an individual within a small time frame. It is harder to do that in a way that feels fair and just. We try our best to accomplish this goal by tackling the idea from a number of sides. In order to talk about how a candidate is assessed, it is important to know what they are assessed for.

The traits that we are trying to assess are:

  1. How much emotional intelligence has the candidate acquired so far?
  2. What unique technical background and skills does the candidate bring?
  3. What part of programming does the candidate shine in?
  4. How much does the candidate know about Extreme Programming?

The first thing that happens is the candidate is given an explanation of the interview process. They are told what will happen, what they are evaluated on and why. It is important to eliminate surprise wherever possible. We believe this level of transparency is essential to the accomplishing our three goals.

Once the interview has been explained, there are a number of programming problems that the candidate is asked to work through. Each problem is straightforward with no obscure programming knowledge required. There are no riddles or surprises. Each exercise allows candidates to demonstrate a host of different skills as they work toward different solutions.

As they work through the problems, they have the opportunity to be given help and advice by three to four programmers that have been designated as their team. The team will not give solutions, instead they will help with programming language knowledge and design advice. The team will also rotate into the interview, giving the candidate a chance to navigate, teach, and guide various people with different skill sets.

There is a proctor, a person who takes lead on the interview. The proctor works as a guide for the candidate, helping keep them on target, and moving smoothly through each problem. It is the proctor’s responsibility to ensure the candidate understands what is happening throughout the interview.

Lastly, the candidate is not expected to solve the problems. In most cases it is not possible to finish in the allotted time. The purpose of the exercises is not the solution, but the path taken. We are not focused on what the candidate does not know, but rather the unique experiences and strengths the candidate brings forward.

We know if the candidate will be a good fit for the team.

There is a lot to consider and understand when talking about team fit. The Hunter Software Development Group works very differently than any place I have ever worked. We use a practice called “Mob Programming” to do all of our daily tasks. This means that all production code is written in a highly collaborative environment.

The factors that are key for our work environment are:

  1. Can the candidate communicate collaboratively?
  2. How does the candidate research new information?
  3. Do they demonstrate kindness, consideration, and respect?

Being part of a collaborative team is essential for anyone working in a Mob Programming format. Candidates will be asked explain how to solve problems and sometimes navigate a member of their team through the process of solving a problem. This means that one of their team sits at the keyboard and the candidate is asked to tell the teammate what to do. The disconnect from the keyboard forces some form of communication between the team and the candidate. Each of the team members is at a different skill level for different sets of skills. Inevitably, the candidates will either guide someone that is currently more skilled than they are or a teammate who is less skilled than they are. The way the candidate handles these two situations provides invaluable insight into that person’s communication style. It is important that the candidate shows kindness, consideration and respect during the whole process.

The processes of our everyday work environment puts highly collaborative teams into situations where they are acquiring new knowledge, usually as a result of having no foundational knowledge. The problems that the candidates are presented with are straightforward as for as core knowledge but ask questions that the candidate may not be familiar with. We look forward to web searches, text messages and anything else the candidate can use.

The candidate knows if the team/company is a good fit for them.

Letting someone know who you are is complicated process that can easily take the entire time of the interview. So how do you let someone know who you are within a couple of hours and still accomplish the other goals of the interview? This is one of the hardest questions we try to answer during our interview. We start by holding the interview in our open work environment. The candidate can just look around and see how other teams are working. They can hear the discussions, and see the excitement. A few feet away a team is working to solve problems and tackling goals.

Our interview process is part of our work. It is collaborative and social, designed to mimic the best parts of our work while still being an interview. Teammates take turns typing, helping, and guiding during the process, all of this helps give a feeling of what to expect.

If the candidate seems to be a good fit skill-wise, we then continue to a Lean Coffee session that lasts 45 minutes to an hour. This changes how the Q&A process for interviews goes as it starts by putting all questions and topics up front for all to see. Even if all topics are not discussed, the candidate and the team can see what was on each other’s mind.

A Lean Coffee format gives the candidate the chance in participating in the selection of questions and topics. Each person participating in the interview has three dots to vote on topics. These topics are then organized by number of votes. The topics with the most interest are then discussed first.

This gives the candidate a lot of agency in guiding the discussion. Their voice gets heard and they get a chance to have their questions addressed. It also allows them to focus on topics from the interviewer that they feel will make them sound better.

Each topic is given a five-minute window to be discussed. When the time is over, everyone votes on continuing or moving on. If even one person wishes to continue then the topic is continued, but only for two minutes. Then the voting cycle continues until everyone is done with the topic.

Each topic discussed is a topic not a question. Everyone is encouraged to reflect on the topic and address what it means for them. For instance, if the topic given by one of the interviewers is, “Describe a moment when you felt you really shined,” all members of the interview are encouraged to answer, not just the candidate.

This also means that topics brought up by the candidate will not only be addressed by the interviewers, but also by the candidate.

These discussions are the best way that we have found to truthfully let the candidate know who we are, what we do and why we do it.

In Summary

The Hunter Software Development Group has a very different approach to interviewing born out of a different perspective. We start with a foundation of kindness, consideration and respect and build from there.

We work to fairly assess the candidate based off of four types of skills. Emotional intelligence, unique experiences, what makes the candidate shine and what they know about Extreme Programming.

These methods have been very successful for us when hiring. We retrospect and adapt after every interview, so we are always improving. However, I would like to be part of a larger conversation. By discussing this with other professionals the community as a whole can gain insight from each other’s experiences that might not be seen any other way. Maybe the whole of the industry can improve and find yet to be discovered better ways. Mob Programming has led to better code quality. If we all huddle up and analyze how we interview who knows what will happen?

Why I believe in #NoEstimates

Before I start, as I will be talking about different work experiences, I need to state all my opinions are my own. They do not represent the opinions of my current or past employers.

That being said now let me begin.

What:

When I was first introduced to the concept of #NoEstimates I was a mid-level developer and thought that it was a wacky idea that could never work. Later, still a mid-level developer, I decided that working with estimates was stupid. Then I grew up and learned that the world was not black and white. I listened to what @WoodyZuill had to say and tried to understand the meaning.

Experimentation:

My first experiences with trying #NoEstimates had nothing to do with Woody. I worked in a small company that hired me to take over a legacy VB.Net v1 project which had failed so badly they fired the whole team. They had no source control despite having 13 versions of the application deployed, and only one copy of official source code that didn’t match any of the deployed versions. I hired a new team, we focused on bug fixes that were discreet, understandable and easily repeatable.

We gave no promises and made #NoEstimates. We focused on discovering value, by giving users fixes to things that were easily understandable. Within 3 months not only did we have source control, but we managed to reduce the number of variant applications and we were deploying every week. We had moved beyond bug fixes.

We were so successful, that the company sold in under 2 years. The CEO was able to retire, based on the value we delivered. We did this entirely without estimates.

Tutelage:

Later, I got to experience #NoEstimates in a completely different way. The team I was part of worked on custom line of business applications. We often produced software for different departments within the company. Here we focused on changing discussions that were given to us. We always asked: what is one thing that if we gave it to you now would make your life better? Then we tried to understand that enough to figure out something that is discrete, understandable and has a clear definition.

Once we did that, we would work to deliver it. Once it was delivered, we would follow up with the users to see that it met their need. If it didn’t we changed it. When the need was met correctly, we were told what the next need was.

That is how we worked. The company never had worry about interrupting us, because our deliverables ended up taking less than a couple of days on average. This was not a precondition, or intentional. It happened because of how we isolated something to work on. Occasionally it would take significantly longer. That was ok also because it meant that there were more unknowns in that piece.

 

So What:

#NoEstimates as I have witnessed it accomplishes two things. The first is it moves authority to make business decisions to the current point in time. By delaying the act of what has priority, to the last responsible minute the business is better able to cope with business as it is.

The second benefit is that it places business decisions in the hands of those who have the knowledge to make the decision. I always say that programmers are business people who have not been correctly trained in business. I say that because every line of code is a decision about how the company does business. By focusing on discrete deliverable chunks and using those chunks to measure value/need, a lot more of the decision of what goes into the application goes to those who are responsible for the business.

 

Now What:

#NoEstimates is the beginning, not the answer. There is a lot more exploration that can happen out there. Let’s focus on improving how we do business, and share our successes and failures. Eventually we will always find better.

Reinventing the User Group

User groups are awesome for technology. They accomplish several key goals. First, they give developers a place to learn the standards around their technology. They also give a forum for thought leaders to explain changes and improvements to the technology to those who care. User groups also provide an organized place to network with those within our same field. This is why they are so awesome.

User groups are an old institution, compared to anything else in the field. One of our local user groups has been around for 20 years. The idea of user groups has been around longer than that. Therefore, it is not surprising to see that the idea is being iterated on.

If you have not been to a user group, seriously- go. Let me explain the basic format. The members of the group gather to hear a speaker talk about some topic. The speaker gives a presentation and answers a few questions. Sometimes the group meets for an informal meal or drinks afterward.

I attend two user groups that completely break from this format. This break is not simply to be different, but because they have a different set of goals and they have found a format that enables those goals better.

The first group is the Technology Immersion Group (TIG). TIG’s goals are to give a forum for developers to take a topic and dive deeply into that topic. TIG is structured more like a large study group. There is a panel that functions as subject matter experts, and usually some study material used to guide the group. The panel spends a short amount of time introducing what was supposed to be covered in off-hours and most of the time is given to Q&A. If there is not much Q&A then the panel will explain points of what is coming next.

The second group is the San Diego Architecture Special Interest Group. This group’s purpose is to give a forum for senior developers and architects to discuss things they are encountering at work and get advice. This group’s format is a round table with three rounds. The first round is a problem round. Anyone in the group can ask the group for advice on things they are dealing with at work. The second round is a round table discussion about some specific technology. Sometimes they do a book discussion, sometimes a more open discussion. The last round is a show and tell round. You need to share something that you find interesting. This could be a tool, a programming language, a kick starter or anything. The last round facilitates discovery of things to either help us with what we do, or helps us unwind.

These two groups arose out of a need that was not being fulfilled by current user groups. That does not mean that current user groups are out-of-date, but only that there is space for new user groups to arise, particularly ones that fulfill the specific needs of their users. I hope to see more specialty groups that change the format in different ways. I also hope to see these two groups replicated in different towns. All of this grows our community and improves the industry.

You are a Star

I believe I suffered from Imposter Syndrome for most of my career, and if there is one thing I can say I have definitely learned is that you are the star. No matter your experience level, language, or technology bent; the fact that you are out there producing code makes you a star.

If you are not producing code: do so. I can promise you one sure thing: No code you write will ever be as bad as some of the code I have personally put into production. I wrote some things when I was a junior programmer that would make the faint of heart faint. Trust me, I had to run a production application in debug because a variable would lose its value. To keep the program working I would have to edit the memory location and then hit continue.

But that is the beauty of code. It is so valuable that even the worst written application, if it meets its basic need, will be profitable. The application above was so successful that the company’s competitors would hire us to do the work under their name.

Code is value. As long as you are producing code you are producing value.

Now I am in no way saying to stop learning, or searching for a better way. However, I am saying that you should go and produce. Build something, either for yourself or someone else. When you are done, build something else.

Searching for perfection will not help you discover that you belong. It will, in fact, do the opposite. Only by cutting your teeth on code will you begin to see the value you bring to the community.