Hackbright Fellows Visit Slack HQ!

Yesterday, Hackbright Academy visited Slack HQ for the first time. We were greeted by Hackbright alumnae and current engineers at Slack, Roo Harrigan and Allison Craig, so we felt right at home immediately.

A warm welcome from the Slack team.

Pictured: A warm welcome from the Slack team.

Roo kicked off the field trip with a short introduction to the Slack platform. The field trip then got interactive very quickly! Roo led the Hackbrighters through a Slack-Twitter integration so that we could all test out an integration for ourselves. A few shouts of joy later, many of the women had successfully integrated their Slack accounts with Twitter and were viewing their tweets posted in Slack channels in real time.

Hackbrighters successfully integrating Slack with Twitter.

Pictured: Hackbrighters successfully integrating Slack with Twitter.

Next, Roo discussed webhooks and how they are applied on the Slack platform, and then led us through the Slack API. In preparation for this field trip, all the Hackbright students were given access to a github repo, and after Roo’s introduction, we moved in to an API workshop time. Each of the women worked on creating an environment and delving into the Slack API, while other engineers on the Slack team assisted by answering questions and providing guidance.

Slack engineer explaining

Pictured: Discussing Slack API with the engineering team.

Towards the end of the field trip, we then transitioned into a Q&A time with a group of fabulous panelists — all women engineers! — at Slack. The panelists included another recent Hackbright graduate and Slack Software Engineer Carly Robinson, Slack Test Automation Engineer Jessica Tung, Director of Engineering at Slack Joann Anderson, and Senior Engineer at Slack Duretti Hirpa.

This amazing line up of panelists then shared their gems of advice to women starting out in their software engineering career:

  • Networking is key — take advantage of informational interviews, without the pressure of getting a job out of the conversation, as an opportunity to learn and build your network in the tech space.
  • Once you land your first job, seek out a more experienced engineers and ask how they debug things. Sit with them, pair with them even, and learn their strategies for debugging. Getting past the tooling, learning how to switch tabs and work faster — these things can get in the way of your progress, so try to learn them early on!
  • Be comfortable with frustration. It’s not an easy job search, but you do have a powerful network of women in your program as well as in tech at large, so lean on each other for support throughout the job search and career growth journey.

They also shared about their most and least favorite aspects of working at Slack:

  • Dealing with growth is the most challenging thing — we’ve grown from 120 to 500 since I started, and communication is affected by the rapid growth. However, the thing I love most about Slack is that I have the most intense working day while I’m here, but once I leave, things are quiet and I have the space to take care of the rest of my life.
  • I have never felt stupid at Slack. From the beginning, I have always felt supported and everyone was always open to questions. The challenge now is that because I’ve been here longer, I get to work on more challenging parts of the code base and things are a bit more hands off. It’s a good challenge, but it’s also… a challenge!
  • The people at Slack are the best group of people to work with — they are very receptive to questions, and I always feel heard and seen. The hardest part is the growth and changes that growth brings to team dynamics and communication dynamics.

Roo then kicked off an audience Q&A and Hackbrighters jumped in with insightful questions for the panel:

Q) Do you have advice for women and people of color in the interview process and workplace, who have historically been disenfranchised in the tech industry?

A) My advice is to participate in organizations that support black and hispanic engineers. It’s so important to network with the group of people you identify with and who can better understand the challenges that you go through and who have similar backgrounds. An example of a great community is /dev/color.

  • If you are asked an uncomfortable question during an interview, be curious and ask, “Could you tell me why you are asking that question?” Stay open and curious, because you never know why the interviewer is asking that question, and it could be an opportunity for you to educate the interviewer on an area that they might be blind to.  
  • Do your research on the company overall — Silicon Valley has a bad reputation for its company culture, but not all companies are like that. Dig in to find out how the company you are evaluating operates. In your interviews, ask what the company is doing to promote diversity — the answer to that question allows you to see if a company is actually walking the talk when it comes to diversity hiring.

Q) How do you onboard new engineers to Slack, especially as you continue to grow?

A) Every new engineer is assigned a mentor. All new engineers also participate in onboarding exercises, such as making a change to a web page, so that you get familiar with things like deploy workflow, how to write an ABI test, unit test, etc. New engineers also start with a couple of bugs — these bugs have been labeled as “easier ones” and they work through the bugs along with their mentor. Once this orientation period is completed, they then get to talk with their manager about future projects to tackle, such as  building a smaller feature by yourself, or working with your mentor on their feature, then working on a bigger feature, and then working independently. Every new engineer is paired up with a mentor, no matter how much experience you have. Everyone gets a mentor.

Such insightful information! Thank you, Slack, for inviting us into your space and empowering us with tools and advice to succeed as software engineers.

Hiring engineers? Join us for Career Day on June 8th, where you can meet Hackbright’s newest software engineers! Learn more about how you can partner with Hackbright to change the ratio of women in tech.

Bootcamp to Engineer: How I Got My Job

“Reach for the stars!” they tell us. ”Don’t stop chasing your dreams!” they say. We hear over and over again that we should go after what we “really want.”  TED Talks, inspirational memes, and our therapists tell us to just “go for it.” Yeah, we should!

giphy (15)   82a0d7622759be1112315c2dbd9d6fdfMeanwhile, real people are like, “yeah, right”. It’s much easier said than done!

There are so many unanswered questions and unaddressed fears that hinder us. The uncertainty of success prevents us from trying.


Sometimes you need more than inspiration – you need proof! You need information that will validate your goal and motivate you to take that risk. You need resources that will quell those fears and help you feel more secure about your decision.

That’s why we are hosting an incredible event for women who want to make a career change.

Check out Bootcamp to Engineer: How I Got My Job.

We believe that the best way to make a tough decision is to arm yourself with the information and resources that will carry you through to your success. On June 2nd you will hear from women who risked everything to become software engineers. Now they are influential, successful, and most importantly, HAPPY! You’ll also hear from the hiring managers at Hackbright’s partner companies about hiring and onboarding bootcamp grads. Read a little bit about our speakers below.

  • Kyla Farrell joins the panel as both Hackbright Alumna and engineering manager at Lanetix. She began her career in Architecture and Construction before transitioning to Software Engineering.
  • Josh Leven  has founded two ed-tech companies, and is now working at a third (NoRedInk) where he’s helped grow the team from 2 to 30 people.
  • Terri Wong graduated in Hong Kong with a BS degree in Digital Graphic Communication & Business. She is another Hackbright Alumna and a Software Engineer at GoDaddy.
  • Elsa Birch has a PhD from Stanford in Chemical Engineering. After graduating from Hackbright, she is now a Software Engineer at Pinterest.
  • Wayne Wight is passionate about growing diverse, collaborative, engaged development teams. He is a Hiring Manager at Lever.

Come to our free event this Thursday, June 2nd to learn from these women and men, and connect with others who are also considering a big change. Discover the resources and services Hackbright Academy provides to our graduates to help them succeed. Then, go forth and #changetheratio!

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.