Issue 7 - Stories, Fences, and Doing instead of Learning

Happy Summer, folks. I'm excited to share this issue with you because it covers three areas I think are important for career development and growth. I'm looking forward to hearing what you think.

Let's start with some interview prep.

Create Five Stories to Prep for Your Next Behavioral Interview

I've been conducting a lot of interviews as I look to fill a very specialized role on my team, and so interview techniques are on my mind. I wanted to share with you how I prepare for behavioral interviews and how I coach others to do so.

A behavior interview, sometimes also called a situational interview, is where your interviewer asks you questions about how you work with others or how you respond to certain situations. They're looking for you to talk about conflicts, stressful situations, how you dealt with pressure, and how you handled feedback. They're trying to see how you'll work together.

To prepare for these kinds of interviews, you'll want to have specific stories to share, and you'll want to use the STAR technique:

• Situation: Describe the situation. Set up the story.

• Task: Describe the responsibility you had in that situation.

• Action: Explain what you did to complete the task, or if you didn't complete it, explain how you tried.

• Result: Explain the outcome and how it connects to you. Explain what you learned and emphasize what you accomplished.

Many people I interview are great at explaining the situation, task, and action, but they don't share the result. That's unfortunate because that's their chance to shine. Don't let this happen to you!

I've noticed that you can prepare for almost any behavioral question if you create stories for a handful of situations. Here they are, in no particular order:

When you did an amazing thing at work and received recognition.

Think about something you did that was impressive enough to get noticed not just by a manager but also by your team. This is a chance for you to talk about times you showed initiative, leadership, good judgment, and just generally getting stuff done. Give the background, explain what you did, and talk about the result.

When you dealt with a difficult coworker.

We've all had situations where we've had to deal with difficult people. Conflict is part of work. Even when people are working toward common goals, the approaches each person might want to take won't align. Some people are better at collaborating than others. Your future manager knows this is going to happen, so be sure you're able to tell a story that explains when you've had these situations and how you moved past them. This is one of the most important questions you'll want to be able to answer with a solid resolution.

When you were under a lot of pressure.

Jobs are stressful, and work can pile up. Have a good story that shows how you prioritize things and deal with high-pressure situations. Think about how you handle multiple projects and high-stakes meetings. And again, make sure you nail that resolution.

When you had to take charge of something.

Think about that time when a project went off track, and you brought it back from the edge. Or that time when you volunteered to take something on when nobody else would. Show how you steered it to a successful conclusion.

When you failed at work or received feedback on where you could improve.

Questions around failures, shortcomings, or mistakes are the ones everyone worries about the most because it's hard to talk about our failures. That's why it's so important to prepare this story well. Like the others, talk about the results, and emphasize how you've improved because of the situation. Show how you learn from feedback.

If you have these five stories you can share, you'll be ready to answer those behavioral questions with confidence.

That Fence is There for a Reason

When you come into a new situation, you will find constraints, best practices, and various rules in place. You don't always have the context for those rules, but the rules are there. Sometimes those rules or processes might slow you down, and you might be tempted to work around them or advocate to get them changed. It's dangerous to do so without careful consideration.

One of my favorite things to point out is that every warning sign exists because someone did the thing the sign says not to do, including the one by the hotel hot tub that says "No Diving." Of course you shouldn't dive into a hot tub. But the sign exists because someone did it and got injured. The sign is a reaction to something that happened. The sign exists for a reason.

Many processes you'll encounter are there for that reason as well. Someone did something that broke production. Someone made a business decision, and now things are structured a certain way. And like everything else, there's a name for this: Chesterton's Fence.

G. K. Chesterton's 1929 book, The Thing, uses an example of a person who sees a fence and wants to remove it, not understanding why the fence was there. Before removing the fence, they need to discover why someone put it up first, or they could end up making things worse. The lesson is as follows:

Do not remove a fence until you know why it was put up in the first place.

Chesterton explains that fences don't just pop up for no reason. People build them intentionally in response to a real or perceived reason. The reason might not be a good one or even a relevant one, but before you tear down the fence, be aware of why the fence exists.

You won't know whether or not you need that fence if you don't take the time to figure out why it's there.

Before you go ripping out pieces of code, restructuring that codebase, or overhauling an entire process, do the critical work of understanding why things are the way they are. This goes double if you're new to a team. You don't want to be "that person" that shows up and tells your new team how they're doing everything wrong. The act of questioning and seeking to understand will be worth the effort for both you and your team. You might discover that the "fence" isn't necessary anymore because other things have changed, or you'll determine that you need it more than ever.

Tear the fence down once you and others are sure you no longer need it.

"Doing" rather than "learning to do"

One of the most important lessons I learned from my teaching mentors is that there is such a strong motivational difference between:

You will learn how to x

and

You will x

Try it. Look at any course, article, tutorial, or conference talk abstract containing the phrase "learn how to" and remove it. You'll find the pitch is stronger without it.

Here's an example. Consider this::

"In this workshop, you will learn how to build a full stack web app."

It's a fairly common thing I see in article and book drafts. The author's letting you know what will happen, but they're focusing on the fact that you'll learn something. The focus is on the act of learning rather than the new skill.

But if you strike the phrase, you get something more motivating:

"In this workshop, you will develop a full stack app."

This is a tiny but powerful change when it comes to motivating your learners. Instead of focusing on the process, this makes the outcome clear. If they follow this tutorial, they'll have built something, and they'll be more excited.

Many course designers use Bloom's Taxonomy verbs to define the outcomes for their courses. Without going into too much detail, the taxonomy is a way to express how people progress through the learning process in stages:

• Remembering

• Understanding

• Applying

• Analyzing

• Evaluating

• Creating

One way to use Bloom's Taxonomy to define outcomes is to choose verbs from the "Applying," "Analyzing," "Evaluating," or "Creating" levels of the taxonomy, as those levels deal with higher-order thinking skills. The first two, "Remembering" and "Understanding," are lower-order thinking skills that eventually lead toward higher-order thinking.

A person who can remember facts, define terms, and classify things has a good foundation, but learning about a thing is not the same as doing the thing. And when you're creating technical tutorials, your ultimate goal is to show them how to do a new thing, so share that with them and get them excited about what they will be able to do.

I love this 21st-century verbs list, and I use it when planning my learning material.

You can make a huge impact and create more motivating content if you start thinking about how you can tell your learners what they'll do when they're done rather than what they will have learned.

Parting Thoughts

I hope this issue helped you think about how you'll present yourself at your next interview, in your dealings with others as you look at existing systems, and when you write your next tutorial. Here are some other things to consider:

1. Take some time to construct your own stories to prepare for your interview. Then see if you can answer the following questions using your stories. Be sure to use that STAR technique. Your interviewer won't always prompt you to talk about how things turned out, but you absolutely should do so:

   • Tell me about a time when you disagreed with a coworker.

   • Tell me about a situation where you had too many things on your plate. How did you prioritize things?

   • Tell me about a time you led a successful project.

2. What's a best practice you follow but disagree with? What is it about the approach that bugs you? How will you go about changing it?

3. Look at the 21st-century verbs list article and see if you can incorporate them into the next piece of content you create to create a more motivating experience.

That's it for this time. Thanks for sharing a little of your time with me each month. If someone you know would find this helpful, send this to them and tell them to subscribe.

Share

I'd love to talk with you about this newsletter on Mastodon, Twitter, or LinkedIn. Let's connect!

Please support this newsletter and my work by encouraging others to subscribe or by buying a friend a copy of Exercises for Programmers, Small, Sharp Software Tools, or any of my other books.