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! 


Programming is Not Math – Sarah Mei

Sarah Mei, founder of RailsBridge, wrote this piece that we had to share. For all you talented women out there who are on the fence about whether or not coding is for you, we hope this provides some insight into the industry and what programming is really all about. Enjoy!

 Programming is not math.

When I learned to program, back when dinosaurs walked the earth and the internet had no cats, there was an idea: if you were good at math, you’d be good at programming. I was great at math as a kid, but perhaps because I didn’t like it much, no one steered me towards programming. I came to it accidentally, in college, when I took an elective programming class because it fit my schedule.

So my first programming language was Fortran, an abbreviation of “Formula Translation.” As you might expect from the name, the projects in the class were exciting things like estimating the area under a curve using rectangles, like you see in the diagram below.

The Riemann Sum.                   The Riemann Sum. Thanks to H.J. Keisler.

Doing Riemann sums in Fortran is about as math-oriented an introduction to programming as you can get.

And I loved it. SO MUCH!

That same quarter, I was taking my first Japanese class. Towards the end of the term, when I was getting ready to change my major to computer science because PROGRAMMING FUCK YEAH, I thought briefly about how similar the two classes felt. In both cases, I was coming into a culture I didn’t understand or feel part of. I was learning the mechanics of communicating, while at the same time trying to gain enough cultural knowledge to feel at ease.

But I knew – and everyone knew – that programming was like math. So clearly, I was good at Fortran because I was good at math.

Now, almost twenty years later,  I’ve changed my mind.

It started when I graduated, became a software engineer, and discovered that the vast majority of developer jobs only required middle-school math at the most. I had to keep a bit of math handy to do whiteboard interviews, but once I was on the job, my ability to communicate both with computers and with other humans was much more important.

Math gifI figured, at the time, that my jobs were the exceptions. Surely most programming was way more about math. I just, uh,…didn’t see those jobs. Even on the job boards. And my friends didn’t seem to have them, either…but oh well.

Then after I’d been working about ten years, I started teaching new people to program in my free time. I taught Ruby on Rails, which is a web programming framework; people came because they wanted to learn how to make websites. Because of those motivations, the curriculum had virtually no math.

And this is what finally did for it me. The students I saw – all adults – came from a wide range of backgrounds. People with a math background did fine, of course, but people with a heavy language background often did better. I saw this curious effect again when I started working with high schoolers, with a similar curriculum. Bilingual kids often took to programming more easily than monolingual kids.

I thought back to college, to my jobs, to my friends’ jobs, teaching…and I finally figured it out. Programming is not math.

Programming is language.

Specifically, learning to program is more like learning a new language than it is like doing math problems. And the experience of programming today, in industry, is more about language than it is about math.

And my next thought, of course, was why doesn’t anyone else think this? Why do we still have this idea that math skills indicate programming potential, while language skills mean you should go into poli sci?

Well, when I feel out of my depth, I usually start by looking for “official” opinions. So I looked for relevant academic research.


I found absolutely none, which is pretty flabbergasting. I found a lot of opinions, both from computer science educators, and from people in industry. Perhaps within academia, the link between math and programming is considered such an obvious truth that it isn’t worth confirming with research.

It seems more likely, though, that this research exists, but not under the search terms I tried. Please let me know if you are aware of relevant papers.

In the meantime, if we can’t have data, we can at least examine the conversations people have on this topic. Here are some things people often say when asserting that people must be good at math to be good developers.

Generally, they fall into three categories:

1. “You need to know math to be a good programmer.”
2. “You need to learn math to get the skills you need for programming.”
3. “Plenty of programming is still math!”

Let’s look at them one at a time.

1. You need to know math…

1A. …because computer science comes from math.

This is true. Academically speaking, most computer science departments trace their lineage to the mathematics department. Many computer science degrees are still very math-heavy. Mine certainly was.

However, as many other people have noted, computer science is not programming. At most academic CS schools, the explicit intent is that students learn programming as a byproduct of learning CS. Programming itself is seen as rather pedestrian, a sort of exercise left to the reader.

For actual developer jobs, by contrast, the two main skills you need these days are programming and communication. So while CS still does have strong ties to math, the ties between CS and programming are more tenuous. You might be able to say that math skills are required for computer science success, but you can’t necessarily say that they’re required for developer success.

1B. …because without a mathematical foundation, you’ll have only a surface understanding of programming.

A common variation on this: without a CS degree, you can’t build anything substantial. Which, ha ha! Don’t tell the venture capitalists! They’re down there on Sand Hill Road giving actual money to hundreds of people building software projects without any formal qualifications whatsoever. In fact, they do it so often that the college-dropout-turned-genius-programmer is our primary Silicon Valley archetype of success. And monetarily, their strategy seems be to working out for them, if the fleets of Teslas on 280 are any indication.

Back here in the real world, I have found little connection between a person’s formal qualifications and the depth of their understanding. As an example, consider whiteboard interview staple big-O notation.

If you took a dynamic methods class in school, you know that big-O notation is pretty much meaningless in the real world. Which is to say, it doesn’t matter how an algorithm operates on an arbitrary set of data. The only thing that matters is how it operates on your set of data. An algorithm that is O(n**2) for arbitrary data may actually be constant time (meaning O(1)) on your particular data, and thus faster than an algorithm that is O(nlogn) no matter what data you give it.

There are some interesting mathematical ways to model this, but weirdly enough, the people with CS degrees conducting whiteboard interviews never seem to be too interested. Go figure.

So, if you don’t actually need to know math to be a successful developer, perhaps instead the very act of learning it primes you to think the right way?…

2. You need to learn math…

2A. …because it teaches abstract problem solving, which you need to be good at programming.

Abstract thinking is absolutely a skill that every developer needs to hone. In fact, some people say that finding the right level of abstraction for a concept in your code is the root of all hard problems in software.

It is also quite true that you can learn abstract thinking by studying math. At last year’s GoGaRuCo conference, Daniela Wellisz, a developer with a background in math, did a fascinating talk on how programming is similar to doing proofs in math. I recommend watching it if you’re interested in the topic.

However, just because you can learn abstract thinking via mathematics doesn’t mean there is no other way. Learning a new human language is another way to develop that skill. Coming to understand concepts that are literally impossible to express in your native language is pretty damn abstract. When we learn a second language, the way we re-organize concepts based on a higher level of abstraction is structurally quite similar to how we re-organize concepts when we learn to think mathematically.

So while math is one way to learn to think about abstraction, it is not the only way.

2B. …because programming based on the mathematical concepts of logic.

Indeed, programming is often concerned with logic. But the same logical concepts are embedded in our human languages. Math is just a formalization of the concepts we use every day when we construct sentences and communicate with other humans. The best writers and speakers understand that, and can construct logical statements in human language that are easy for other people to evaluate. Sometimes they even change people’s minds about things.

Mathematical logic is a notation for concepts we already know, and it is the concepts – rather than the notations – that are important.

So if you don’t need to know math to be a developer, and you don’t need to learn math to be good at development…wait! But some jobs still do!

3. My developer job uses plenty of math!

Of course people still use programming to do math. But programming itself no longer is math.

Even in non-math-oriented languages, there are some applications where math will be useful. And then of course there are whole languages oriented around math, such as Fortran, as I mentioned before, and Haskell, a largely academic language now finding favor among some industry developers.

But these are the exceptions that prove the rule. If a small and shrinking set of programming applications require math, so much so that we cordon you off into your own language to do it, then it’s pretty clear that heavy math is, these days, a minor specialization.

And even if you are writing code to do math-y things, you’re probably not very good at it unless you’re also good at language. The best developers today work on teams, and they do well IFF they know how to communicate – via their code, and directly with other people. As one of my favorite programming books once said, “programs must be written for people to read, and only incidentally for machines to execute.”

The long view.

If programming is so similar to language, why haven’t we – developers – already made this mental adjustment? Why does the idea that “if you’re good at math, you’ll be good at programming” persist so strongly?

When programming was just getting started, early in the last century, we used it to solve highly mathematical problems like calculating missile trajectories and decrypting secret messages. At that point, you had to be good at math to even approach programming. Tools, such as programming languages, were designed specifically to solve mathematical problems, because those were the ones we thought it was worth spending money on. Computers were for doing math.

Over time, due to lots of different factors, our societal conception of what computers are for has evolved. When considering this question, these days we think in higher-level concepts such as solving a problem, making some tedious thing more convenient, and/or making money. These higher-level goals sometimes include mathematical subgoals, but also include things like ease of use, connectivity, and interface — problems that can basically be summed up as “messy humans and their relationships to other messy humans.”

So as a result, while programming is still applied to some mathematical problems, in our modern world it is more frequently applied to other, messier types of problems. The shift happened pretty quickly – it started gathering steam in earnest in the 90s. And today – only 20 years later – we find ourselves with math-oriented programming jobs firmly in the minority.

It makes sense that slow-moving academia hasn’t caught up yet. And the programmers who today are the senior developers, the old guard, came of age when this wasn’t yet true. So of course they think the path to success looks like theirs.

Don’t panic!

You can still be successful if you walk the traditional path. If you’re good at math, you’ll probably still be good at programming.

But the rapid evolution of our industry means that math skills are no longer the only indicator of potential developer skill. In fact, they’re probably a weaker indicator than they’ve ever been, given where the industry’s going. So please, guidance counselors: send us the ones who love language. We’ll give them the tools to change the world.

What has your experience been with math and programming? Tell us in the comments below! Feel free to share and be sure to check out Sarah’s  blog for other honest and helpful thought pieces. You can also follow her on  twitter!

Hackbright Academy is the premier engineering school for women in San Francisco dedicated to closing the gender gap in the tech industry. Want to join us and help #changetheratio? Awesome! Learn more about our full time 12-week software engineering fellowship at for our upcoming Info Session on April 13th! RSVP to join us in person or remotely. 


What To Expect When You Graduate From Hackbright

Wendy SaccuzzoWendy Saccuzzo, Director of Career Services at Hackbright Academy, helps place Hackbright students into software engineering roles at some of the world’s fastest growing tech companies and startups.

Hackbright graduates with majors such as Linguistics, Art History, and Spanish land engineering roles in Silicon Valley companies. A Computer Science degree doesn’t determine your success. Other things do.

It’s a good time to be a software engineer. Salaries are high, demand is high, and the outlook for growth in this career long-term is strong. This is arguably the most in-demand profession in our increasingly tech heavy world.

The problem? People can’t get past the antiquated notion that a CS degree determines whether you’ll get a job. It doesn’t.

Stop thinking a Computer Science degree is a necessity.

Mark Zuckerberg was majoring in Psychology before he dropped out of school to start Facebook. Hackbright has gotten over 200 brilliant women into engineering roles. Guess what? Only a handful had CS degrees. Hackbright alumnae are working at partner companies like Eventbrite, Facebook and New Relic and loving their jobs in engineering.

Did you break stuff and try to put it back together when you were a kid?

Did you spend your recess in the lab working on the computer, tinkering with things around the house, or assembling a zine?

Have you taught yourself some code?

Do you love learning new languages, or delving into linguistics?

Do you build and/or play games, and feel driven to know more about how it all worked? Are you good at debate and explaining how things work?

If you said yes, then you have what our graduates have – curiosity, one of the most important ingredients to being a successful software engineer.

Your major doesn’t determine what you’re capable of doing.

Anthropology. Political Science. Biology. Public Policy. These are just some of the majors that our graduates who are now software engineers had. Thank goodness that they didn’t let their majors overshadow their interest in becoming software engineers. Does that mean anyone could be a software engineer? No, but it’s not as hard as our culture makes you believe.

If you’re enjoying the more technical parts of your job or perhaps you do a little coding on the side, then maybe you should look a little further into the field. Try out some meetups, or go to a hackathon. Build something with a group of people who are also curious and see what it’s like. Not only will it give you an idea of what a day in the life is like, but these passion projects and contributions and commits you make on GitHub will make you a marketable candidate.

You can then further your coding skills on your own or join an immersive program like ours. Either way, if you see your capabilities are there then there’s no need to stop yourself from making the career change.

Companies want to see your capabilities now and see a hunger for learning.

As an engineer, you need to be able to fix broken software, leave the code in better condition than you found it, fix bugs, and think about scalability. You must always be thinking, “What if?” New programming languages and frameworks come out on the regular. To stay relevant as a software engineer, you need to keep up with the latest trends by going to meetups, conferences, and reading up on the latest technologies.

At Hackbright, we know what the market trend is and that’s what we teach you. Supplement that with going to coding meetups, being informed of the latest technologies and going to conferences, and guess what?

You’re the type of coder that a company would want on their team. Because even the CS degree majors on their team may not be as up to date on the latest as you are. That’s what makes you extremely valuable.

It’s not just about a CS degree for companies.

Meet Sarah. Jasmine. Alaina. Jessica. Siena. Micki – all graduates of our 12-week immersive program, all engineers, no CS degrees. Many supplemented that experience with the plethora of tech opportunities provided to them in the area.

Engineering leadership and the technical recruiters who are hiring for these coveted positions want to know why you decided to learn how to program. They want to know that you contribute to open source, that you have regular commits on GitHub, and that you spend time outside of your day job on this hobby that you’re turning into a career.

Be able to talk about how you’re always learning, what you’re curious about, and that you’ll contribute to the culture of curiosity on their team. Let them know that you might not know all the answers, but that if you’re stumped, you’ll ask a couple of other people, search for some answers on the internet, and try to figure it out first before you throw in the towel and ask someone else what to do. Now that’s a promising engineer.

Not only can you be an engineer, but you can be an engineering manager!

Hackbright began in 2012 and in three short years, we’re already seeing multiple graduates get promoted to engineering managers.

Why? Curiosity. Passion. Drive to learn… You get the idea!

Check out the new 2015 Course Report on Coding Bootcamp Outcomes and Demographics to see the average result of coding school graduates.

Bottom line: We need more engineers – we need more FEMALE engineers, and a CS degree doesn’t determine if you can do it. Only the time and energy you put into coding now will.

Join Hackbright’s upcoming 12-week software engineering fellowship and become a software engineer with us. Apply to the fellowship before November 6, 2015.

Prospective hiring partners of Hackbright Academy – companies that are hiring for diverse engineering teams – can sign up to recruit from Hackbright Academy on December 1, 2015.