Thoughts on Take Home Interviews

There is a movement now in tech to really think about what it would take to improve our interview process. This is a movement a long time coming. White board coding interviews are clearly a strange way to measure a person's ability to actually do the day to day work of a modern software engineer. And we know that we tend to have a lot of bias in our interview processes that takes what we wish were an objective evaluation of skills and turns it into something very, very subjective.

Recently, my friend Julia Grace wrote about the interview process at Slack, to grant more transparency into what it takes to become an engineer at one of the hottest companies around. While this is a recruiting tactic it's also great that they are helping people understand what to expect and how to apply. Slack is taking pains to try to avoid bias, by having people complete a take-home technical exercise.

This varies by position, but generally you’ll have a week to complete a technical exercise and submit the code and working solution back to us.

Since we don’t do any whiteboard coding during the onsite interview, the technical exercise is one of the best ways we’ve found to evaluate programming competency.

The exercise is graded against a rigorous set of over 30 predetermined criteria. We’re looking for code that is clean, readable, performant, and maintainable. We put significant effort into developing these criteria to ensure that, regardless of who grades the exercise, the score is an accurate reflection of the quality of the work. We do this to limit bias. If there are clear criteria, variations that might impact score but have nothing to do with the candidate (such as if the grader is having a good day) are less likely to influence the outcome.

On twitter, a discussion ensued about whether asking people to spend time at home doing exercises didn't itself cause bias, against those who did not have a lot of spare time to be doing take-home exercises. Julia mentioned that they expect it to take 2-4 hours, but admitted that some people got really into the project and spent far longer than that.

This brings up three good questions that I want to address:

1) Are take-home exercises on the balance good?
2) Is it reasonable to expect people to spend 2-4 hours of their own time on a take-home exercise?
3) What about the people who will spend more time?

On the issue of 1, I think that yes, take-home exercises can help a lot to address the bias that happens when you know the person who wrote the code. They have the potential to be the blind audition step that the tech industry needs.

On the issue of 2, I actually ALSO think it is ok to ask candidates to spend a few hours on these exercises. This comes with two caveats. First, you should genuinely believe that the exercise can be done in the number of hours you expect by a candidate qualified for that level (so, measure how long candidates report spending on it). Second, these exercises only take "a few hours," not "tens of hours."

I feel ok, within bounds, to say that you should find a few hours to do a coding assignment, especially if it reduces the time you would need to spend onsite. The benefits of getting rid of whiteboard coding and that particular bit of evaluation bias outweigh the possible inconvenience. If you're looking for a job, you have to budget time to interview. So take half a day off if you can to do this project. Just because the exercise says take home doesn't mean you actually have to do it in your off hours. If you're unable to take time off of work to interview at all, unfortunately, you're going to have a problem getting a new job anywhere.

Which brings us to issue 3, what about the people who will spend more time? This is the most interesting part.

Julia said that candidates get really into solving the problem, and spend more time on it because they're excited about what they're building. That is awesome, but it also makes my blood run cold. At this point you're talking about something that is both a test of your programming abilities but also a creative project. Let's contrast that to the description that Foursquare gives of their take-home portion:

Instead we give out a take-home exercise that takes about three hours. The exercise consists of three questions:

1. A single-function coding question

2. A slightly more complicated coding question that involves creating a data structure

3. A short design doc (less than a page) on how to implement a specific service and its endpoints.

Every question we use is based on a real problem we’ve had to solve and has a preamble explaining the reason we need to solve this problem. If there is an obvious solution with a poor running time we mention it since we can’t help course-correct when the work isn’t being done live. We also provide scaffolding for the coding questions to save the candidate time.

This appears to be designed as an exercise that will only require a lot more time if you are struggling with the solution. Sure you can go nuts creating a crazy creative data structure or design doc, but this is a pretty clinical test. There's few places to add bells and whistles and they're unlikely to get you any brownie points with the interviewers.

These are two processes with the same goal, to reduce bias in our interviewing process, but slightly different tactics in the take-home. I would guess that Slack's take-home is fun and appealing to a set of people, those who enjoy tinkering or creating cool new projects. And it will find those people and make them shine, and probably serve as a good bit of recruiting to make them even more excited about the possibility of working there.

But I can tell you that for someone like me, I would hate being given the "creative" take-home coding problem. I'm happy to write some code to show you that I can. But I don't like to tinker, and I prefer that my creative work be collaborative. It feels like you are wasting my time and instead of making me more excited, it makes me far less excited.

The creative take-home also seems likely to select for those with free time, because if it is really an exercise that some people want to overdo, they will overdo it and you will have a hard time not rewarding that enthusiasm (why shouldn't you!). And while it's ok to ask for a few hours, building something that rewards those who can spend far longer is likely to bias against those who have, say, kids to take care of after work and on weekends, or other activities that limit their free time.

On the other hand, Foursquare's test is the first take-home I ever read about where I thought, "yes, that I would do." It is respectful of my time, and gives me something constrained to complete. We can elaborate on creative topics in the in-person interview, I do much of my best creative thinking with other people, elaborating on ideas together. Of course, I am a strong in-person communicator, and having a process that pushes the creativity into the in-person interaction interviews selects for people like me.

In the end, you probably want to hire a spectrum of people. When thinking about how to design your take-home tests, make sure that you are being considerate of the candidate's time, and decide if you really need this test to be a test of both technical skills and creativity, or merely a screening for technical skills. It may be that different roles need different screenings, and you may even want to offer both! That's a lot to ask for, but no one ever said that fixing hiring was going to be easy.

Ask the CTO: Getting Information without interruptions

This is reposted from my Ask the CTO series on O'Reilly

The problem: I don’t know how to figure out what’s happening on my teams without asking people directly, and it’s driving them crazy!

I am in charge of a team that is running a big, critical project. My boss is breathing down my neck at all times, asking me for status updates, wondering when different pieces are going to be done. Usually, I know what is happening because I’m doing some of the work myself, so I can give the answers because I’m deeply involved in the project. This time, however, I’m not actually doing any of the work, and I don’t even have the time to attend every planning meeting and standup. When my boss asks me for status updates, I feel that I have no choice but to ask a member of the team.

Of course, there’s also the outages. Did I mention that this big project is to replace a system that is crumbling and causing incidents all the time? So, if I’m not asking about project status, I’m trying to figure out why we’re down, what the status of the incident is, if there’s anything I can help with.

I just got some feedback from the tech lead: I’m driving the team crazy with my one-off questions. They complain that I’m distracting them, interrupting their work, and derailing other important discussions to get status updates. I don’t want to do that, but I don’t know how to figure out what’s going on without tapping someone on the shoulder to ask. What do I do?

The solution: Know where to look

When you are embedded in the team you are leading, the details of their projects are the air you breathe. But add on more teams or a level of management and all of those details provide hard to discover. How do you get the status of projects when you are a step or two removed? How do you figure out what is going on without constantly tapping an engineer on the shoulder and asking her for a status update?

To begin with, you have to know where to look. If it is important that you know the status for projects at the drop of a hat, then you should learn how to read the project management dashboards the team is using. If the teams are not using task tracking and project management software, at this point I must ask, why not? It is one thing to avoid the overhead of formal task tracking in a very small group. However, as the team grows, you need to have transparency into progress. This means that you need a sense of what the tasks that make up “progress” look like, which requires some sort of breakdown and tracking, even if it is in the form of sticky notes on the wall.

This also goes for your production incidents. What is your incident management process? Are incidents managed via chatroom, or by people sitting in the office together? Do you have a postmortem process? If ongoing incidents don’t have a communication process and structure, it might be time to throw something together.

Knowing where to look is the first element, one that managers often skip over too quickly. You owe it to your team to look at the existing tracking software and look for the status there first, before firing off questions directly to the engineers. However, looking through the project tickets and work-in-flight status does not always provide the full picture. Sometimes the person managing the project tracking is themselves a bit disorganized. Sometimes the details that you are concerned with are not represented, or not represented well. Then what do you do?

Practical advice: Manage up, read the room, and let the team lead

Let’s break down this situation further, because “then what” really depends on the time and the urgency, and the reasons behind your question.

Scenario 1: You’re asking because your boss asked about the project and you didn’t have a great answer.

That’s fine! But does your boss need more details this second? Or can you ask the team for details in the context of scheduled meetings or via less-urgent communication channels (email or chat)? Usually when the boss asks us something, that makes us want to jump quickly. What we really need to do is just make a note to get more information and then get it when the time is right. This requires some managing up. Predict the questions that your boss tends to ask, and have some general answers prepared. That will give you some ammunition to use as you push back for time to get details on specific concerns. And you will need to push back occasionally. The worst outcome is having your boss go directly to the team themselves and ask for a status update.

Open office plans provide the most tempting setup for interrupting people. Picture: you have a question you’re itching to get an answer for, the manager of the team is in a meeting that you can’t interrupt, but there’s one of the engineers sitting there typing away. The temptation to tap him on the shoulder and ask can be overwhelming. I know it is for me. If you’re going to do this, for goodness sakes, respect the signals. Is this person wearing headphones and look really focused? Or is he chatting, walking around, or otherwise out of the zone? Be sensitive about your impatience versus their focus, and apologize when you are forced to interrupt their work. Apologies don’t cure all evils, but making an effort here is important.

Scenario 2: You’re asking because launch of this work is imminent, or this work relates to an immediate production issue and you need nuanced details that only a developer can provide.

In this case, you may very well need to interrupt someone and reading the room will be essential. There are times when managers, for whatever reason, are themselves either occupied with something else or don’t understand the nuance of the situation you are concerned with, e.g., a release is at-risk and you don’t know why. Sometimes, asking the developers for details will tease out decisions that could change a release from “late” to “on-time minus a non-essential feature.” The goal is to do this very sparingly, and use it as a teaching opportunity instead of a chance to undermine.

In the book Turn the Ship Around (an essential leadership text for engineering teams that I've recommended several times already), the authors spend a lot of time discussing how to resist taking the wheel every time a small problem happens and thus undermining the leadership and ownership of the members of the team. The way you choose to ask for details in the moment can make the difference between encouraging leadership from the team and enabling learned helplessness that causes the team to be paralyzed without you around. Instead of barking orders in a production outage or telling people to cut features close to a launch, practice using these situations to ask them what they intend to do. Asking what they intend to do puts the ball in their court, and forces them to practice taking leadership of the situation. You want the whole team, not just the tech lead or manager, to feel capable of speaking up and sharing leadership for resolving these situations. Use this direct interaction to push that team-driven leadership and encourage the team to be in charge of situations instead of victims of them.

Scenario 3: You’re asking because an idea occurred to you, you just heard of another team doing a related task, or you have an unspecified concern about the project and knowing more details will help clarify.

Getting details from the developers directly is often useful when you have an intuition nagging about a project. Again, the trick here is to do it without interrupting a developer who is in the middle of flow. Unfortunately, you’re the boss. Even if you try to communicate via non-urgent channels like chat or email, often the person will notice and drop everything. Some situational awareness helps. If you work in the office with them, try to wait until they are getting up from their desk, going to lunch or coffee, or notice when they are out of the zone. If they’re not in the office with you, encourage them to make active use of chat status to indicate when they can be bothered or not, or make it clear at the outset of your chat or email that the topic not urgent but you would like to get some details later.

Have you heard of “swoop and poop management?” It describes what happens when a manager or other senior party unfamiliar with the details drops by the team, makes a suggestion for something the team should look at, and then leaves. Swooping down, pooping out an idea or comment, and flying away without seeing the effect of the interaction is, at best, a distraction or annoyance and, at worst, causes people to start focusing on a causal idea instead of the important tasks at hand because The Big Boss said so.

In all of these situations, you want to defer to the team’s immediate manager, tech lead, or product manager as it makes sense. Going directly to the team should be an occasional event, not a regular occurrence. It’s not that you can’t have a relationship with the team directly, but it is the job of the tech lead or manager to manage and communicate project status specifically so that the engineers can focus. When you do choose to go to the team, do it productively and positively. Use it to share ideas with the developers, help them grow as leaders, and affirm your connection with them in a productive way.

Find more of my columns here!

Ask the CTO: Navigating the hands-on to hands-off transition

I'm writing a new series for managers on oreilly.com. Here is a teaser for my first post!
The problem: I’m a new manager and I’m overwhelmed

A few months ago, I was given the opportunity to run a new team in a growing area of my organization. The company thought I was ready for a bigger leadership role, and I agreed. I think I have a good track record that prepared me well for this: I've been a successful tech lead, had a couple of direct reports, and created some great software. I was excited to grab this chance to lead a large team and set the technical direction for part of the business, so I gladly took the job.

But lately, I've begun to realize that instead of having a few hours of meetings a week, more than half of my time is booked before the week begins. I have regular 1-1s, touchbases with peers across tech, and meetings with the product team for planning, interviews, and strategy sessions, and the list goes on. I was excited to write some code for the new systems my team is building, and I've tried to, but the only time I can find is in the mornings before everyone arrives, or at night after I've eaten dinner. I'm totally stressed out trying to balance all of this, and my team is starting to complain that I am canceling my meetings so I can have more time to code. So, my question is: how do I learn to balance my days so I have time for all these meetings and management tasks, but also time to write code?

The solution: Think of management as real work

Let me ask you a question, before I begin. Do you believe that management is real work? Do you believe it is work that is just as valuable as coding, architecture, and other hands-on technical tasks?

We start with that because if you do not think that management is real work, you will continue to treat it like an unfortunate burden to be dealt with so you can get to the fun stuff. Which, sadly, is the attitude that many managers in tech seem to take. I say that this is sad because it causes not only suffering on the part of the manager, but a lot of damage to the team as well. Your team needs you to be there as a manager for them, and it is almost impossible to show up fully for a role that you don't think is valuable. Management is work, and it is important that you put your management priorities front and center.

Great managers know that their value comes from the ways in which they create functioning teams, focused on the right work. When you can do that job well, you will almost always create greater value to the organization than you would as an engineer; yes, even a 10X engineer. If you shortchange your role as manager by fighting for code to write and technical work to deliver, it's likely that you will end up, at best, totally stressed out, and at worst, slowing down your team.

Sometimes we managers feel that we have to keep writing code because otherwise things won't get done. However, if your team isn't getting enough work done, your job is not to do the work yourself. Your job as a manager is to figure out how to help the team get more done. It is incredibly hard to make the overall team stronger and spend half your time focused on doing the work yourself, especially when half your time is actually overtime. Yes, immersing yourself in the technical details may give you some insights into the day-to-day challenges of your team, but you can also get many of those insights by training your team to notice them, and helping your team know what to tell you.

Going hands-off is hard, even if you do value the work of management, because you no longer have a simple, easily measurable thing to look at. Experienced engineers get frequent strings of wins as they write code, fix bugs, and see new features come to life. The feedback loop as a manager is much, much slower. There's no red-green-refactor for guiding humans. It's okay to mourn the loss of that endorphin hit. You spent years getting good at the job of being an engineer, and now you have to do something that you probably aren't as good at yet. It will get better, but it will not be the same.

Answer continued with practical advice and more on oreilly.com

You can bring a horse to water...

Trying to Convince People to Change

I was talking to a friend who was frustrated with one of her engineers. This engineer had a tendency to fall into some bad habits when stressed out, and my friend had given him a book to read on the topic, but he hadn't bothered to read it. Why not read the book, which would shortcut all of these conversations and corrections my friend needed to make over and over?

Are you familiar with this story? I am, having lived it several times. I have given my team various books to read over the years. Some of those books include:

Creative Mission Critical Synergy For Leadership

Turn the Ship Around
Leadership and Self Deception
Making Things Happen
The Five Dysfunctions of a Team

I have even held reading groups for some of these, I wanted so much for my team to read them.

I love to read, and I have grown to love books in the "self-help/business/leadership" genre. These books have taught me a ton, heck, I blogged my defense of the repetitive business book because I find so much value in them. They're great!

However, getting value out of books like these is predicated on two important factors:

1) You have to actually read them
2) You have to read them with an open mind to learn from them

Asking my team to read books has had mixed results. The most successful book I tried to get folks to read was Turn the Ship Around. I read it with my leadership team, and we would discuss it in our team meetings. It is a book that is so deeply applicable to the practice of managing engineering teams that I think it was easy for my team to appreciate its value.

For most of the rest of the books, the people who were already interested in the topics read them, and the people who did not want to change what they were doing did not. Even when the doubters read them, they read them with a mind towards disagreeing with their message, and I'm not sure they got anything out of the books.

This is not a fun lesson, but it is an important one for anyone who is managing a team. You can't force people to want to change. You can give them information, books, classes, coaching, but if they don't see a need to change, none of that will help. So the first thing you have to do, before giving them books, is to really convince them that they need to change.

Ah, but this is tricky! Do they actually need to change? If they change, it will make your life easier. Will it make their life easier? 

Sometimes, we want people to change when in fact what needs to change is the situation we've put them in. If someone on your team is acting really negative, do they need to change their attitude? Or perhaps, do you need to move them to a team where they are not being ignored by their manager?

Before you look to change the people, make sure that the change that needs to happen isn't in fact something in the environment that you can control. 

Most people are going to behave in unhealthy ways when they are in unhealthy environments. Asking someone to change the way they react to stress is a tall order. Sure, it would probably be good for them to chill out, be nicer, stop blaming others for their problems, but I've been working on my unhealthy reactions to stress for years and I know I still have a long way to go. Even when people want to change, personal change doesn't happen overnight. It is usually easier for a manager to change the environment than it is to change a person's reaction to that environment.

Looking back to my successful reading suggestions, they have almost all come when people had control over their environment, and the book was about helping them drive change in the team. It is pretty rare that I've given an unhappy person a book for reacting better to unhappy circumstances and seen them embrace it.

Poor reactions to difficult situations can negatively impact the team and it's your job as a manager to help people identify these behavioral issues. Books can be great for this, but they are rarely going to shortcut the process of change. No matter what, don't forget to look at the circumstances that are triggering the behavior. It is unlikely that you'll coach your team to Buddha nature but you might be able to reduce the stress that is causing the problems in the first place, and that's a win for everyone.

Ask the CTO: The Angry Employee

Question:

A few days ago, we had a fairly impromptu team meeting to discuss a new initiative. My goal was to brainstorm some creative visual ideas with the designers, but I also invited the engineering team so that they could participate. One of my senior UX engineers, Dan, was out of the office, and so he dialed in to the meeting because we couldn't realistically wait for a few days and it didn't seem urgent that he attend in person.
We had the meeting, and one of the ideas seemed to touch on some of the things Dan really cared about. The designers were proposing something that in my mind was orthogonal to what he had been advocating, but he felt angry that others were encroaching on his turf. This culminated in a rant on team chat about the situation which upset several of the other teammates, and when I tried to message him about it privately (he was still out of the office) he got angrier and accused me of not supporting him and always siding with the design team over tech. What do I do?

Answer:

Well, there's a lot to unpack here. Seems like a few things that should have been minor issues (team meeting without everyone in the room, one person feeling that others were encroaching on their job) escalated quickly into some serious unhappiness.

Let's discuss what went well. Trying to address the issue of inappropriate venting on chat right after it happened was the right thing to do. Even though chat is not a great way to have difficult conversations, it is always good to provide immediate feedback when you see things happen that are not respectful of others in the workplace. Sometimes the person will apologize immediately, to you and the team. If this happens, you don't need to bring it up again but you do need to watch for it in the future. Unfortunately, this time it just escalated the situation, and instead of an apology you got blamed for creating the frustration in the first place.

The thing to do now is to get face time with Dan. You can take him to breakfast, lunch or coffee if being in a public place seems more neutral than doing it in a conference room or office, but it needs to happen quickly. Letting him cool down for a day before you address the issue again is OK and possibly even healthy, but it is not OK to let this hang out there for days.

Once you get him face-to-face, your job is to listen. Completely. Don't say anything except perhaps murmurs to indicate that you are listening and following along as he speaks. At the end, give him a period of silence to ensure that he is really, truly done saying what he needs to say. For many people, just listening will be the hardest part. But you gotta get comfortable holding silence even when you're bursting to comment.

Now that he's done, you are going to repeat back to him what his concerns are as best you can, and ask clarifying (vs leading) questions. Your goal here is to make sure you understand exactly where he is coming from, and he believes that you understand this. This is to stop yourself from telling stories about him. If you find yourself filling in gaps, "you are mad because you were not in the room because you're always taking days off whenever it suits you," for example, stop. No filling in gaps. No telling stories. No imagining motivations beyond what he has told you. Give him the chance to feel totally heard.

Only once he feels totally heard are you allowed to then offer your interpretation of the situation, and how it differs from his. Try to come at this with a new perspective given what you now understand of his experience. You may find, after hearing him out, that you did screw up and ignore his ideas. If this happened, admit it and apologize.

OK, cool, so you've heard him out, and stated your case. Now what?  First, if he has not yet apologized for the chat outburst, that needs to happen. It is not optional. Remind him that, as a senior person on the team, people look to him for leadership, and his behavior was not one of a leader. Beyond that, you need to start talking about why he trusts you and/or the team so little that he felt compelled to dial into a meeting that was really a courtesy invite, and why he thinks that others are stealing his ideas and getting credit that he is not getting. Because people rarely get angry and stay angry after a single minor incident. They get angry and stay angry because they've built up resentment about something over time. This is a strong warning signal to you that something is broken in your team. Even if this person is lost to you, identifying the trust gap on the team and working to repair it is essential for future stability.

A few final thoughts. We sometimes go overboard in trying to get everyone in the room for "brainstorms" and "idea sessions." Inevitably, as your team grows, people are out of the office or worse, you just simply cannot have every single person involved in these decisions. This often feels like a loss of control for early employees or senior folks who are, for whatever reason, excluded. Coming up with strategies that let people have effective idea meetings without having everyone in the room is essential. Remind everyone that ideas are just the barest first step. The path from "idea" to "implementation" usually twists the idea in ways you can't foresee, and there should be plenty of chances for people to help shape them into a better reality even if they miss the inception point.

You may want to triangulate with another person's observations of what happened in the meeting. If you decide to ask someone else about their impression, be careful not to lead them into a story you want to hear. Take the time again to listen instead of speaking yourself. Even if they agree with your assessment that Dan was out of line or tell you that you did nothing wrong, don't use it as a cudgel to bash Dan with. Be especially careful of WHO you ask to share their observations. If you are guilty of favoring designers over engineers and you ask another designer for their opinion, they may back you up, not seeing the problem. Another data point can be useful but it still does not actually paint a perfectly objective picture.

Finally, there's the possibility that you can't handle this alone, that the person is too upset to talk to you 1-1 and you need to involve a peer, superior, or someone from HR as a mediator. If that is the case, steel yourself for what will likely be an unpleasant meeting. Even if you smooth things over, it's going to take some serious apologizing on both sides and a concrete plan to work through the issues that led to this place.

Dealing with an angry team member is always touchy, but as with most difficulty situations, it gives you the opportunity to look at a bigger picture that you might have been missing, and think of strategies to address it. So don't panic, listen, and learn from the situation at hand.

In Defense of the Repetitive Business Book

Over a recent vacation, I finally read Mindset, by Carol Dweck. For those of you unfamiliar with the book, I'll recap quickly. Have you heard that you shouldn't praise your children for being smart, but instead praise them for working hard? That is probably the most popular trend coming out of this book, which discusses at length and in almost excruciating detail why a "growth mindset," that is, one that believes that people can get better at whatever they choose, that effort and exploration are the keys to success, is preferable to a "fixed mindset" that believes that you are as smart, athletic, musical, etc, at birth as you will ever be, and effort is secondary to your measure of natural talent.

Mindset is a deeply repetitive book. You are treated to story upon story upon story of the successful (and happy, and well-adjusted, and sustaining) person who exhibited the growth mindset. You're treated to many contrasting stories of the successful but less-than-they-could-have-been (and unhappy, and maladjusted, and burned out) person with the fixed mindset. You also get a good dose of research to back up the observations of the behaviors of people who both put themselves in various mindsets and people in experimental conditions who are put into the two mindsets. It ends with some situations that you might face, a parent with a fixed mindset child being one, and suggestions for how to approach them with a growth mindset.

I would absolutely recommend that you read it.

You may be surprised, given the faint praise I have given so far. It's repetitive, deeply so. If you get the concept, then, why read the book? You could probably get the gist with a blog post or short article, or maybe a TED talk. What's the value of a book on the topic, beyond lining the author's pockets?

I think that sometimes I fall victim to this fallacy that if I am familiar with the general outline of a concept, and I agree with the concept, that I understand this concept. I see this play out especially in non-technical topics. If I can roughly explain it to someone, I understand it, right? 

Of course, there is a huge separation between understanding a concept and putting it into action. Many of the concepts introduced in pop psychology or business books are pretty easy to understand. The problem is putting them into practice. Remembering to do them. Most people understand that the first step to losing weight for most people is to get more exercise and eat better, and yet, putting that simple practice into place is hard. It's hard because breaking habits is hard, forming new habits is hard. Changing the way you react to things is hard. 

Mindset is in some ways just a rehash of concepts of Buddhism. Let go of your notion of "self." Be open, relaxed, curious, willing to believe that you can grow. The only inevitability in this life is change, nothing is fixed. That means that, yes, success is ephemeral, but it also means that you are capable of changing, learning, and growing, all the time. Many leadership, pop psychology and business books end up sounding like a rediscovery of parts of the dharma. No one is surprised when you say that, as a philosophical, spiritual, or religious person, you are still learning the meaning of your particular path, and learning every day how to walk that path. It is no surprise that it takes a lifetime of study. So, too, does learning the concepts of leadership, creativity, interacting with fellow humans, and growth. Whether or not it is a spiritual path, it is not something that most of us find natural, and not something that will sink in with an article, or even a book. But it helps to get a prolonged exposure to the idea, to work through some of its nuance, to spend 5 hours with it instead of just 15 minutes.

So, read Mindset. Think about your own mindset. I can say that personally I have moved slowly from fixed mindset to growth mindset over the years. It has been hard. I still fall back in places to the fixed mindset. Why am I moving? Mostly because it's just more fun to grow. To learn new things. To believe that you can change. I kept meeting these people that seemed so light, so free, so creative, and they just seemed so willing to learn and fail and learn some more. Why not me? Why not all of us?

Framing

I had a realization, towards the end of my last job, about company values. What are company values (aka "Core Values")? Well, here are some examples: Zappos, Etsy, Facebook. My former company had 10:

1. Everyone deserves a Cinderella Experience

2. Dream big and go after it!

3. Make the most with what you have...scrappiness is a virtue

4. Debating, honest conversations and collaborating make the company stronger

5. Happiness and positivity is a choice

6. Embrace the RTR family and bring your authentic self into the office each day

7. Bring your best intentions to everything and trust that others do the same

8. Adapt and learn from everything you do

9. Roll up your sleeves and get involved. Everyone should be accessible and involved with the day to day elements of RTR

10.We are all founders of Rent The Runway

When I first started, I was skeptical about the purpose of Core Values. Zappos, the most famous advocate of this concept, seemed a bit weird. I am not a conformist, and I felt like expecting a diverse group of people to embrace the same set of values and beliefs was a bit Orwellian.

What changed my mind? As part of the company review process, we would ask people to mention ways in which their peers embraced the core values. One person might write, for example, "When Jane suggested we try this crazy experiment to increase the performance of our product page, she encouraged us to dream big and go after it." You weren't required to spell out how each person met every value, just give one or two instances where they had met them.

Is it a good idea to use values as part of the performance review process? Well, for better or worse, one of the things that indicates success within a company is how well a person is capable of working within the culture of that company. This can be a bad thing, when the culture of the company is confused with the color of the company, the gender of the company, the background of the people in the company. That is not a very specific culture, and it is likely to cause bias that does not actually serve to reduce the collaboration issues that you might worry about in heterogenous groups. When company values are more explicit, however, they give you something that is (hopefully) less correlated with how people look and more correlated with how people communicate, make decisions, and behave.

I wrote, read, and delivered many reviews, always involving a section on values. I also observed many "core value stories," where employees would stand up and tell about another person or group who went above and beyond and how that tied back to some of our core values. I got to see over and over again examples of people exhibiting these values and the ways they presented themselves.

At some point, I realized there was a pattern. The people in the company who were beloved by all, happiest in their jobs, and arguably most productive, were the people who showed up for all of these values. They may not have been the people who went to the best schools, or who wrote the most beautiful code, in fact they often weren't the "on-paper" superstars. But when it came to the job, they were great, highly in-demand, and usually promoted quickly. They didn't all look the same, they didn't all work in the same team or have the same skillset. Their only common thread was that they didn't have to stretch too much to live the company values, because the company values overlapped with their own personal values.

What's the takeaway here? Well, we often talk about "culture." By now, we know that beer and ping pong tables aren't culture. Many of us fear that "culture" can be a dog whistle for "people who look like me." And yet, people are more likely to be successful and happy if they are in a company with a culture that matches their values. My experience has led me to conclude that looking for the values of your company as part of your interviewing process is probably at least as important as the technical and skills screening, in finding the best employees.

Why is this post called Framing?

The way you ask people to look for values is going to make a big difference in what they look for, and what they see. You might have 10 values, as RTR did. Would you really want to ask every interviewer for a "yes/no" on all 10? Probably not. But if you boiled that question down to "culture fit", do you think the interviewers are going to think about the company values? Or are they going to think about whether this person looks like them, talks like them, is "a person they could get a beer with?" The way you frame the question of culture is important, and if you aren't explicit, people may skip over the details and go with their bias.

If you agree with me that values are valuable, I encourage you to put them in your interview process, and make them explicit. Don't ask for "culture fit", list the values and ask people to mention any they noticed the person definitely meeting or definitely not meeting. Prime the interviewers beforehand with the list of values, so they know what to look for. And then, let me know how it goes! Because this is still theoretical for me, and I would love to hear your experience, as well as any counterpoints to what I have suggested.