Diversity Part I: How To Strip Gender Bias From Hiring

First in a three-part series on how to implement diversity in software engineering teams, by leaders at successful companies.

Sonja Gittens OttleySonja Asana Diversity Lead is Diversity & Inclusion Lead at Asana, where she’s responsible for crafting the company’s strategies for recruiting employees from underrepresented groups and creating an inclusive environment that allows them to thrive. Prior to her roles in diversity & inclusion at Asana and at Facebook, she was global policy counsel for Yahoo’s Business & Human Rights Program. She is a native of Trinidad & Tobago.

Sonja, an attorney by training from Trinidad and Tobago, joined Asana a year ago, after over a year as Facebook’s global diversity program manager, and nearly ten years at Yahoo before that. Follow her on Twitter at @SonjaOttley.

Diversity in the workplace. For some people, it’s enough to say it’s the right thing to do. But there are studies that show that teams that are inclusive — meaning people don’t have to be different on the outside from the inside to fit in — make a difference that results in more innovation and more money.

If you’re not seeing qualified candidates for your positions, look at yourselves instead.

When you have a diverse and inclusive team, you get different approaches to goals and you have a broader set of knowledge and experience. As a result, you are more likely to innovate. Yes, there are plenty of companies making money hand over fist without diverse teams. Imagine what they could do with them.

At Asana, we wouldn’t say we are successful yet, but we believe we’re on the right track. This is a mission for us, and we are still making progress. It’s really easy to talk loftily about what you’re trying to achieve, but it’s not useful unless you are comfortable doing it. So we are trying to ground our efforts in data to determine what really works. Our product makes it easier for teams to track their work with greater clarity, accountability, and efficiency, so tracking and measuring our diversity tactics is second nature to us.

Company culture starts with you

From the start, your company needs to ensure that its culture is absolutely encouraging for any underrepresented group — women, minorities, anyone who is qualified to do the job. If you’re not seeing qualified candidates for your positions, look at yourselves instead. Before a software engineer applies for a position anywhere, they look closely at the job description and the company. But they also look at the company culture, both online and in the real world. Every employee is a walking ad for your company. What message are they sending?


Asana Engineering

The companies that leading candidates want to connect with are those where they feel they can not only do the work and ship products, but find a space in which to thrive and grow. Are there management opportunities? Is there active mentoring to turn today’s coder into tomorrow’s VP of Engineering or CTO? And whether or not they plan to start a family, your family leave policy will tell them something about how much the company values long-term employees. Most of all, if they’re not seeing anyone from an underrepresented group in a place they would like to be at the company, they may not even apply.

Diversity policies can’t just be bold statements on your About Us page. The need to be actively encouraged. At Asana, we offer mentoring and coaching to staff at all levels, so as we grow, our experienced staff will grow with us.

What works — and what doesn’t

We encourage interviewers not to focus on resumes.

 We’ve tried many things to see if they will improve our recruitment and retention of employees from across the range of potential applicants. Some things work notably well. First, we encourage interviewers not to focus on resumes. Assume that anyone making it to the interview stage has the relevant checkboxes you would find on a resume. Instead, get straight to the point and probe them about their skills, and about what they have already done and built. Students may not have had a place to show off their accomplishments outside of their transcripts, so it’s up to the interviewer to find out what they might have done in school besides ace tests. Did they build something, or contribute to an open-source project?

We don’t remove names from resumes to hide gender or possible ethnic backgrounds. We do reach beyond the standard A-list of schools. A name-brand university like Harvard or MIT might have a diverse student body, but focusing on the big names overlooks schools like Harvey Mudd, which has an excellent computer science department, and an unusually high percentage of women coming out of that curriculum. We look at what they actually learned and built.


Sometimes having bias means not recognizing it.

Software engineers can largely be evaluated on the basis of their code, something less true or not true for other roles in a company. We take advantage of that opportunity: As a first step, we do blind, anonymous code evaluations without any identifiable candidate data on them.

We encourage gender-neutral pronouns, a potential source of bias even among people who think they have none, from our internal feedback on candidates. Everyone is referred to as “they” or “them.”

We use interviewing.io to remove gender and ethnic clues even from phone screens. Interviewers can’t make out the candidate’s true vocal tone, or hear regional accents that might bias them. After all, don’t we all have accents?

One company can’t do it alone

At the big-picture level, we work with organizations like Project Include and Founder’s Commitment to develop and share best practices with other companies. Far from being a distraction, diversity recruitment, and retention practices have the potential to make our industry even more gravity-defying, more disruptive to outdated ways, more mind-bogglingly profitable than it already is.

We’re proud of the culture we’ve created at Asana, and the people we’ve attracted to work here when they have so many other options. But no one firm is going to figure it out by themselves. As engineers, we focus on data and metrics to determine what works and what doesn’t, and we document and share our best practices as proof to others that our success — or at least, our progress — offers reproducible results.

Hackbright Academy is the leading engineering school for women in San Francisco dedicated to closing the gender gap in the tech industry. Learn more about our full-time software engineering fellowshipIntro to Programming night courses, volunteer mentor opportunities, and how to partner with us to hire female software engineers and #changetheratio of women in tech! 


How To Win At A Collaborative Coding Interview

Ben NgScreen Shot 2016-11-04 at 2.31.11 PM is a software engineer at Etsy. He previously worked at Shift, enjoys studying distributed systems and mentors at Hackbright Academy. Follow him on Twitter at @_benng

If you’re interviewing for a software engineering position nowadays, one of the first steps in the interview process will be a phone screen. You and the interviewer will look at the same source code using a collaborative code editor like Coderpad. As an engineer for five years and a Hackbright mentor, I’ve been on both sides of the phone. Here’s my big-picture strategy for tackling these interviews, and some advice from experience.

Problem solving is messy. Embrace it!

“Are you going to charge in empty-handed, or carry a sword and a spool of string?”A good interview question will have a solution that isn’t immediately obvious — one that you aren’t expected to know or recognize immediately. Instead, you discover the solution by identifying and solving smaller subproblems, evaluating multiple approaches, and backtracking from failed attempts. Sometimes you’ll need to make a logical leap, and other times you’ll need to make incremental improvements.

Think of the interview as a labyrinth. There’s an unavoidable component of chance involved, but you can maximize your odds of success by having a strategy beforehand. Are you going to  charge in empty-handed and hope for the best, or are you going to carry a sword and a spool of string?

 Five Steps to Success

1. Work some examples manually

Don’t immediately start writing code. There are two good reasons:

  • You want to make sure your understanding of the problem matches the interviewer’s. Try to think of edge-case examples. For example, do you and the interviewer agree on what number the Fibonacci sequence starts with?
  • If you can’t do something manually, you can’t automate it.

The coding questions that you’ll get in phone screens are usually some form of “given this input, produce this output.” Work out a simple example. Then work out some harder ones. Think about edge cases in the input. What if the numbers were negative? What if the integers were real numbers?

2. Translate your examples into test cases

Print this out for your collaborative-coding phone session

A flow chart for problem-solving. Print it and follow it during your collaborative-coding phone session.

After you’ve worked through a few examples, you’ll develop an intuition for what inputs make the problem easy to solve, and what inputs make it difficult. The solutions for the harder cases tend to build on those for the easier ones, so you’ll arrive at a complete solution more quickly if you start by solving the simple cases. Get familiar with your language’s assert library so that you can quickly translate your worked examples into test cases.

3. Start working on a solution

Run your code against your test cases frequently. Get them to pass, one by one. This has two benefits:

  • You’ll demonstrate progress as each test case passes. The interviewer gets to see you methodically tackle a problem rather than flail around. Plus it’s good for your morale.
  • Should you cause an old test case to break — a regression — you’ll know immediately. That’s when the problem is easiest to fix.

4. Look for ways it won’t work

Once all your test cases pass, think of any other edge cases you may have missed. You have a better understanding now of the problem and the solution, so you may come up with situations where your code won’t work. If you do, go back to step 3. Your interviewer will be impressed with how careful you are, and how readily you admit to discovering flaws in your code.

5. Refine it

“Your interviewer will be impressed with how readily you admit to flaws in your code.”Once you’re confident that your solution is behaving correctly, it’s time to refine it; it’s rare to arrive at the optimal solution for a non-trivial problem on the first try. Analyze your solution’s time complexity, and see if you can do better. Common strategies for improvement are pre-sorting the input, using a special data structure, or using dynamic programming. Use your improved understanding of the problem to simplify your code — an elegant recursive solution might be obvious only in hindsight.

If you get a practical problem — like discovering the primary color of an image — you should talk to the interviewer about how you would operationalize your solution. In other words, what do you need to do before you can ship this code? Common topics are security, performance, scalability, testing, and documentation. For example, will your code work on extremely large input? What if a user uploads a Word document when you expected a jpeg image?

Challenges unique to phone interviews

The interviewer can’t see you

This makes it hard for them to gauge your progress. To combat this, you need to over-communicate what you’re doing, whether that’s talking or typing. Whenever possible, show your work in the collaborative text editor. But sometimes, you’ll get a problem that’s very graphical, and easier to think about on paper. For example, it’s far easier to draw a tree and work out a recurrence relation on paper. Tell the interviewer that’s what you’re doing, so they don’t think you’re spinning your wheels.

You can’t see the interviewer

No vision means you’ll be extra-sensitive to everything you hear. Don’t over-react to it.

  • If you hear typing, it’s not because they’re chatting with their friends or working on something else. A good interviewer will be constantly taking notes; they want to capture exactly what you say and do, so that they can make an objective decision later.
  • If you hear a sigh, it’s probably not because of you. Your interviewer may have received an email that their lunch order was delayed.
  • If you don’t hear anything, it’s because they’re giving you quiet time to think. Don’t presume silence means they’ve written you off.

Using the environment

everything-you-think-you-know-about-thomas-edison-might-be-wrong (1)

“I have not failed. I’ve just found 10,000 ways that won’t work.” — Thomas Edison

Run your code often

Frequently make sure that your code compiles, and that your solution is behaving as expected. Unlike a whiteboard interview, you can actually execute code. So do it, and do it often. Very often — several times a minute isn’t uncommon. It’s a rookie mistake to write a large amount of code and then try to get it working at the end.

Got all that?

“As an engineer it’s not just whether you solve a problem, it’s how you do it. Collaborative coding interviews are a unique opportunity to showcase your technical skills. Don’t be intimidated by the stranger watching your every keystroke. Instead, practice the five-step strategy so you can methodically tackle difficult problems under pressure. Before your interview, refresh yourself on the challenges unique to phone screens, so you’re mentally prepared for what’s to come. Finally, don’t forget to use the environment to your advantage, by frequently running your code as you’re working on it. You’ll be a winner, because as an engineer it’s not just whether you solve a problem, it’s how you do it.