New article at Ranorex, “Agile Hiring”

agile hiring
Agile Hiring (26-Jul-2018)

Don’t create a long laundry list of technical buzzwords for hiring. There’s a better, more agile approach.

In this blog post for Ranorex, I present six major points to consider when hiring someone for your agile team: three job requirements essentials, and three important aspects to consider during the hiring process.

New article at Ranorex, “Raspberry Jam Gets Thin in the Pool”

raspberry jamRaspberry Jam Gets Thin in the Pool (16-Jul-2018)

“The more you spread it, the thinner it gets.” — the late Gerald Weinberg

In this blog post for Ranorex, I talk about the mass growth of our industry, and how as a result developers have on average less experience than ever before. I talk about some ways in which we might thicken up that jam.

Interviewer Tips

About every other week, Monster or some portal publishes an article on how to interview properly–what kinds of questions to expect, what kinds of attitudes to carry, and so forth. You’ll also see articles on what sorts of questions to ask as an interviewer. What aren’t published as often are suggestions on how to avoid being a bad interviewer.

While I run a consultancy, I’ve held several full time positions intermittently. I believe in order to stay relevant when training or consulting, it helps dramatically to be part of a real team from time to time. I also find it wise to interview at least once a year–even if you like your current job, it’s always a good idea to find out what’s going on out there.

I’ve had some interesting interviews over my career. I’ve done well on most, and botched a handful too. I’ve also been subjected to “interviewer abuse” many a time. I personally have interviewed close to a couple hundred candidates in my career, and have tried hard to avoid making these candidates miserable.

Here is a short, not exhaustive, list of recommendations I wish my prior interviewers had read before interviewing me:

  • Don’t treat the interview as an opportunity to blather endlessly and show off your skills. Your candidate should be talking at least as much as you.
  • Don’t ask your candidate to “write code” at the whiteboard. Chances are you have at least one computer in your office that the candidate could use.
  • Don’t fixate on overly clever algorithms or puzzles. Insights needed to solve these may not come, particularly if it’s 3:30pm on a Friday and you’ve already subjected the candidate to hours of interviews. Better: Start with a reasonable problem, keep the discussions open-ended, and be willing to shift gears based on what you learn from the candidate.
  • If you think a candidate’s answer to a technical question is wrong, discuss it. There are often other ways to answer a question, and you might have also not done a good job of asking it. Initiate a discussion. You might even learn something yourself.
  • Don’t insist on any more than a half day’s interview. We all know that the important impressions are made or not in the first five minutes, so demanding significantly more time is inconsiderate and suggests vast room for improvement at interviewing.
  • Provide the candidate with a rough agenda, making sure to include what roles each interviewer has in the organization.
  • Ensure your candidate gets exposed to the culture of your company–make sure the interview process accurately reflects it! Make sure they get to see the team at work.
  • Don’t pigeonhole your candidate. Try having an open discussion and see where things lead, instead of forcing him or her through a predetermined interview sequence.
  • Don’t make a candidate slog through the interview process if it’s clear to all parties that he or she is not a good fit. If you think there’s a problem, have the courage to initiate a dialog with the candidate about the supposed mismatch. Ask them where their strengths lie, and look to take the discussions there. Chances are that you’re not doing a good enough job of asking questions.
  • Don’t deliberately make your candidate uncomfortable. Avoid intimidating behavior, such as staring angrily or morosely and refusing to utter more than a syllable or two. Don’t forget to ask them if they need water or a restroom break.
  • If you insist on “behavioral interviewing,” make it clear to the candidate how his or her answers correspond to your decisions.
  • If you are declining to extend an offer to the candidate, be honest with them about the reasons why.
  • Thank your candidate by phone or email within a day of the interview, and indicate when you will have an answer.

Interviewing Well

A friend, “Joe,” requested some tips on interviewing after returning from one where he felt uncomfortable and didn’t get the job. Here’s what I told him:

  1. enjoy yourself. Convince yourself that you’re there to find out more about the place and see if it’s somewhere you want to work. Don’t view the interview as “I gotta get a job.”
  2. act yourself and relax. This is very similar to recommendation #1. If you’re somewhat obnoxious in person, make sure a bit of that comes out. Hiding things rarely works, and if they can’t handle you being yourself, then you probably don’t want to work there.
  3. enjoy yourself. Figure out how to make your visit entertaining. Even if you don’t get the job, you’ll have had some kind of adventure. If the visit ends up sucking, or you don’t get the job, you’ll have a good story, and will have had an opportunity to figure out how to do better for the next one.
  4. it’s not what you say, it’s how you make them feel (straight from Weinberg). This is a critical mindset for making sales, consulting, training, etc. It’s an approach I’m still learning how to do well, but have noticed that it can work wonders. If you leave them thinking, “wow, I just had a great time while Joe was here,” then you’re probably getting the job. People won’t remember the specifics of what you say, unless you say something really stupid. But they do remember how you make them feel.
  5. see recommendations 1, 3

According to Joe, it went real well on a subsequent interview, particularly rules #1 and #2.



I double what you’ve written and say to choose a proper time to attend interviews 🙂 The best possible probably is when you are happy with a current company, as you don’t care so much about getting the job and you can easily follow rules: 1,2,3 😀

Yes, great notion. I recommend everyone interview at least once per year, just to stay in practice and also to see what else is going on out there.

Interviewing: The Email Challenge

I’ve interviewed a significant number of candidates recently for a developer position at my current customer. I’ve never boiled down interviewing to an exact science, but I think I’ve managed to get a lot of bugs out of the process. The up-front work is where I’ve been concentrating most of my efforts, due to the large number of resumes. By “up-front,” I mean the efforts leading up to the decision as to whether or not to bring in a candidate for face-to-face interviews.

Prior to even looking at resumes, putting out a good job description is an important step. That’s a topic for another blog entry. Once you have a stack of resumes, your job is to whittle them down to a small enough number. My recommendation is to set aside two weeks for screening candidates. Over that two weeks, expect to run an average of 2 phone screens a day. (Don’t try to do more than a couple a day, unless you want to go insane!) This allows you to cover up to twenty candidates if necessary.

Each phone screen should last from 30 minutes to an hour. This is a feeling-out process for both of us. I try to give the candidate all the negatives up front and give them the opportunity to beg off. Most don’t. I ask a number of conceptual questions, mostly design or process related. I look for the ability to carry a technical conversation. Does the candidate have knowledge of significant development concepts (patterns, OO, unit testing, etc.) that is commensurate with their claimed experience?

For a while, I would ask technical questions over the phone. It’s awkward, not very effective, and ultimately frustrating. I brought in a few people for face-to-face interviews; these people ended up being good at answering technical questions over the phone but had little additional value.

Recently I began a practice of sending out an email challenge to each candidate that I was still interested in. The email has two parts. The first part is a number of simple questions and answers regarding the language of choice (Java here). Answers to these few simple questions can reveal a lot about the core knowledge of each candidate. You’d be surprised, for example, how many candidates have a tough time explaining the difference between .equals and ==. Even with Google at their disposal!

For the second part, I grab a prototypical sludge method from the system. The candidate’s job is to figure out what the messy code does. They can define a contract for the method, write a unit test, add comments, or do whatever they choose. I also suggest they rewrite the method. The nice part is that they can cheat as much as they want–they still have to be the ultimate arbiter of what is quality code.

I give the candidate two days to return the email. From there, it’s a dialogue. I challenge the candidate as to their answers and as to why they coded things a certain way. A candidate might get a number of questions wrong, or have questionable programming style, but that doesn’t preclude them from further consideration. I look for their ability to think, to justify their answers, to perhaps open their mind up to different ways of looking at things. I bring in candidates for face-to-face interviews based upon the results of this dialogue.

I used this technique many years ago when doing a slew of interviews. It worked well then, and it still works well now. One other benefit is that it gives candidates an opportunity to shine if their phone chat didn’t go so well. And most candidates actually enjoy it, since most good developers are geeks who like a challenge.

The email challenge also does a good job of ferreting out the troublemakers. One recent candidate (I’ll call him Joe Blow) interviewed for a lead developer/architect position on the team. All went well on the phone. But answers in Joe’s email response were commensurate with a mid-level developer. A couple of answers to the Java questions were dead wrong: Joe demonstrated complete misunderstanding of the difference between instanceof and getClass(), for example. The code he sent back was pretty confusing in one spot, and only adequate elsewhere. Further, Joe hadn’t bothered to compile it, which I had explicitly required per the instructions. I pointed out the incorrect answers, as well as the code issues, including items for which there is no “right” answer, just opinion.

All of the other candidates were able to cope with me picking at their code. Some of them challenged me back–good!–or acknowledged that they could have done things differently, and why or why not it might be a good idea to do so. Unfortunately, Joe Blow couldn’t handle the fact that someone might actually see things a different way. He ended up withdrawing from consideration for the position immediately after providing his very defensive responses. Apparently he couldn’t take the heat. He wrote a lengthy email to his recruiter, and also accused me of looking for people who coded in a specific Java “dialect.”

Touchy and perhaps even whiny: this is not the kind of candidate you want for your lead developer! Still, I learned from the process. I added a few more disclaimers to my comments (“these are not intended to suggest there is one right answer,” for example) and tried to show a bit more compassion in my already-sensitive answers.

Ultimately, when you’re looking for a developer, you want to know if they can write maintainable code. Asking technical questions rarely gives you the answer. The only way to find out is to get them to write some code. Sitting and pairing in a live interview accomplishes this effectively. But if you want to save the time and expense of bringing in candidates for face-to-face interviews, the email challenge is a great tool.

Old Age

I recently turned 40. I don’t feel a day over 20, at least from my mentality. Sure, I’m a cranky curmudgeon, but I think I’ve always been that way. In fact, I think I’m far more mellow now.

Some people are 40 the day they turn 20. And they stay that way. So certain of their viewpoints and knowledge, anything else someone suggests to them is a quickly-dismissed challenge.

If there’s one thing that’s most frustrating about the software development industry, it’s that there are so many people that just “know everything.” The mentality needed to build software often suits a sharp, independent, but stubborn mind. Once something works for them, no matter how well it works, developers often have a tough time accepting the fact that something else could work equally as well or better.

Building a successful software team is about finding the right mix of people, and the people with the right attitude. If the team members learn to question themselves as often as they question each other, you’ll probably be fine. If you have “questioning strata,” success will be difficult–it’s hard to get the self-assured down from that upper rock.

When hiring, get rid of your three-and-four-letter acronym laundry lists. Instead, you’re looking for an equal balance of smarts and humility. As far as the “smarts” side of things, check out Joel on Software’s “The Guerilla Guide to Interviewing” for some interesting ideas on how to interview candidates.

As far as the humility measure? It’s tough to ferret it out in an interview, for the goal of an interviewee is to promote self-confidence and success. I like to first ask questions about the things that people enjoy doing, and what gets them riled up. Try pushing a few buttons–it’s not too hard to get the superego to emerge. But the best way to find out is to sit down and try solving a few coding or design problems together. See how enthusiastic your candidate is about explaining things to you. The more important thing than them knowing everything is for them to be able to patiently explain the things they do know.

“You can’t teach an old dog new tricks” is an absolutely true phrase–just remember that old dogs often come in new stripes.