How to Interview Software Developers based on Changing Technical Debt
Interviewing a Software Developer isn’t easy. Interviewing a Software Developer is a high stakes gamble where the choices made are often ill-informed and the result of a choice has enormous consequences, both good and bad. The entire interviewing process has been flawed since the very first “Programmer” job was posted, many moons ago. If you have the time and patience to read this long-winded article, I believe I can help you make a more informed decision using my own experiences interviewing, hiring, working as a consultant and full-time employee, and my own opinion about the most honest and robust hiring strategy I believe in.
When it comes to hiring, there’s a lot at stake for the interviewer and candidate alike, so let’s begin by discussing the interview from the vantage point of the manager.
Understanding the hiring manager’s aspirations
Managers often hope their new candidate is going to be the “one” who charts a new course for their product, their company, and ultimately, paves the way toward golden opportunities for everyone on the team. Managers have visions of hiring someone so special, they can work normal hours, get a better bonus, and lengthen their lifespan through the type of stress reduction they were advised to undertake by their Cardiologist.
After a candidate is found, interviews happen. An offer is made. Anxiety fills stomachs. Email clients see their ‘receive all’ button pressed over and over. Papers are signed. Videos about “why groping is inappropriate” are watched. Then, months after an understanding is reached about what the candidate would bring to the organization, both parties are often disappointed by the differences in expectations for the position and the reality of the position.
The interview is where all of the false expectations are born. Having worked as a full-time employee, consultant and founder of two start-ups, I’ve had my fair share of interviews on both sides of the table. I have hired freelancers, contractors, consultants, and full-time employees. I have gotten lucky, and have been seriously blown away by some of the people who worked for me, whom I never would have imagined would be capable of carrying the baton across the finish line; and yet, succeeded beyond my wildest expectations. Other times, I’ve kicked myself for a costly hiring decision that drained so much time and energy, I would have been better off doing the work myself.
I used to suggest we hire a candidate based on their intimate knowledge of subject matter. When I hired, I often prided myself on my ability to ignore personality, as if my tolerance of the more eccentric candidates provided me a bigger talent pool from which to choose; a tolernace I believed provided me an edge over our competitors. Everyone who hires usually tells himself or herself that they have some edge over other interviewers. They tell themselves they provide a much more thorough interview than their peers. They tell themselves they can judge a candidate’s fitness better than anyone else. They tell themselves their cowboy shirt they picked up at the thrift store looks nice. Remember this about interviews: Interviews happen off-the-cuff because interviewers have no systematic process or methodology to successfully measure a candidate’s real value.
I am, perhaps, the worst interviewer of all time
I have worked for multiple Fortune 50 companies and never once did I have any guidance when it came to interviewing candidates. As a result, I was, perhaps, the worst interviewer mankind has ever known. If you, as a candidate, dazzled me with an impressive resume that attached brand-name companies, whose hiring team had already vetted you as a candidate, you had my attention in the interview. If you, as a candidate, had networked your way to some of my best friends and acquaintances on LinkedIn, I went into the interview with a certain level of confidence we may have cubes together in the near future. If you, as a candidate, had memorized an API, I would probably recommend you to my superiors.
People make the mistake of hiring based on personality
Let’s talk about the bad math your Human Resources team uses when talking about the need to increase “human capital”. Math that involves some tricky numbers. It would be easy to argue the differences in product quality and team productivity have a common root cause: individual personality quirks. Lots of HR personell who had a euphoric moment in “Psychology Class 401” believe a great product is the result of charismatic and intelligent people helping to improve morale, communication and transparency. The people directing the organization hiring efforts through job postings, career fairs, and college campus recruting often look for individual personality traits and consider those traits to be crucial in forming the right team. The goal is to hire people who stay at the company long enough to call it a ‘career’, and they hope to hire people who seem pleasant and politically correct.
A few fallacies at play here:
- If multiple teams each have highly skilled employees, and a similar product, but one team has longer delivery dates and a less stable product, then individual personality must be the lowest common denominator affecting the equation.
- The best hires are the are the ones who are likely to know a product intimately by staying at the company for a long time (also known as “Career Men”, to use an antiquated, politically incorrect, gender-specific term).
- You can apply a universal theory about improving productivity in the workplace to hiring people for all career-types.
I’ve worked with some great teams where people got along well, they worked long hours together, they had charisma, a sufficient background in software development, and yet, they still delivered the kind of software you wouldn’t want your family dog to see on the neighbor’s computer, for fear the dog would be scarred for life.
With all skill-sets being equal, even if people get along, even if there’s transparency and open communication, it doesn’t mean a product is going to work. Hiring using personality and character as a way to determine ‘value’ is a bad way to evaluate an individual’s ability to help you write great software.
The Eclat Principle. Continuous Candidate Modeling based on Changing Technical Debt
I believe the key to building a superior product is complex, and I’m going to illustrate the interviewing flaw and propose a solution based on one simple principle I like to call the Eclat Principle.
The Eclat Principle is a concept in management theory in which the selection of a candidate, with all candidates’ skills being equal, should be based on the candidate’s ability to counter-balance the shortcoming of an employee or the collective shortfalls of a team, using transparent indicators in a product to define the desirable traits of each subsequent employee.
I applied your theory and now we have a very weird developer sitting in my office
Obviously, if you apply the Eclat Principle to your hiring without further consideration, you can end up with some interesting people on your team. I firmly believe you can base your hiring decisions on technical debt and reposition your new teammates accordingly based on their ability to work with others, their inability to communicate, their uncanning ability to offend, and other quirks that might leave you with a team resembling the Island of Misfit Toys.
Accommodating a personality mismatch
If you end up hiring someone who is a “misfit”, you have more options than you think.
- If you hired a good developer with anti-social behaviors, skip the employee evaluations that try to mold human behavior, and give them a private office where they won’t be as likely to offend others. Move them into a cube in the “future occupancy area of the office”, where they’re less likely to feel isolated and more likely to be feel free. Let them work from home on a regular basis.
- If you hired someone who feels obligated to send antagonizing emails, you should ask yourself why your company uses email as a means of communication. Maybe it’s time to consider changing to a short messaging service. Perhaps you need a system where you can moderate one person’s messages.
- If the person you hired seem abrasive or disconnected in the Scrums, consider moving your Scrums online where they can be more easily moderated. If you hired someone who speaks little English, a chance to replay a recorded scrum or get a private text about the question of a story or task provides an opportuntity to translate a question with greater ease.
Don’t let Human Resources drive the expectations of what is “normal”. If you are willing to spend a small amount of time and money relative to a developer’s salary on accommodation for the right employee, you might be able to advance a project more quickly than you would with a team of similar, like-minded developers.
If you think it seems wrong to change processes based on individual personalities, you’re missing out. Continuous Candidate Modeling based on constantly Changing Technical Debt is how great products are developed, and an ability to adapt to changing personalities and skill-sets is crucial to moving a product forward.
It’s good to outgrow one another
As a manager, you should consider an ideal scenario: If you hire people who help move your product forward, you should outgrow lots of people on your team, and as you do, those individuals will move on to better suited positions, or you will have the means to sever the relationship with a severance package and LinkedIn recommendation that shows your company values individual contributions, but the time has come to part ways.
It’s okay to hire with the long-term expectation you and the candidate may eventually outgrow one another, provided you’re open about the hope, expectation and upshot for all parties involved if that scenario comes to fruitition.
Candidate qualities sought in the standard interviewing model
To understand how the interview process works, let’s skip over the recruiting process and begin during the start of the interviewing process. For many job candidates, the interviewing process often seems mysterious and confusing, mostly because the people doing the hiring are badly confused by this mysterious process. Let’s say you’re applying to a big company. This mysterious hiring process usually starts with an email from a Senior Manager, who says, “HR got this resume from a recruiter. Let me know if your [SIC] interested.” The person who now has to interview you may or may not have known there was a job opening. Accordingly, the interviewer may or may not have any interest in conducting an interview.
The interviewer writes HR back and says, “Sure. Schedule it.”
HR enters the candidate into the requisition system, and then tries to set-up a time to screen the candidate. The candidate might go through a technical interview on the phone, or a short technical phone screen and another technical interview in-person.
If the candidate passes the phone screen, they are then invited to the office for an in-person interview. The candidate buys a new shirt to replace the one with mustard stains, buys a razor, trims their nose-hair, and orders a new pair of shiny shoes. The day of the interview, 15 company employees receive an email asking everyone to skip lunch at the deli to interview the candidate. 1 person shows up. He has a mustard stain on his shirt.
The interviewers ask questions they either searched for online during the actual interview, or ask questions based on problems encountered recently during development, with the goal of establishing a baseline for the candidate’s competency.
An interviewer may choose a candidate who is the smartest person they interviewed. They may hire a candidate whom they feel won’t outshine them at the office. They may hire someone who reminds them of someone they used to know. If the candidate answers all, some, or none of the questions correctly, they may or may not get offered a job. Why? Because most companies have a universally accepted standard for deciding whether or not to move forward with an offer: choose someone you like.
Human Resources doesn’t send an interview format to those doing the hiring. I have never had a manager ask if I went through a systematic approach to vetting a candidate in an interview before suggesting we make an offer. The hiring approach can be best described as loosey-goosey, and at worst, organized chaos.
Our first test of a candidate was always technical competency. When I helped interview, we received so many resumes, I was convinced many of them were fake, and that’s mostly because, many of the resumes were fake. Recruiters would edit resumes for the candidates, recruiters would ask a candidate to rebuild a resume based on a job description, or they would ask a candidate to copy an existing resume for someone who did get an interview offer. I have had endless recruiters ask me to be someone I’m not just to get to the face-to-face.
When I did hiring, our first line of defense was to ask questions to see if the candidate we were interviewing was the same one whose resume we had in front of us on the table, and not a candidate who had copied a better resume from Indeed.
I believed asking questions to measure technical competency was a black and white means of selecting a good developer. You either answered the question correctly because you knew the material or you didn’t know the material. Sometimes, I would ask candidates a question about a line item on their resume to see if they added a position, project, language or framework just to get into the interview. Then, I became a victim of the same approach I used to weed out unqualified candidates for a position I was well qualified to fill.
Case Study. Out of sight, out of mind
One day, I was interviewing with a company. Most of the interview went well, and then the company asked me a technical question about authentication. They saw a short blurb on my resume about and decided the topic would be a good talking point, since they were in the midst of rebuilding their authentication system. They said, “Let’s talk about this authentication service you built.”
That’s when everything went downhill.
I had written the authentication code many years ago. I was the only developer on that project, and the only thing I could remember was a recollection of how proud I was of the system I built at the time I added the blurb to my resume. This authentication system took me a considerable amount of time to develop, but I couldn’t remember much about it. Maybe if I could have read what I wrote on my resume, but I don’t sit around the house reading my resume as a refresher.
I hesitated answering the interviewer’s question because I couldn’t remember anything about code I had written years ago. I gave the same kind of pause I received from many candidates I had interviewed in the past. Imagine if you will, a pause that is followed by trepidation. There’s a small quiver in the voice. The same kind of quiver one associates with a blatant, all-out lie.
I knew a good deal about authentication, then, and now. It had just been a very long time since I had done much with this home-grown authentication framework. After a project is complete, I put the individual mechanisms of how the system works out of mind, because I categorize working code as ‘complete’ and when it’s clean, and organized and tested, I put it forget the intricacies so I can remember upcoming events, like my son’s birthday and what I need to buy at the store..
I couldn’t answer the question and the interviewer seemed to think I might not be the same person on the resume.
Fallacy: The inability to answer a technical question indicates the candidate doesn’t know the subject matter.
Often, an interviewer has to interview someone who might become their next peer. If they’ve made it through the technical competency qualifications, the next concern is, “Can I sit beside this guy everyday for the next three years? Can I go to meetings with this guy? Can I write code in the same repository as this person? Would I be comfortable standing next to this person in the restroom?”
The interviewer becomes concerned about the character of the candidate, so they begin to measure the candidate’s personality by examining speech patterns, mannerisms, and language, with the hopes of determining who the person is and what they’re going to be like on a day-to-day basis. Sadly, none of these evaluations matter. People act differently in an interview than they do once they’re hired. Even if you read a recommendation from a former coworker on LinkedIn, the truth is, each person will be a different person in a different company culture.
Company cultures, and the social groups within those cultures, influence the different types of personalities you will see in the people you work with, and those groups shape the type of person you will see on your team. The person you’re interviewing may have extensive experience turning spaghetti-code projects into design pattern greatness when he was the sole developer, but in a team where everyone writes spaghetti-code, it’s probably unfair to assume this person will have much of an impact on your team. Instead, your new-hire is likely to become a spaghetti-code programmer who harbors the knowledge to fix your project, but has neither the motivation nor the position to be a savior.
The character of the person you see in the interview, or on the resume, will have little impact on your culture if your team has been conditioned to accept their own sets of norms. The person you’re trying to hire is likely to become identical in performance and practice to the rest of the team. Take for example, the Bystander Effect, where the greater the number of bystanders to a crime, the less likely it is that any one of them will help. Social conditioning, cohesiveness and diffusion of responsibility are powerful motivators.
In order to truly evaluate the character of your candidate, you need to see how your candidate works in your current setting, which is an unrealistic proposal. Asking a candidate to work for free, goes against against the ethos of most companies, and the legal restrictions imposed by various employment laws.
Fallacy: The initial perception of a person’s initial character in the interview is emblematic of their true character after they’ve been assigned a laptop.
Risk mitigation (AKA: Let’s use a third party recruiter)
To reduce the risk of hiring a candidate who is either a poor culture fit, or one who appears technically incompetent, companies often outsource their hiring to recruiters and staffing agencies.
Using a third party, companies hope to avoid the risk of legal action stemming from wrongful termination lawsuits. They also can avoid the awkwardness that comes with letting the candidate and their staff know that the time has come to part ways using the appearance of a temporary project that may or may not be limited by time and budget constraints.
Contractors have become the new 90-day employment probation for many companies.
Having worked as a contractor and a consultant, I can tell you first-hand that the person you hired as a contractor is likely very different in performance than the person you could have hired as a full-time employee, and that difference is reflected in each line of code on your project.
There are multiple flaws inherent in the notion that you can hire great talent using an outside recruiter. Most of these flaws should not be overlooked because these flaws prevent your company from building a better product by believing engagement strategies don’t contribute to a product’s quality.
Contracting stresses out your contractor
Over the years, I have worked as a consultant through my own consulting company, but my company has never worked directly for a client. Instead, my company has always worked as a sub-contractor for another company, whom the client has presumably hired.
Sometimes, I’ve worked as an employee of the company I own, which is contracted with another company, who is contracted by another company, who is then contracted by the client. It’s a mind-boggling scenario, and it’s even stranger that multiple people whom I have never met, are eating into the hourly rate I’m earning for each hour of work I’m performing.
If you own a home, picture it like this: You hire a painter to paint your house. His name is Joe. You expect Joe’s company to paint your house. Joe hires his friend Bob to paint the house. Joe doesn’t care if Bob hires someone else to do the work. Bob learns Gary, his hard-working neighbor, needs a job, so Bob hires Gary for half the rate Bob is earning from Joe. Bob shows up to paint your house. Bob doesn’t know Joe.
Each company a consultant or contractor is subcontracting to, often has a 30-day “net” turn-around for payment. That means, as a contractor, you may not get paid for 90 days from the date you bill (this is different than billing from the date you worked), and the net billing date for the 90 day window is often the last day of the month. The day you write some of the greatest code of your life, you may be 120 days from payment for the work you’ve done…and that’s only if you get paid.
Contractors get burned. A lot.
Over the years, companies started to require a United States entity to act as their 1st tier vendors. That, however, didn’t stop staffing agencies from subcontracting recruiting work to 3rd world countries. Those 2nd-tier companies set-up a shell company in the United States. The 2nd tier vendors your contractor works for will often state that the devloper, or developer’s company, won’t get paid until the 2nd tier vendor is paid by the 1st tier vendor.
I have worked with endless contractors who have their mortgage and car payment tied up with a company owned be a guy named “Chuck”, whom they only spoke to before the contract started. It was a five minute phone call. Now, a year later, the contractor hasn’t been paid for 4 months. Chuck is not willing to answer the phone or respond to emails about the hold-up, except for one short note that reads, “I have sent your email to someone in accounting. They are on vacation.”
When you work in contracting long enough, you learn the best job in the world is working as an accountant for a staffing agency. Why? Because those people take more vacations than a widowed millionaire who loves a cruiseliner.
As a business owner, stake holder or project manager, you want your team to be engaged. To be engaged, each developer has to be free from the constant nagging and distractions that prevent a dedicated focus. When your number one worry is whether your lawyer missed a line in the contract that is going to prevent your house from being taken by the bank while your wife and kids go hungry, it’s hard to think about the best way to write a Facade to help the junior developers move forward. Instead, you’re thinking about Chuck in his new Porsche and then your thoughts drift to how many cups of Ramen you can take to the shelter.
Case Study: The wrong legal contract
Years ago, I was interviewing (through my own consulting company) with a Fortune 50 company. After a few interviews, they offered me a contract. The location was desirable, and I thought I’d be a good fit based on the languages and frameworks the team was using to develop their product.
When the contract came from their staffing agency, I read it thoroughly before sending it to my attorney. This particular contract caught my eye, mostly because the grammatical errors, intermingled with the legalese, suggested the contract had been modified. Here’s what caught my eye:
- The contract required my company carry a $1,000,000 general liability insurance policy.
- The contract allowed the staffing agency to change the rate at any time.
- The contract said my company agreed to the rate, but the rate was nowhere to be found and required multiple emails to receive.
- The contract required I pay the legal fees of the company I was working for, if they were sued.
- The contract required my company pay $1,000,000 if I stopped working for their end-client.
I declined the contract. The recruiter, who lived in India, then sent me a new contract that read like a standard contract. I declined the new contract, which is when the 1st tier vendor started calling me, asking me to reconsider. While I could walk away, most contractors can’t walk away. They often sign bad contracts because they need income.
For many companies, what happens behind the scenes with your contractors affects your contractors. Those arguments, letters, letters to lawyers, documentation preparation, stress, and fatigue affect your product’s quality.
If you hired your contractor to test how they will perform as a full-time employee, you may never know how your contractor might perform as a full-time employee because there are different stressors affecting developers in various engagement models.
You, as a manager, have no control over the rate
As a contractor or a consultant, you get paid an hourly rate. The staffing agencies and consulting agencies you subcontract for, or work for directly, rarely offer rate increases (and when I say “rarely”, what I mean to say is that the SOW changes I have seen only happen when staffing agencies reduce the rate). When the market rate changes for a position, the agency will often renegotiate rates with the client, but you, as the consultant or contractor, do not share in the increased rates.
Instead, when your contractor is working a long-term contract, there’s an implied assumption that they will continue to work for the agreed-upon rate. As market rates change, your contractor is likely to stay aboard if the market rate is stable. For example, the market rates for AngularJS and HTML5 development have dropped due to the flood of developers with the required qualifications. If the contractor is writing a framework such as Flex, MUMPS, ColdFusion or Cobol, where the candidate pool is slim and the rates have jumped dramatically, your inability to influence the rate paid directly to the contractor is a huge liability for your product and team.
A proxy controls the rate paid to your contractor or consultant, and rate re-negotiations are a rare event between a contractor and agency. In short, your company may eventually lose the person with the greatest knowledge of how your product works, including the product’s shortcomings, the robust pieces, as well as business knowledge, such as how your team is organized and to whom he can delegate tasks. The best contractors and consultants jump at the end of a contract when rates are up. The best ones are always building relationships and waiting on the next opportunity that might pay more money. The less skilled contractors and consultants are far more loyal and are thankful when their contracts are renewed. Without a direct line to rate renegotiation, your product is held hostage by the least skilled contractors who are often more interested in recurring income than product advancement.
Titles and status determine who provides the best product solutions. Contractors have neither.
Note: Consultants often make wonderful team leads. This next piece is about contractors.
Usually, most companies organize their teams based on this simple rationale: the smartest guy in the room naturally ends up in charge.
It’s a pretty simple way to ensure the development team can always rely on the brightest member of the team to come up with a solution, to monitor the repo, and to ensure solutions to the most complex problems are the most elegant solutions.
When your contractor is the brightest developer on the team, there’s a reluctance for a team to go around the lead developer. The contractor is temporary. The team lead is not. As a result, the contractor is never the team lead, and it’s not in the contractor’s best interest, or that of the junior developers, to go around the lead.
When it comes to asking for coding help, ideas or suggestions, your team will always rely on the lead. If your contractor has a great idea, solution or proposal that will push your product ahead, each of the positive intentions will have to be approved by the lead.
In addition, the contractor can easily be moved from task to task. Most contractors are there to support a team, not to act as the owner to a solution. This prevents a contractor from owning a complex problem domain. And worse, it prevents a sense of domain ownership, and domain ownership is key when it comes to developing quality code. If a developer doesn’t own a solution, the developer won’t be inclined to worry about the fine nuances of programming that separate elegant solutions from rudimentary ones. The person you need to solve the most damaging technical debt may be silenced because of their social status.
The politics of working in a group and the inability to own a particular problem area of a product, prevent your contractors from fulfilling the potential they have as a full-time employee, especially one where they are given the status, title and clout of being a “Senior Developer” or “Architect” or “Lead Developer”. Titles and positions are important because they impart a sense of social hierarchy, responsibility and leadership, and you can’t bestow those titles on a contractor. When you’re a contractor, you’re just a contractor.
Fallacy: You can try out great candidates with a contractor or consultant
Most Interview Formats are Seriously Flawed
Most companies have an interview format that is off-the-cuff. Their interviews have very little organization in terms of the true needs of the position and the approach they’re going to take to interview the right person for the opening. Interviewing is a high-stakes game and the thought given to how to interview should be just as important as many of the other events, such as the level of effort involved in project planning. Sadly, most interviews are less thought-out than what one is going to have for lunch.
Crafty and clever questions won’t help you find a candidate
Some companies I worked for tried clever questions and challenges to test a candidate’s competency using what is commonly referred to as the “Google Interview”, and before Google, Microsoft had some very thoughtful approaches to interviewing which have since been mirrored by Human Resources departments throughout the galaxy.
These clever approaches to interviewing required longer interview formats.
Sadly, most companies don’t have the clout to keep someone interviewing for an extended period of time. Candidates who are actively looking for a position will usually take a job offer from a company that is “pretty decent”, instead of waiting on another opportunity to follow-through with multiple interviews and a finally, a job offer. Candidates who need a job don’t want to put all of their eggs in one basket and find themselves beholden to one suitor, because the stakes are too high.
When I performed interviews as a consultant, I remember feeling deflated when my Senior Manager told me the dream candidate I was counting on had taken a position elsewhere. If we missed an opportunity to hire someone because we were trying to be clever or we were eager to involve more people in the interviewing process, we ended up working longer, harder hours.
You need to be a dream destination in order to field crafty and clever questions (why is the manhole cover round, anyhow?). Dream-destination status is reserved for a handful of companies, and prolonging a decision is a good way to lose the candidate who might be the best choice to help tackle your greatest technical debt.
Fallacy: The right questions will help you hire unique talent
You should never hire someone you only interviewed on the phone
I used to believe you could build relationships on the phone. After a few conversations, you would develop a rapport, and the rapport would lead to a relationship strong enough to get work done. Over time, I noticed the people who were eager to build relationships without a regular physical presence preferred not to be present for several reasons, none of them good.
The less you see someone, the more questionable the ethics become
Case Study: The Freelancer interviewed on the phone
As as very young developer-turned-temporary-manager, I was tasked with finding a designer for our project. I knew a couple of people from the discussion boards where I was a moderator. These were people whom I had had some discussions in various threads, and after talking to one guy, I thought I had a great candidate. I felt I knew this person from some discussion threads and private messages.
The person I was talking to was known throughout the industry as an up and coming star who was just starting to gain national recognition. I talked to the designer on the phone about whether he could help us achieve our design goal. We talked. We talked some more. We had conference calls and private calls. We had a rapport.
With approval from my boss, I hired this designer to do the work we discussed. I paid him and right after the check was cashed, that’s when the problems started. The work I received in return was not the style or quality I expected. I contacted the designer who informed me he had sub-contracted the work out to another designer, and the new designer he subcontracted to was a far more inferior designer.
Disappointed, I started the search over again. I hired another designer on the phone. He took enough money to buy a nice, used exotic sports car. One day, I received an email fron a person I had never heard of (who turned out to be a very nice guy). He told me the designer I hired, hired him to design our project, and he had not been paid, and was suing the primary designer for non-payment of services, and consequently, he was withholding our assets from delivery to the guy we had hired on the phone. An hour later, I received an email from my friend, asking if I was aware the assets used in the design were plagiarized.
Beware of the Shills
When I think of shills, I often think of a guy on a corner in the Bronx, who appears to be winning every game of ‘guess which cup has the ball underneath’, whom, it turns out, is the brother of the guy who appears to be losing each hand when the unwitting passer-by decides he’ll take his chances and bet $5, only to learn the ball was never under any of the cups.
When you start hiring, you realize the world is filled with shills.
Case Study: The Shill hired on the phone
One day, I was tasked with hiring a developer on the phone. I went into a private office, sat down, and started asking highly technical questions. The person on the other end of the line spoke very quickly, he was abrasive, but quick to answer every question and nothing I asked stumped the candidate. He spoke with a thick accent that made it hard to understand what he was saying, but in software, talking to foreigners is par for the course. This was clearly a candidate who knew his stuff, and when my boss asked if we should hire the guy, I gave a nodding look of approval.
A few days later, I conducted another interview. The person I interviewed this time seemed knowledagble, spoke with a heavy accent, too, was abrasive, and we hired him a few hours later.
A couple months after one of the new-hires showed up, his manager came to me with some concerns. It didn’t seem like the new guy could write computer code. What bothered me was the new guy seemed passive and sheepish, far removed from the personality of either person I had interviwed. The manager asked me to investigate. So I walked over to the contractor’s cubicle and asked if he could subclass some code for me, so we had a consistent behavior for this control across all screens. I didn’t ask him to write the code in front of me, rather, I just needed him to write the code and I’d come back in a few hours. A couple days later, the code still wasn’t written.
That’s when a fellow developer told me the two guys we hired lived together. They had been friends since primary school in India, and I began wondering if the person I hired had done both interviews. So I asked the shill if we could speak for a moment, and I asked if he wouldn’t mind answering the exact same questions I had asked him on the phone, three months earlier. He was unable to answer any of the questions. The coding assignment was still unfinished.
After spending 3 months in fees to employ someone who failed to develop a product, we let the shill go. Then, the shill’s friend said he had to leave for a family emergency. Each week, the friend would call and tell us he was having trouble with his Visa and couldn’t get back into the country for one more week. We had two open positions and two projects that were idle. I began working nights and weekends, ordering pizza directly to the office.
Fallacy: Interviewing on the phone is a quick means to evaluate a candidate.
Memorization means nothing in terms of performance
After being burned in our phone interviews, we decided to move to a more rigorous interview format, and conducted each screening through a video-conferencing system. In our new format, my Project Manager would snap a photo at the end of each interview and if we hired someone, he would compare the photo from the video-conference to the candidate’s face the day the hiree showed up for work. I always worried someone would gain or lose weight or heaven forbid, grow facial hair, before their first day on the job.
One of first interviews with the video-conferencing system was a young guy who spoke slowly, always seemed to stumble with an answer, and then gave a response with a flawless delivery and a textbook answer. This developer knew the API of the framework we used so well, I was astounded. I asked him off-the-wall questions one would only know if they lived and breathed everything there was to know about this framework. We made an offer, the candidate accepted, and I thought I had hired my soul-mate; someone who would share my enthusiasm, and more importantly, someone who could balance the workload so I could go home by 9pm, 8pm, 7pm, 6pm, 5pm.
After he showed up, I walked the new contractor through the tasks we needed him to complete. A few hours later, I went to his computer to check on his progress, and he had multiple projects checked out of the repository. “An eager contributor”, I thought.
A quick glance at his workspace and I realized the projects he had checked out weren’t from our repository. Not a one.
I asked the contractor to delete whatever he was working on, and to work on our project. He was agreeable, and a few hours later, when I walked over to his cube. He had multiple projects in his workspace. Most were closed. The only open project he was actively working on was not even our project.
As I left, the contractor said he would like to ask me a question. When I told him to go ahead, he asked me a question about how he could build “a reusable dialog box that displayed different buttons, where each button would behave differently based on a function passed in as a parameter.”
Our product didn’t have a dialog box.
I had wrongly assumed in the interview, that the developer’s love and passion of the framework meant he loved building applications like the kind we were building. Instead, he was passionate about what was familiar to him at the moment. He had no enthusiasm for our product. He was the most qualified from a technical perspective to address our technical debt, but he didn’t have the motivation to do so. He was fully capable of writing code that would help us move our project into production, but nothing could motivate him. He would have been the only other highly experienced developer on this product which would have reduced the pressure on me to manage a team and write code, but instead, I found a developer who was only interested in learning, not developing. In the interview, I needed to find a way to evaluate the candidate’s ability to solve more than technical problems; I should have found a way to ensure he could fix technical problems specific to my problem domain.
Fallacy: Memorization is an indicator of enthusiasm, and enthusiasm will help you pay down your techical debt
One-on-One interviews lead to a frame of reference bias
Frame of Reference bias
Too often, developers value a candidate’s worth, based on how similar he or she is to the interviewer. Sometimes, you attend an interview and realize the questions asked are meant to measure the probability of success, and those same questions seems to correlate to the personality of the interviewer
The candidate who makes it through the gauntlet is going to be one who has a background similar to that of the interviewer.
A development team often becomes made up of people who look alike and come from a similar background. For example, companies that have a pool of developers who are self-taught are more likely to hire other self-taught developers. Companies with a pool of developers who went to college to get an Master of Computer Science, are more likely to hire developers with advanced degrees in Computer Science.
The problem is, the groups begin to narrow their potential pool of candidates based on their pre-established beliefs, and worse, they focus on narratives that have almost nothing to do with finding the right person for a project.
Case Study: The Cat Lady
I once went to an interview where I met a pretty neat group of people. I had already made it past several rounds of highly technical interviews, so this was more of a meet-and-greet, with the appearance of one-on-one interviews (AKA, the personality test). One guy who interviewed me had shorts and a tee-shirt on. One guy had pictures of donuts on his wall. I figured the place was relaxed. The man-in-shorts seemed like the kind of guy you could drink a beer with after work. In his interview, he was only going to ask me one highly technical question about a rarely looked at, but commonly used interface, and he was scared impressed when I nailed the answer.
I interviewed with a woman who asked me to sit down in a chair in her office. On her desk, was a picture of a cat. The picture itself was in a small wooden frame, nicely displayed with a matting. On the wall, there was an 8′ x 8′ canvas, with the same cat. In the wall photo, the cat was clearly taken from an overexposed photo.
“Do you like cats?”, she asked.
“I like cats.”, I replied.
“Do you have a cat?”, she asked.
“I don’t own a cat.”, I replied.
She scribbled in her notebook with a look of disgust.
Next, she asked me if I had a Masters in Computer Science. She was starting high, presumably to give me a low-brow look when I told her I only had a Bachelors in Computer Science.
I replied, “No. I have a Bachelor of Arts in English Literature”.
She scribbled in her notebook with a look of disgust.
Then, she asked if I could draw a Semantic Data Model on the whiteboard, and I couldn’t, because I have never even seen a Semantic Data Model. Actually, in 15 years of software development, the only time I have seen illustrated data models was in one company where we had a Waterfall process, and the section of the documentation with the data models was well below pages 70-95, where my project belonged, in the section dedicated to “Business Analysts and Managers”.
Then, she scribbled in her notebook with a look of disgust.
At this point, the interview abruptly ended and we parted ways. The company escorted me out, thanked me for my time, and I never heard from them again.
In my frame of reference, I’m self taught and can teach myself pretty much anything if I have a business case for the need. If I need to learn a concept (for example, a language, platform, or framework), I have a methodology I’ve adapted which works for me:
- I build a small working application people will find useful in the language I need to learn.
- I hold the baby while she naps and Google a question over and over on Stackoverflow.
- I sketch ideas and solutions to business problems in a Moleskin notebook at Starbucks when my wife or inlaws have the kids
To me, the markers for success for the position were based on an extensive knowledge of the framework they were using. That was my understanding after talking to the recruiter, and based on the questions asked during the technical phone screens. This company badly needed someone with extensive knowledge of an older framework.
Out of 5 interviews, the framework was the focal point. However, one developer had a different frame of reference for how she believed success was measured, which was probably based on a strong understanding of abstract concepts learned in academia. Her frame of reference for ‘value’ where different than mine, and in my mind, different than the requirements from the person who posted the initial requisition.
To her, the markers for success for the position were based on a knowledge of academic concepts that could be repurposed on any given framework or langauge.
In a one-on-one interview, she saw me as a poor fit. In a panel interview, or one with a chaperone or mentor where topics are kept on-point, this frame of reference bias wouldn’t happen.
This interview should have been kept in-bounds by eliminiating a personal frame of reference bias. This kind of check is clearly demonstrated by the mass conformity witnessed in the Asch Conformity Experiments, which “demonstrated the degree to which an individual’s own opinions are influenced by those of a majority group.” Sometimes, mass-conformity can be a good thing when it comes to providing a cohesive interviewing experience across a team.
One way you can combat the frame-of-reference bias is by ensuring all interviews are conducted with a chaperone or moderator, whose sole job is to ensure the interview doesn’t go off-track, but I’ve never seen a company include a chaperone or moderator in the interview process. Instead, you often go from room to room, where each individual must agree on the candidates’s worthiness. In the process, companies lose great talent because they believe a collective consensus is a measure of a candidate’s worthiness, and they approach collective consensus by allowing each person’s individual frame of reference for what “success” in a hiring means, to be influenced by personal life experiences.
Fallacy: Collective consensus ensures candidates are chosen based on a bigger vetting process, The bigger the vetting process, the more likey your group is staffed with the best talent.
You can’t test a coder by having him write code
A few years ago, there was a big movement to test a developer’s competency by having him or her write code during the interview. Several start-ups even popped up where developers were asked to write code before the interview, where the coding was recorded and then sent to a manager to evaluate. The idea on paper sounded great. You could evaluate a candidate’s problem solving skills in real-time, see how long it took them to solve a particular problem, and get a sense of their coding style.
Now, when you go into an interview, companies ask you to write real, live, actual code. And you, as a candidate, are then evaluated based on “whether the candidate really knows the subject matter.” That’s a terrible idea.
Case Study: The Voyeur
I had a company contact me and say, “We want to meet you”, which usually starts with a long, email on LinkedIn where people spell my last name wrong even though it’s easy to copy and paste. The position the company contacted me about was a “Senior Software Engineering” role. Sounds great. Let’s meet!
I made my way through traffic, paid sixty dollars to park in the company’s garage, and then made my way into the lobby where I was greeted by the Senior Manager. The company brought me upstairs and two, junior developers came in and asked if I was there for the Junior Developer interview. I decided that rather than explain there was a terrible mix-up and I needed my parking fee refunded, I would go through the interview process and then have a talk with the Senior Manager about the confusion afterwards, mostly because I have gray hair and a resume longer than most grocery lists, so it should have been pretty clear there was a mistake somewhere in their communication trail.
One of the Junior Developers said, “I’ve set-up some coding challenges for you. Just take your time and see if you can figure them all out in 10 minutes.”
The developer handed me his Macbook. Now, I have nothing against Macbooks. I like Apple products as much as the next guy, but the only Macbook I have is from 2007, and it sits in my ottoman so my son can bang on it. I’ve used a Linux OS at a job before, but I have never had a client or employer who used or offered Apple products. I like Bill and Melinda as much as Steve, Larry, and Sergey.
I asked the developer what IDE he was using, because after using Enterprise IDEs for most of professional career, he has elected to use an IDE I have never used before.
Like all developers, I use keyboard shortcuts to save time. Ironically, keyboard shortcuts on an operating system and an IDE you have rarely or never used, save less time than my morning detour against traffic to Starbucks. Each time I tried to open a file on the developer’s computer, each time I tried to open a browser tab, or open the developer console, search for a file, search by file extension, or to refresh the browser, I would select the “appropriate” shortcut, and something completely unexpected would happen.
To further add to my coding challenge, notifications kept popping up. I’m not talking about a single notification, but instead, the developer had left his email client open, and one toast notification after another would show up in the corner of the screen.
“Free donuts in the breakroom – Gary”
“Deployment to dev completed successfully – Jenkins”
“Donuts are almost gone – Gretchen”
“Build failed in Dev. – Jenkins”
“Donuts are all gone – Gretchen”
“Build #2 failed in Dev. – Jenkins”
“I never got a donut – Gary”
At home and work, I actually close my email client so I don’t get notifications because distractions prevent me from focusing on the task at hand. Great IDEs now offer “focus modes” so you can stop distractions from bothering you. This “test” was not in any way analogous to how I work in real-life. These were not the tools or environment I used to write code – over the past decade.
Also, this may come as a complete shock, but at home and at the office, people don’t actually watch me code. Sometimes, when there’s collaborative pair-programming, someone may watch me write code I am familiar with to trouble-shoot an issue, but a stranger standing over my shoulder, asking my to write code, is not really reflective of an environment where I do my best work, nor is it the type of interview where the interviewer is going to get an accurate assessment of my coding skills.
I sat in a room I have never been to, which had the terrible smell of body odor. I sat at a desk which wasn’t my desk, and in a chair that was awesome (really, it was awesome). I like familiar environments, but in an unfamiliar environment, I have a heightened sense of self-awareness and the feelings of an outsider. In an unfamiliar environment, I reflect on this study I read in college, which suggested when one dog was knowingly on another dog’s property, he was likely to lose a fight, regardless of size, or health, because he knows he’s not supposed to be there. In this environment, I was an outsider. A loner. A rebel. In a different environment, I’m just not the same person.
By the time I was on challenge two (eight to go) and ten minutes had passed, the two Junior Developers stood up, and said they had all the information they needed, and left.
Never test a candidate’s ability to context switch
The interviewers were asking me to context switch. What they were testing, whether they realized it or not, was my ability to switch environments and solve a problem. This would be a great test for James Bond who is often in a different environment on a regular basis with life-threatening issues. I mostly write computer code at a desk where you can actually see three-week old M&Ms on the floor. The two Junior developers meant to test my ability to write a language and understand common problems, but instead, they were evaluating my ability to:
- Switch to a different operating system
- Switch to a different coding tool
- Switch to different keyboard shortcuts
- Ability to ignore notifications
- To write code in an unfamiliar environment
- To write code under the pressure of time
- To write code under the pressure of supervision
Live-coding is one of the most dangerous tests of a candidate’s qualifications you can perform, because you’re really testing the ability to switch context. As an organization, you end up hiring developers who perform well under pressure, who probably have the same coding environment at home as you do in your interview, and you hire developers who appear to be completely competent, but who are more likely similar in workstation preference and handle unfamiliar environments better than other candidates. Your organization ends up with less diversity, and more similarity, which is dangerous, because diversity drives home an understanding of new technologies, people and processes that help some companies to survive while others go belly-up. Sameness begins with testing how well someone performs a context switch.
Team fit is not the same as project fit
The different tales of woe when it comes to hiring, which you have read about above, have a single premise which can help explain what went wrong. The organizations above, along with the individual team-members (me included), were evaluating a candidate for team fit. Above all else, they wanted to see whether the skills and character of the person they were might hire would make the candidate a good fit for the position they had available. And in doing so, they missed some great candidates because the process used to select candidates was terribly flawed.
It’s not all doom and gloom. The path forward.
Your organization should build a team based mostly on project-fit. By continuously modeling your developer needs based on your evolving technical debt, you can build better products and the diversified team your organization needs to thrive. Let’s begin.
How to REALLY interview a software developer
In order to create a better product, you need to first understand the current strengths and weaknesses of your existing team. If you’re reading this and you’re a manager, you probably already have a good understanding of the issues and if you need help, there are many ways to automate reports to gain an initial understanding of your project’s technical position and technical needs.
Staff based on the team you have, not the team you want
Once you know what each individual and the team lacks, you need to establish the type of person you’re looking for who can provide a counter-balance to your current weaknesses. The person who can help your organization is what I like to call, your company’s Newton. A Newton is an individual who provides an equal and opposite reaction to the project’s deficit.
Before you interview
- write down 100 individual weaknesses
- write down 100 individual strengths
- write down 100 product strengths
- write down 100 product weaknesses
- Identify the most significant weaknesses
- Scout based on the greatest weakness
Trying to identify 100 of anything isn’t easy, but your ability to identify a large number of attributes means you have asked questions, slaved over generated reports, talked to employees, former employees, and you’ve looked at the code, the QA reports, the sales reports, the budget, the legal issues, and much, much more. You need to take a big-data approach to identifying what kind of deficit is your greatest enemy, and you need numbers to back up the argument for the specific Newton you seek.
Your Recruiter should be a Scout
Finding the right candidate, the possible Newton, is a different kind of search from a general employee search. Generally, your recruiters canvas the job boards for people who are either employed or unemployed, that meet the technical requirements. Plain and simple, recruiters simply search for a candidate to fill a position.
You’re not looking for a “Recruiter”. Your company is looking for a “Scout”. A Scout doesn’t search for candidates to fill a position, a scout searches for a candidate to fill a very specific need. You may have to come to a special financial arrangement with your scout because unlike a recruiter, the scout is unlikely to find many candidates who can provide the specific need you asked to have addressed, and you’re not interested in interviewing endless candidates. A candidate who fills a very special need is likely to be a good choice right from the beginning, even if they have undesirable traits.
A Scout is going to look at what your product lacks, and he or she is going to scour potential candidates using Stackoverflow, GitHub, LinkedIn, Blogs and published papers to find someone who aligns with your needs. A Scout looks at the code written to see if the potential candidate has solved similar problems before. If you’re looking for a Linguist, they will search through GitHub forks that were dedicated to a refactoring of names, or long and thoughtful posts on an open source project’s current issues and how the team might address those issues. They’ll search for people mindful enough to correct their own typos in forum posts. A Scout tries to fill one position that represents your Newton, instead of trying to fill multiple, open positions, because they respect and understand the gravity of importance the right hire has toward your project’s success.
There are many different types of Newtons. Differnent Newtons will serve a different purpose.
Types of Newtons
Your company is losing time to manual, repetitive tasks. You’re performing manual tasks that are slowing down development as you manually search through code, performing line by line replacements of hard-coded strings. You’re DTOs and Entities have an almost identical make-up, but together, they have bloated your code-based with 100s of objects that almost mirror one another. Your deployments take a day as you compile locally and migrate the changes to another environment. Your libraries are inconsistent between machines because the dependency management and lifecycle are inconsistent.
Typical job posting
Senior Software Engineer. Experience with Java, Maven and ANT, preferred
Named after the Sahara desert, this Newton is a big believer in DRY software, and he is repulsed whenever he is tasked with doing a task twice. The ideal candidate is disgusted when he sees a task that could have been automated or reduced to its lowest common denominator, but hasn’t been. He is not going to be your most productive developer, because he spends too much time re-configuring his code clean-up to group getters and setters together, and he is unable to look past constant names that don’t begin with a similar prefix to group each field by alphabetical order. Instead, his job is to reduce the repetitive tasks of the team.
The Sahara looks in the mirror each day and stares at his pot-belly and receding hairline with a sense of ease, because he is proud of everything he has accomplished as a software developer, and the idea of doing menial work is beneath him. He wants to learn new concepts and challenge himself. He would easily be characterized as having OCD. He might take medications for an obsessive compulsive disorder. Don’t pay much attention to appearance as an a marker of a potential Sahara. The Sahara’s disheveled and messy appearance might be his way of rejecting social norms and conformity, or convincing himself he’s not obsessive about everything. The Sahara has never fit-in very well in different environments because he always believed the world should have a certain order to it. His desk is organized and clean with cord routers, and his laptop bag does not mix pens and batteries in the same pocket. He may not be the most pleasant person, but he will provide the counter-balance your team needs.
On the Job
The Newton you’re seeking can learn the ins and outs of Maven or ANT in a short period of time. He can learn RegEx and he’ll figure out a way to turn the entities into serialized objects the client understands. There’s no need to include any of the frameworks in the job description, let alone, ask about them in the interview. You’re going to pursue a candidate based on their loathing of all things redundant. The candidate you’re pursuing is going to feel belittled by having to repeat the same task more than once.
In the interview, you’re going to probe the candidate in unique ways. You might ask the candidate to write on the whiteboard a palindrome and have him search through the palindrome to find a specific letter, then, to spell the palindrome backwards. Then, you’ll ask the candidate to find the same letter again. Then, ask him to spell the palindrome backwards, again. If the candidate seems frustrated and bothered at any point during the interview by the redundancy, or better yet, keeps insisting in an angry tone he has already answered this question, then you have a Sahara. If the candidate hasn’t shown any emotion about answering the identical questions again, you may elect to ask him what his name is, pretending you forgot. You’re looking for a person who has a strong emotional reaction to repetition, and the insulting nature of redundancy.
You’ve been building your application for a long-time. Part of the application uses a framework and language that is so old, only a handful of browsers still support the necessary plugin. Your customers have started suggesting they won’t be renewing their contracts, because there’s too much demand from their staff for an application they can access on their phones and tablets, so they don’t have to be in the office to do work. Your sales have started to slow down, and you’re now going to have to make cuts to your staff, right when you think you need them most, because they have all the domain knowledge. You start to wonder how you got so far down the rabbit hole with such a huge team of intellectuals. Why didn’t someone stop the madness before it was too late? How did you end up in such a risky position? What were you missing?
Typical job posting
Senior Software Engineer. Experience with cutting edge frameworks and latest languages
Named after the artist, Andy Warhol, the Warhol loves everything modern. He isn’t afraid of change or age. Instead, he embraces change as an indicator of progress. He is willing to accept the world isn’t perfect, but he likes pushing boundaries and he’s against the status-quo. The Warhol is the developer in your group who constantly reminds your group that in this other framework or language, you can do things easier. He is quick to point out and remind everyone that with this new API, you can delete all of the code Gary wrote last Summer, even as Gary steams in the corner. The Warhol is the developer who builds a prototype one day without asking to show that a third party authentication service can increase conversions, but was quickly shut-down by Senior Management for doing work that wasn’t assigned to him. He can’t help but love change and while your project uses an older framework and language, the Warhol is spending his free time reading the docs for a server or language your team has never heard of, and obviously, never plans to use. When deciding what he’s going to do for his pet project at the office, the Warhol quickly turns to language trends to see what the flavor of the month happens to be, before answering.
On the Job
The Warhol is often an advocate and a change agent. With large systems, you won’t be able to have the Warhol single-handedly update your product, but you can use his enthusiasm and passion to infect others. If your project is small, the Warhol can spend time updating libraries or languages, methodologies or device compatibility in ways that help your product to offer features and capabilities that help others to feel a sense of pride in the product. If your team has a big project, you may wish to have the Warhol design prototypes or smaller applications that leverage your product’s capabilities. You need to ensure the Warhol has a path to do more than develop R&D projects that end up in a directory where they the labor of effort will go to die. Perhaps you can use the Warhol to update libraries and frameworks, or the look and feel of the application. This is the Newton who must push the product forward so others feel a sense of momentum that eventually consumes your product, and prevents it from becoming a lethargic leviathon which cannot be tamed or moved, and becomes all consuming as a cancer that grows.
When you interview the Warhol, don’t be put off by questions about whether you plan on moving to a new framework or language given the legacy nature of your current platform. You want to see how the Warhol can modernize a project, given time and the right tools. You’re interested in how he would motivate others to follow in his footsteps. You will want to question the Newton about his past approach to updating and modernizing a product, and look for a sense of enthusiasm about updates and changes that far outweigh other concerns, such as one’s ability to write clean code or testable code. Instead, it’s more important that the Newton be charismatic and inclusive enough that other want to be involved with his projects. He should attract others to his task at hand and drive forward a mission of modernization that others feel has precedence over the status-quo: feature creep as a means of adding value.
Be aware of a candidate who might appear to be a Warhol, but is in fact, just a brand-snob. Brand-snobs read the developer journals of popular companies and take the comments and sales press by the PR team as gospel, and they just regurgitate what they’ve read. They neither have exposure to alternative approaches or experience. They just follow the lead of a product evangelist.
Your company first elected to hire a $300/hr software consultancy who built a web-application that looked as though it might be used as a text-book example for every cutting edge language, framework, test-suite, and automation tool available. After a year of development with the two brightest consultants you have ever met, two guys show up named “Lee” and “Lei” show up. They bare speak English, and as you sit at your desk, you receive an email from the consultancy letting you know the architects are being moved to other projects now that “We’re moving into a development phase.” Six months and $313,200 later (plus food and lodging), the code coverage has dropped to 5% and clicking a button (any button), opens a dialog with a stacktrace.
Feeling anxious about all of the money you’ve been spending without measurable progress, your Director has come over to your desk to discuss the idea of “Rightsourcing” the project. Instead of paying $300 an hour for two guys who seem to stare blankly at a screen for most of the day, he has a plan he calls, “12 for 1”. For each developer he currently pays $150 an hour to support, he’s going to send the project to Bangalore, where his new consultancy has promised 12 developers for $150 an hour.
“Twelve times the progress!”, he yells in pure enthusiasm, before leaving your desk.
For three months, you have a daily conference call at 7am and 10pm, seven days a week, to accommodate your new team. Your wife has left you. She has taken the dog and the kids, but happily, she left you the cat and 20 frozen pizzas she bought at Costco.
Strangely, each of your daily conference calls always involves the same two developers in Bangalore, and a project manager who may or may not be your future replacement, but he really liked sitting in your chair when he visited the office. When you ask why the other 22 developers can’t attend the conference call, you’re Indian consultancy tells you the microphone is broken on their conferencing system.
“We’re hoping to have it fixed soon”, he tells you.
Each commit to the repo has the names of only two developers.
“Controls”, the project manager says, “We have very thorough controls in place.”
Another year goes by. You lost your bonus because you failed to manage the team assigned to you “appropriately.” You’re thankful your new apartment is a first floor apartment with sealed windows. As you prepare to leave for work one day, coffee in one hand and keys in the other, your cat bolts through the door in an apparent escape attempt. You never see the cat again.
Your boss decides to bring the project in-house and hire two, full-time developers, in the hopes of having a working prototype in production by Christmas. You begin to assess what you need to do.
Your code is now spaghetti-code, and while the business requirements changed a little, the domains, class names, property names, operation names make it impossible to bring on new talent to save your project and your job. New developers are confused by the naming conventions, which look like the menu at a Fusion restaurant, and the muddied domains prevent a separation of tasks that you need to begin assessing where the issues originate in your team and project.
Typical job posting
Senior Software Engineer. Must have excellent communications skills
Named after the author, Ernest Hemmingway, this Newton is someone who loves language. He’s a developer who likely studied English Literature or Creative Writing in college. He has a strong command of the English language, and while he may not understand architectural concepts or even design patterns, he can give your project a sense of purpose and clarity. With purpose and clarity, and the end of obfuscation, you can more easily introduce architects and design-pattern specialists.
The Hemmingway is someone who loves how communication matters. You won’t find this Newton reading news written by “so called” journalists. His choice in news will be refined, and he’s more likely to choose his news source by the number of Pulitzer Prize winners on-staff, than the interesting celebrity news.
The Hemmingway likes programming, but he may not love programming. He likes programming because it allows a creative outlet, the same way writing a novel provides a creative outlet, but he could parlay his talent into other mediums as well, provided there are words involved, as well as the nuances of communication, such as diction, inflection, rate of speech and even body language. The Hemmingway has interests that extend beyond writing code.
If you try and hire an architect or OOP expert too early, before this Newton has had a chance to provide context around the project’s purpose through eloquent semantics, only one of two things will happen: First, your highly experienced developers will be useless, as they struggle to apply their expertise to your spaghetti-code monster. You’ll wonder why you hired either of them, and you’ll be paying high salaries to people who have very few code commits. Second, you’ll probably drive these bright, senior developers to find positions elsewhere. No architect or OOP expert gets the chance to see a project’s code before they’re hired, and these two “gurus” will resent you for hiring them to work on a project they can neither learn from, nor use on a resume.
On the Job
The Newton you’re seeking will need the right tools for the job. Some tools in development make refactoring better than others, and special consideration should be given to ensure the Hemmingway has access to these tools. A very small investment in refactoring can pay big dividends when it comes to bringing your project back from the gallows. The Hemmingway needs an environment where he is able to focus and concentrate, one where he isn’t bothered by the distractions of banter that prevents his lazer-focus from thinking of the changes necessary to make the impossible, possible again. Providing him with an office, when others have cubes or an open floor plan can make a big difference. You should help the Hemmingway to avoid meetings, because the Hemmingway’s thought process is likely to come about after long stretches of thought and consideration, and an hour long distraction, might cause this crafty savior to lose days of work, as his thoughts build momentum that manifests in large, sweeping changes.
When interviewing the Hemmingway, you don’t need to concern yourself with his current ability to refactor code. For example, you don’t need to measure his knowledge of class name refactoring, or method and constant extraction. His ability to refactor a project into design patterns isn’t completely necessary, either. Over time, as you focus on Continuous Candidate Modeling, you can hire Architects and OOP experts, that can refactor project into elegant design patterns that would make Martin Folwer weep. Instead, your interview should be focused on the candidate’s grasp of language. You’re looking for someone who has a vocabulary far above the vocabulary of anyone on your existing team. Your interview should pay careful attention to the candidate’s word choices, and his ability to express himself.
Temperament doesn’t matter. Some of the best communicators are motivated by emotions, and finding someone with a moderate temperament doesn’t mean the person is more emotionally stable.
When asking the candidate questions, focus on his ability to tell a story. If you ask about a difficult challenge he had with a project, keep probing and ask him to describe the project, the team, the raw emotions involved. You’re looking for someone who is engaged with projects on a level that goes beyond completing the project or the art of the code. You want someone who is clearly emotionally engaged with how the product changed a team’s culture, or how the improvements brought about a change in the lives of a sales team that had little to sell. You’re looking for a candidate who is involved with the meaning of a product, and not the transient nature of build and deliver. Feel free to test the candidate by asking him to discuss the project’s importance to him, on a personal level. Pepper your questions with the words and phrases that only a true linguist would love. If the person you’re interviewing doesn’t ask for clarification, then you likely have someone who can help right the project.
Driving change into practice
If you identify the Newton, it’s easy to be fooled into thinking the job offer and acceptance marks a new beginning. If you’re lucky enough to find the candidate who provides the energy to drive project in the opposite direction, you might believe you’ve achieved a major milestone. The sad reality is that most company cultures are far more powerful than any one individual. Even the most charismatic or assertive employee can quickly be drowned out by the forces of an established culture that is resistant to change.
I’ve worked for companies that are part of a sinking ship, and while it’s clear the vessel is taking on water so quickly, no one is going to change the rapidly deteriorating situation, I’ve found most passengers are more interested in prolonging the destruction if it means they don’t have to deviate from what is familiar, their routine, and what often represents their established view of the world around them.
To ensure your Newton is able to make the desired changes within your product, you will need to repeat a very simple process on a daily schedule.
- Knowledge extraction – You need to know what the Newton is doing each day. It’s less about ensuring the Newton is working, and more to make sure the team’s existing habits, their current way of going about their business, isn’t influencing the decisions and actions of your savior. Other teammates may resent the new-hire, they may object to his additional autonomy, of they may simply believe he should become ‘one of them’. Your goal is to make sure the Newton isn’t held back by the routines, practices, and culture that steered your product in the direction it’s going. Ask yourself if the Newton is providing an equal and opposite force, a counter-balance to the current pull of your product. If not, you will need to act quickly to ensure changes are made.’
- Conversion to story – By converting the requirements of the product, as it related to the role, into a story (either a user story, developer story, or the like), you have an Agile process to follow that lends credibility to the task at hand. You will need to make sure the user story, in your own mind, is a reflection of the Netwon’s skill, without being overly direct. When you hire someone because they are able to steer your product in the opposite direction of what many have invested blood, sweat and tears into, you will be resented for the appearance of being thankless.
- Mantra based behavioral change – For the benefit of the product, you must repeat to the Newton and the team, what story the Newton is working on. This prevents the distractions and busy-work that other teammates can perform, and it helps the Newton to focus. The quicker you can change the direction of a product, the faster it aligns with your business objective.
The Technical Competency Measurement
Once you find a Newton, you will need to measure the candidate’s technical competency. We’ve discussed why context-switching is a poor measure of a candidate’s ability to write code, and I don’t believe you should rely on API memorization as an indicator of qualifications, either.
You need to find someone who knows enough about the basics, that, together with their unique character, can help to steer your project in a different direction; the opposite direction.
Some companies rely on a take-home test. I no longer believe in take-home tests, and I surely won’t complete one again.
In 2009, I was asked by an outside recruiter to undergo a take-home test. The test was a prerequisite to the in-person interview, and I was asked to write a special type of search algorhthem. I spent days on the assignment, and I even went so far as to brand the project for the company. The end result was something that had a means to prove it’s efficacy, and it was rather attractive for something that would only be seen by a small handful of people. I submitted the project and I never heard back from the company or the recruiter.
I had no rapport with an individual inside the organization. No one person felt obligated to respond, and I can’t even be sure the communications channels were open. Did the recruiter even have the email address of the right person or someone who worked at the company? Did anyone receive what I worked on for 28 hours of time? I’m not sure, but if you, as a company were to send me a take-home challenge today, even with endless experience, my unwillingness to be vetted in this manner shouldn’t be seen as a sign of disrespect or incompetency. It’s just not a worthile time investment.
With take-home-tests, you also risk having someone else solve the riddle for the candidate. It’s not uncommon for a candidate to ask his peers for assistance on topics that might be unfamiliar.
You should always pursue a strategy that allows you to compensate the candidate without hiring the candidate. Here’s how it works.
- Build rapport – Don’t allow your recruiter to be overly engaged with the candidate. Often times, recruiters create an illusion about the company and project that prevents a relationship from forming on authentic terms. It’s not uncommon for a recruiter to promise a job title 2-tiers above the actual position, or a salary that is also not within range. Hyperbole is part of the salesmanship of a job, and it doesn’t take long before a candidate is reserved from being himself or annoyed because of a “mis-communication”. Instead, have someone from your actual team reach out to the candidate and begin a dialogue. The dialogue doesn’t have to be strictly formal, dedicated to the job at hand. It’s okay to discuss trivial matters, so long as you don’t cross the boundaries and become unprofessional. Let your candidate know that you’ll be offering up solutions based challenges which they’re free to work on in the comfort of their own home, and they’ll be compensated in a manner that is equal to the investment of time. Cash is tricky, but you can propose gift-cards or a charitable donation in the candidate’s name.
- Propose a solutions based challenge – In order to see how your candidate solves problems and communicates, you should choose 3 unanswered questions on Stackoverflow. Choose problems that are associated with your project. If you use a specific language or framework, choose unanswered questions that use those languages and frameworks. Be sure to see if the question itself is coherent and articulate enough that it can be answered. Then, have the candidate propose an answer to each of the questions. With a solutions based challenge, you give the candidate an opportunity to better market himself or herself in the community, and you provide a chance to see their communication and technical problem solving skills in an environment and domain that is familiar and comfortable, which is a setting that more closely mirrors how people work.
- Open-source project challenge – Offer your candidate an opportunity to work on a very small segment of an open-source project. Discuss with the candidate an open-source project that is similar in some respects to your own project. Reach out to the project owners or contributors and ask what the current needs are, or look at the issues for each project, and in the discussions or issues list, identify a task that can be solved in a short period of time. Then, have the candidate fork the code, and begin a dedicated effort at resolving an underlying issue. Even if you don’t hire the candidate, the candidate benefits in the following ways:
- Philanthropy – The candidate invests in developing a project that is outside the organization which contributes to the greater good of the community. It’s a chance to further build relationships and a network, which helps if you’re already out there looking for a job.
- Resume builder – The candidate invests in developing a project that further demonstrates his competency. He’s able to show to the very next company what he is capable of doing. His time hasn’t been spent on a closet project.
- Closure and compensation – Regardless of whether you hire the candidate, you should let the candidate know what he did right or wrong, or even if you decided to hire someone else. Then, provide the compensation you agreed to.
Domain Knowledge is for Architects and Principal Developers
Obviously, you need people on your team who know your product inside and out. You need people who can ensure the feature you’re adding or the test you’re writing provides real business value. You need people who understand your build process and deployment process. You need developers who can make informed decisions about which tools and frameworks you should migrate to over time and you need someone who knows which platforms can help you reduce costs. You need people who can ensure the code is scalable and someone who makes the go/no-go decision for code that is idle in the code-review system. You need some great developers.
I propose you choose Architects and Principals who are very well compenated and thus, have a lower likelihood of leaving your organization. You need people whose domain knowledge has little value outside of your organization, and you need to pay these people with dumptrucks full of cold, hard cash. Pay them insane amounts of money because you never want them to take their domain knowledge with them when they exit. The stakeholders should always be well compensated and showered with lavish praise, because you need a handful of people in development who see your product through, people who know all of the team members, both past and present. They need to know the rationale for each commit and they need to know the business value for each commit.
Hiring to offset technical debt doesn’t need the same level of project ownership. Your Project Manager and team lead should work together to write stories and granular tasks that any mid-level developer can follow. You don’t need HR hiring developers for a life-time of service and a team of pleasant people isn’t how great software is built. Often, it’s quite the opposite.