My fiend Johonna (aka Josie) Nutter turned me on to the following blog post written by Katie Thomas at the Hackbright Academy. The titular focus of the article is suggesting questions to ask of people interviewing you in order to determine if the overall culture is more or less female-friendly. It’s a great post and you should read it now.
I hope you actually read it as I’m not going to summarize Katie’s excellent advice. Instead I’m going to comment on it since these questions struck me as some of the exact questions I should have asked at my last startup, the one that ended up being a sick cliché of almost everything wrong with SF startup culture. My concern over the initiate or inexperienced candidate asking these questions, and the reason for this post, is to explain why I think these are excellent for ANY person and how people interviewing you can lie to themselves about what’s really going on around them.
“How often do people ask questions? How do people ask questions?”
I love these questions. As a new employee your job is to ask questions. All the questions. As a manager if I found a new hire asking only a few questions within at least the first 90 days I would be concerned about their long term success. As you move upward either technically or management wise this rule becomes more and more important and the time period should be extended further and further. Software testers are especially good at this since one of our primary duties is asking the questions no one else wants to ask or didn’t think to ask. We’re a curious and insatiable bunch that way.
Most interviewers if asked this question will reply with some sort of pat answer about it being a collaborative environment where new ideas and opinions are welcomed. That’s generally a fib in most companies. It’s a well-intentioned fib but it’s still a fib. What you’re looking for here is a reaction to people raising basic questions or asking about things that “aren’t their job” or even things that are tribal knowledge. As an example, within my first 90 days at my last position as a manager I was called into the VP of Engineering’s office and taken to task for asking who should be on an interview panel and which team was supporting which product. None of that was written down on a central repository, if it was written down at all. The issue was most management had been with the company for several years and so knew all those questions before they were moved into team management. My asking questions about this sort of thing was taken as a sign of possible (sure) incompetence as a manager since everyone else knew it.
As a new employee you run the same risk. Unless the company, department, and team are open and accepting of what seem like basic or redundant or even “semantic” questions then you will be facing a wall of expected omniscience you will more than likely fail to overcome.
“What practices do you have in place to ensure high quality code and continued learning?”
Code reviews are awesome. Everyone does code reviews in this day and age, mostly because they’ve been told how awesome code reviews are by a blog entry or expert on some sort of topic. When done correctly code reviews are great as one method for defect prevention while also sparking debate that can raise the level of code quality for all participants. The same is true for style enforcement tools, unit tests, or [insert thing here]. My only complaint with this question is you need to dig deeper. How are these practices and tools used? How are they enforced? Are there different rules for some people? If I check in some code for review how long do I usually have to wait for comments or approval? What is the general nature of those comments? Who can block my checkin and for what reasons? The same questions should be asked of all tools, especially style guides. Who set up the guide? Why did they choose one pattern over another? How often is the guide updated?
As another personal example, I once had a high priority fix delayed by a week as I sorted through several days worth of blocking comments. 30% of the feedback dealt with style issues such as how to format comments or spacing of wrap arounds. 60% of the remaining comments were attempts by various senior codes to make my code conform to their patterns, even if two or more of the patterns directly conflicted with each other. 10% of the comments were issues I missed and helpful feedback around how to do it better next time. All of these comments were marked as blockers to submitting my changes. All of these comments were entered in different days as each person found time to look at my checkin and tell me what to do.
A situation like the one I mention above is a giant red flag for a lack of discipline and coordination between people and teams in your organization. As testers we often span groups when we move beyond the mind-numbing verification & validation activities best done by developers in any event. If two or three interviewers cannot agree on how code is ensured then you can expect a lot of tension when attempting to test across functionality to where 75% of all bugs live.
“Are there any women on the team? If so, what positions do they hold?”
I’ve been to and spoken at a lot of conferences and smaller events. I may have a unique perspective since I don’t just go to testing events. Based on that perspective I can be reasonable sure the software testing and software quality assurance profession is one of the most diverse professions in the larger tech industry. We can do a lot better, but we are by no means atrocious. Development engineering events, on the other hand, are still giant sausage festivals. Most of the diversity numbers you see coming out of the large tech companies this days are completely crap for that reason. All the ones I’ve seen lump development engineers in with testers, marketing, project management, and design. Unfortunately for them even when they play fast and loose with statistics they STILL end up with only 20% females and even worse in the numbers of ethnic and racial minorities or self-identified members of the LGBT community.
The sad truth is this question will help you determine the likelihood of your promotion and salary parity should you join the company as a software tester. If women there are a lot of women in development engineering positions it’s a good sign the company is willing to treat difference with respect. Software testers are different. We think different and we focus on different things than a development engineer. At some companies difference is assigned a value judgement and it’s usually more negative. Managers hire people like them because managing these people is the video game tutorial of people management. Since a startlingly high number of companies don’t care much about people management they promote awesome technicians to positions of authority. As a tester this means there is a ceiling you will hit at some point even if you are a rock star. Unless you change careers you will never move above that level at said company since you are different.
I feel I should also clarify something here. I don’t believe women software engineers are inherently and inevitably all that different from male software engineers. The paradigms and skills making a male an awesome developer are the same one making a female an awesome developer. The same holds true for members of the First Nations, African Americans, Latinos, trans-gendered, or anyone else. I did a talk at Electronic Arts on this very subject and did a thought experiment. It was pretty cool. You should ask me for it since I can’t post it anywhere. Freaking Ted Talks agreement. Anyway … what I’m talking about here is perceived difference which is actually worse since there is little you can do when trying to combat it. The people deciding on your career perceive you as being inherently different (ie: inferior) so that’s what happens. Unless you want to battle that it’s best not to join the playing field in the first place.
Vivre la difference.
“What kinds of things do team members do together besides work? How central is drinking to social events?”
WARNING!!! WARNING!!! HIP STARTUP AHEAD!!!
Katie mentions this question as catching “brogrammer” culture but my experience is something different. A distressing number of software companies have fetishized youth culture as the secret to creating a great company. The culture then reflects this fascination. The perfect employee at these places will be under thirty, moderately attractive, and residing within a small radius of the company. Company social events will revolve around evenings spent drinking or hanging out in bars/nightclubs. Even company offsite team building events in the woods will include an open bar and events that do things like rock climbing or wake boarding.
This is an issue because a lot of companies these days put great weight on “cultural fit.” Not attending these events because you have a family or will need to drive 40 minutes home afterwards will be noticed. Eventually you’ll be pegged as a “poor fit” or even a dreaded “nine-t0-fiver.” Companies that truly care about their employees’ happiness and productivity and commitment will have a great mix of events. One company I worked at had evening keggers where the young could congregate and pretend not to be flirting. They also had family-focused barbecues and outings to sporting events such as baseball and soccer. My oldest daughter got to pet a real zebra at one of these events.
Finding a company that caters to people in multiple points and times in their lives is generally a sign that same company is looking at the long term viability of both their business and their employees.