If you provide your login credentials, your private Facebook pages are no longer private, are they?

I have a difficult time understanding why an interviewer wants this information. Is the interviewer’s interviewing skills so insufficient they need to investigate you the backdoor way?

Is the interviewer looking for something nefarious? Or sophomoric?

Part of me is wondering about anyone’s expectation of privacy on the internet. If our banks can’t keep our passwords and accounts safe, why should we believe that our Facebook pages should be safe? But that’s about hacking into the banks, not handing over passwords. I don’t provide my potential employer my bank information. That’s only for actual employers

Employers, remember that an interview goes both ways. Do you realize you are saying to candidates, “Abandon all hope of privacy, ye who enter here”? What will happen after people start to work here?

I might look for cameras in the bathrooms. This feels sleazy to me. And wrong.

Employers, there is plenty of information that is not behind a locked door that you can obtain about a candidate. Ask good behavior-description questions. Learn how to create auditions and use them. Don’t be lazy just because it’s an employer’s market.

At some point, the economy will pick up. You might even be looking for a job. These people will remember you, and it won’t be fondly.

1. Let the behavior-description questions sell the candidate on the company. Don’t try to “sell” the candidate on the company or the people. It sounds like a used car salesperson or a bad blind date. It leaves a bad taste in the candidate’s mouth. (Yes, those are two different links.)
2. Organize the interviews with a matrix, so that everyone knows who is asking which questions.
3. Ask questions that relate to the job. Forget the riddles and puzzles that have nothing to do with the job.
4. Do add auditions to the question mix, so you can see a candidate at work. I like 10-15 minute auditions as a first step.

A friend sent me this hysterical article yesterday, A Most Wonderful Opportunity, Multiple Frustrations, and More. I did not roll on the floor, but I did laugh out loud. I loved the Mt Fuji answer. If I could have answered that question with a straight face, that’s how I would have loved to answer it. Of course, I would have just rolled my eyes so much, I don’t think I could have.

Well, I’ve had a chance to think about this for a while and I have some ideas. Here are some behavior-description questions you might want to ask to determine if someone has had lean experience, or experience limiting work in progress:

• “Tell me about a time you realized you were working on too many things at one time. How did you realize it?” (Pause and wait for the answer.) “Was there a board or some other visualization mechanism?” (Pause.) “Was it a solo effort or part of a team?” … “What did you do?”
• “Have you worked on a team using kanban?” (Use a closed question to establish the experience.) “Tell me about a time you realized your team was having trouble staying inside your WIP (work in progress) limits.” Another question could be, “Looking back, did your WIP limits tell you anything about how the team worked?” (Pause.) “What was it? What did you/the team do about it?”
• “Have you worked on a team using a story board for their iteration?” (Use a closed question. A story board is a mechanism to limit WIP, but teams don’t always use it that way.) “What happened when you used the board?” or “What did the board tell you about the way the team worked?”

Don’t use these questions as a script, but as a guide to a conversation.

If those questions are too high level, bring them down a notch or two by asking more specific questions such as, “How many stories were open at the same time and how many team members did you have?” If the candidate worked on a team of 5 and they had 5 stories open (or more!) chances are good they were not respecting WIP limits. But you don’t have to take my word for it, you can ask. That’s the value of behavior-description questions in an interview.

Matthias, thanks for making me think about lean teams, specifically!

A poster said,

We didn’t try to pair with the whole team during the interview – just one person with perhaps 2 others observing.  Our general interview was 45-60 minutes of question discussion of topics with 2 – 3 people & candidate.  Then about 45 – 60 min. of pair coding exercise.

Issue 1: Auditions. Pairing, as long as you pair at work, is a great audition. If you do not pair at work, it’s a terrible audition. Why? Because it sets the candidate’s expectation that you do pair at work. Then, if the candidate gets to work, and you do not pair, you have disappointed the candidate on the first day. Why do that??

I assume these folks did pair at work. For those of you who do not pair at work, develop your own audition. I have many audition examples on this blog. Search for auditions and use them as idea generators for your position.

Issue #2: Observers. I did not get to ask the original poster any questions, so I don’t know the context. But for those of you who think that 45-60 minutes of questions with 2-3 people is a good thing—nope, I disagree. If I’m the candidate, I can control the room, because I’m great at interviewing. That’s all, just great at interviewing. And, that wastes the time of the observers.

Remember, the best interviews are conversations. So have a conversation—a one-on-one conversation. Use an interview matrix, with each interview focused on just two areas, letting the conversation flow with behavior-description questions.

Now, you have 45 minutes of experience with the candidate yourself. And your two other colleagues also have 45 minutes of experience, so you have three times 45 minutes of experience with the candidate, not just 45 minutes of experience with the candidate. You can compare notes about the candidate and see if the candidate said something different to each of you, or said the same thing three times. You don’t get that kind of data when you have the same interview.

Issue #3. Learning from the Interview. No matter what I like about your interviewing or not, you need to learn from your interviews. Have you set up a way to learn from your interviews?

In a phone screen, you first want to ask elimination questions; then essential technical skills, qualities, preferences; essential non-technical skills; then issues that could pose a problem with interviewing or offer activities.

Okay, so what does that look like?

I write a template for each position, so I can take notes. I leave space for each candidate’s name, the date of the call, the time, all those details. Why? Because if it’s late, and I’m tired, I want to know if I’ve screwed up my notes.

Assuming you’ve done a job analysis first, you have the pieces of the phone screen. The hardest part will be keeping the entire phone screen to no more than 45 minutes.

Think about the elimination factors. Are you willing to offer relocation? Do you really need people with a degree? How about a maximum salary level? I’m a big fan of discussing salary earlier rather than later. Junior people have lower salary expectations than more senior people, so salary should be less of an issue than other positions.

A plea to hiring managers: Please do not look for specific tools or languages or years and years of experience in your junior folks. Please be willing to train your junior staff. You will buy their loyalty for a very low cost. And you will learn if they are smart and can learn quickly.

Okay, once you’ve moved past the elimination factors, which should last no more than 5-10 minutes of the phone screen, you can move the essential technical skills, preferences, and qualities and essential non-technical skills. Are you looking for people who are highly collaborative? What about the ability to finish things? Learn quickly? Take small steps? Oriented towards a goal? Able to design as part of a team? Work as part of a team? Work alone? Something else? I don’t know what’s essential for you. Only ask about what’s essential. Have 3-5 behavior-description questions about these essentials on your phone screen, and feel free to use the questions as a start of a conversation, continuing to take notes.

You may be worried about how to ask behavior-description questions of junior folks. I wrote an article about that. See Interviewing New College Grads.

After you’ve discussed the essential technical and non-technical skills, go on to the issues that could pose a problem with interviewing or offer activities. Is the candidate still in school, and have limited time for interviewing? Are you in another city or state, so you need to bring the candidate in for interviewing? Is the candidate committed to complete a project for another month or two?

That’s how you create a phone screen. It’s not hard, and it takes just a little thinking and preparation.

Here’s what the interview matrix looks like:

Everyone has a chance to ask different questions about two different areas, leading to different conversations. Because two people ask questions about the same area, you get overlap, but not the same conversation. When Sally and Tom ask about problem solving, they both ask about it, but with a different focus, because their other areas are different.

The everyone column on the right is for everyone to meet at the end of the interview to share their ideas about the candidate.

I suspect you’re already doing something like this, but if not, make it explicit. You can even provide the candidate a copy of this sheet–at least the upper part with the people and the times, so the candidate remembers who he or she spoke with when.

For any candidate, manager or not, consider these questions:

• “Tell me about a time you felt well rewarded for work.” Listen very carefully here. People may not discuss money at all.
• “Tell me about a time you  thought you had done a great job, but no one recognized it.” Be careful about how you ask this question, because you don’t want people to blame others, but you do want to know what they think was rewardable.
• “Give me an example of a time you were rewarded for great work, and a time you were recognized for great work. What was the difference and what did it mean to you?” Feel free to separate these into multiple questions.

In addition, consider these questions for managers or leads:

• “Give me an example of how you have rewarded people in the past that worked.” (Listen for the story, then ask this question if it’s not part of the story.) “How do you know it worked?”
• “Have you rewarded people in the past and you think it didn’t work? What happened?”
• “Have you ever been in a position to reward people differently for similar work? What happened?”

Read this post with the other two: Interviewing for Culture, How People Treat Each Other, and Interviewing for Culture, What’s Discussable and What’s Not, and you’ll have a great basis for understanding someone’s cultural preferences.

I like to ask questions such as, “Give me an example of a time people were in conflict. How did the conversation go?” or “Tell me about a time the team members were happy about something. What was it and how did they express their happiness?”

I also like to ask questions such as these: “How do you discuss options for the project (or testing or development or whatever)?” Discussing options, or not discussing them may reveal a lot about how people treat each other. Some teams have hierarchical discussions–they wait for the senior person to say something and then the rest of the team members can chime in. I see this a lot in senior management teams. Some teams disparage team members when they say something unexpected; some teams like the different point of view.

Considering how people treat each other is a piece of culture, and there are many ways for people to treat each other that work. What’s key is seeing how comfortable you are with how the team members treat each other.

In my recent talks about management, I talk about cultural fit. One piece of cultural fit is knowing what you can discuss and not discuss. When you interview people, especially managers, you can’t ask, “What do you discuss or not discuss?” (Well, you can, but it’s not a helpful question.)

Instead, ask questions such as, “Give me an example of information do you normally discuss with your team? With your peers? With your managers? Why?” (Make them all separate questions.) Follow up with “Give me an example of a time you had information you wanted to share but couldn’t (at each level). Why?”

The problem with culture is that it’s totally context-dependent. What is ethically and reasonably acceptable to share in some organizations is not ethical in others. You need to see where people start and where they are affected by their organization. That’s why you need to ask the why questions.

These are opening questions, not the end of the conversation. Especially for managers, you want to ask questions about how they manage. And, if you know their starting place for what they can discuss and what they can’t, you can have a better conversation.

• Pseudo-code that shows how you solved a problem as a developer
• Description of an automated test framework or pseudo-code that shows the interviewer how you put the framework together
• Description of a project schedule, explaining the iterative and/or incremental parts
• Description of a project and what it was that made that project agile (or not)

If you are worried about sharing code or asking for code, it doesn’t have to be real code. And, notice that all of these items can be considered auditions of a sort.

Many years ago (more than 20), I wrote an FFT multiply loop on an embedded processor. If I had to describe that now, I would explain it this way:

• The inner multiply loop had 7 or 8 steps. I can no longer remember.
• During the steps, I loaded a different accumulator to perform some other computation, and then created another loop for the next few steps, testing for done for that computation along the way
• The issues I had to deal with were:
  • What if I finished the other computation first? What happened then?
  • What if I finished the multiply first? What happened then?
  • How did I know the multiply was faster?

I no longer remember the answers to any of these questions, but I do remember asking them. At the time, I didn’t need the real code for that code snippet (or description). But explaining why I felt proud of that code and how I knew and resolved the issues was helpful in my next job interview.

So, yes, be careful about asking for real code or real tests or a real Gantt chart (or any other project artifact). But you can certainly ask for pseudo-code or the thinking behind code (or whatever artifact you want).

Asking for evidence of the thinking behind a real problem the candidate encountered at work is an audition. Asking for something the candidate feels strongly about helps a candidate retrospect.