Don't wait to be invited

Own your story

Work twice as hard

I had the pleasure of attending the Grace Hopper Celebration of Women in Computing conference last week for the first time. Being at a conference with so many talented technical women felt absurdly novel. There were lots of interesting discussions on why the percentage of women in computing is so low and dropping, and the many challenges that women face in the tech industry. While I think that talking about these statistics is critically important, that's not what this post is about. Those of you who know me may have noticed that I'm a woman in computing. I just want to put that out there. Have I faced bias? Probably. The thing is, we so often get caught up in whatever assumptions people have about us, we end up being defined by them. We all face bias at some point in our lives. The question is how to not let it stand in the way of achieving our goals. The three things that I have found helpful are: (1) not waiting to be invited , (2) owning my own story , and (3) working twice as hard . When I was last looking for job opportunities, I knew from the get-go that I would have to overcome a huge amount of bias. No, not because I'm a woman (at least I hope not). The issue was that I had just graduated with a Ph.D. in super theoretical Computer Science that had absolutely nothing to do with the type of job I was looking for. During my interviews, I literally got asked — multiple times — whether I liked to code. I knew I wanted to work at a cool web startup, and I knew that I could bring a lot to the role. I was a kick-ass engineer, but my resume didn't read like it — no MIT or Stanford, no Google or Facebook, and I had basically been doing math for the past five years. And while I had had an awesome stint at another startup company, they weren't well known in the valley. So yeah, no recruiters were pestering me on LinkedIn, no invitations were coming my way. I had to be proactive. I wrote to every person I remotely knew that worked somewhere remotely interesting. I also crashed a couple of Stanford career fairs, where, incidentally, I met Kimber Lockhart (Sr. Director of Engineering at Box). Career fairs were good because they made it easy to own my story. I could enthusiastically talk about how I love coding and building products. I could emphasize the experience I had, and the cool work I had done. I could even spin my degree as the incredible growth opportunity that it was, and as a hard-core testament to my smarts. It worked. I got invited to interview. Not everywhere, but more than enough. Now I just had to get through the panels. Knowing full well that every person interviewing me would be trying to figure out whether I was a theoretician that was actually interested in research, or a "hacker" worthy of joining the team, I had to not give them any reason for doubt. So I studied. A lot. I was in pretty good shape on the algo side, but I knew I would have to really counteract the lack of webiness on my resume. So I read up on all the new web technologies, MVC design patterns, scaling challenges... The works. During my phone screen, I was asked how to scale a MySQL DB. At that point, neither my phone screener nor I had done anything of the sort, but I still gave a solid answer. It showed I was invested. I also read up on every company I talked to so that I could show a genuine interest for what they were working on. I counteracted the "are you sure?" questions with true enthusiasm, and more often than not, it worked. As the engineering team at Box has been growing, we're constantly in a state of having lots of new people. This might make it feel like we have a bias against newbies when it comes to projects or decisions. I can vouch that this is not true. When you think about it, the vast majority of the organization has been here under three years. We're all "pretty new." Talking about it, and making sure that as an organization we stay merit-based and not seniority-based is something I care a lot about, but again, this post is not about the statistics or the trends, it's about what you can do to chart your own path. In the past several months, I've gotten some questions about how to get into cool design meetings, and other "closed-door" meetings. So I think by now you might guess what my answer to that is... One of the main reasons I wanted to work at a startup was the idea of working somewhere resource-constrained where you end up doing anything and everything you're capable of. At Box we've grown quite a bit, but we're still super resource-constrained and still super flexible. We're trying to build an organization that we all own together. So my advice is this: If you hear about an interesting meeting, ask to join. Don't know where the interesting meetings are? Just talk to people. Ask what they're working on. Take an interest. This is not an invitation to crash people's meetings uninvited, just an invitation to be proactive. There are other ways to get involved without attending meetings. For example, in the Engineering team at Box, we have recently been piloting Jive as a means to be more transparent in our communication. The whole idea behind Jive is that it's open to all and everyone is invited. Remember that bias against your newness is in fact justified. You actually are new, which means that you lack context for a lot of things. This can be great because it gives you a fresh perspective. Hands down, one of my favorite things with having a new person join the team is waiting to see what they will find confusing. If you see something strange in the code or our architecture, definitely bring it up, but do so with respect. You want to be the new person that asks good questions and gets everyone thinking constructively. While you're talking to people, be enthusiastic, ask questions, make suggestions. Understand what's interesting about the project you're working on and then talk with other people about it. Schedule your own design meeting. (Now you're invited!) But what if you're not working on an interesting project? I honestly don't believe that. I have yet to meet an engineer at Box that wasn't working on an interesting project. Everything that we're doing here is part of such an amazing goal that it is, by definition, exciting. Being the person who's working on a cool project is fully within your control, so own that story. When you're new, people don't know your value yet. This is true whether or not you have experience. Everyone expects you to be awesome, but unless you've actually written the book on something (like Box Staff Software Engineer Nicholas Zakas ), respect has to be earned no matter what your title is. So go ahead and earn it. If I'm working on a project, I'll go to get advice from people I think will bring me the most value. Become valuable. Learn something from the projects that you work on. Share those learnings with others. Help people when they ask for it, but don't expect them to ask right away. It takes time. In the meanwhile, you just have to keep kicking ass and building a reputation. The cool thing about "working twice as hard" is that it's fully within your control. You own your performance in every situation. The better you make it, the harder it will be to bias against it. And you know what? It actually makes you better for real. At Box, we promote based on performance, not potential. That means that everyone who has been promoted to a certain level on the technical track was performing at that level before the promotion. I still remember getting a peer comment during my first review cycle about not writing enough lines of code at Box. My manager and I both knew that this didn't hold weight. So why the comment? Was it because I'm a woman? Because I had a Ph.D.? Because I was new? Personally, I don't think it really matters. When I was working on sharding , I wasn't a Staff Engineer or an Engineering Manager. I was also the newest person on the team. This was my starting point, so I made sure that I owned my own story on that project. I talked to people. I was enthusiastic. I learned a lot. I brought value. Bias is surmountable. You own that. Tamar is a Staff Engineer and Engineering Manager at Box where she specializes in scaling Box’s database architecture and ORM layer. She holds a Ph.D. in Computer Science from the Technion – Israel Institute of Technology. This post is an adaptation of an internal blog post she published at Box.