PyLadies Meeting notes from “Negotiating the job market: a panel discussion”

Flora Worley organized a fantastic PyLadies PDX meeting called “Negotiating the job market: a panel discussion“.

The meeting was organized in three parts:

  1. Experiences (good, bad and ugly) from four women who entered the software industry in the last 1-2 years.
  2. Managing expectations and setting boundaries from three people, two recent entrants into the industry, and me.
  3. Negotiating the application/interview/offers process (which we turned into a group discussion, led by one panelist)

We kicked things off by asking people to get into groups of four and talk to each other about why they came and what they were hoping to get out of the meeting.

Some of the comments from the meeting and feedback after included:

  • On what was good prep for interviewing: Attending PyLadies and Python User Group meetups to learn new skills, hear about what modules and techniques people are using. (from Amy Boyle, a local developer)
  • Attending PyLadies helped fill in gaps in knowledge useful as a working programmer, even after having a CS degree.
  • “I love being a Pylady, and if it weren’t for this community, I honestly don’t know that I would have continued learning to code.”

Below are my notes from the first panel, anonymized and edited a bit.

How did you find your first job in the industry and know it was the right place for you?

  • I knew a founder of the company from college
  • Knew someone and they invited me to apply. Wrote a great cover letter and got an interview even though they thought I didn’t have the skills for the exact job I applied for.
  • Got the job by going to talks and staying and talking to the speakers.
  • Decided I was more interested in data than my major! Looked around and found a company that was doing a lot with data.

At what point do you say you “know” a programming language?

  • I shy away from saying I “know” something — seems presumptuous to say that the same way it seems weird to say “I’m a writer.” If you’re getting paid to do a thing, though, then you get to call yourself the “thinger”. Coworker has been asking me for help with python and I know the answers to his questions so…
  • Finding ways to help others with things is a good way to boost your confidence.
  • Once I give a talk about something, I have to say I know how to do it because people will come to me for help. It’s a way to force yourself to cram, find out what you know and really don’t know. On my resume I don’t say “I know” — I say “I have experience with XYZ; I have managed to learn these things to get the job done.” Most technical interviews ask more general questions.. not exact syntax of a language.
  • Interviews seem to be trying to figure out if you can learn whatever it happens to be that they need you for at the job.
  • We have to support many languages. So many languages at the same time can get overwhelming.
  • I don’t say I’m an IOS programmer, but I help people write and improve their IOS code all the time.

What was your interview like?

  • Shared projects I made. We just went through my github repo. Tell me about this project, what did you do, what did you use.
  • Was interviewed over Skype
  • Interviewed with 4 people in a marathon. None of those interviews were super technical.
  • The interviews seemed to be gauging whether you would be able to just talk about whatever comes up.
  • They asked me about a lot of command line skills and brought lots of people in from different parts of the company.
  • The interview had me sit down with a program — there’s a bug in this program solve it. What I learned is what matters is the process of how you work on bugs — and being able to communicate that while you’re doing it, not that you actually fix it.
  • Most valued skill is resilience rather than a technical background. You can learn, compensate, fill in gaps. Need willingness to learn, capacity to be frustrated/despair and just move on. People don’t want to hear you freaking out, just want you to do it. Even if it takes you a long time.

Were there classes or resources that prepared you for interviewing?

  • Go out and make something for yourself. Nothing better than finding a thing you want to make, and then making it. Going back to old code, really fulfilling to see progress and wanting to make old code better. You have something to share!
  • Coming to meetings like PyLadies and the Python User Groups. I took some CS classes, but there was lots that I missed. You don’t realize how much you don’t know! Get to meetups to hear about what others are using, what is current in the field. Having a sense of with what the latest stuff is, what are good blogs, best practices, helps out. (seconded by another panelist)
  • Very helpful to go to PyLadies and talk with people around my same experience level. In conversation, people would explain stuff to you in a way that made sense, not just a bunch of jargon.
  • Learning that ecosystem and what tools people use is huge. Helps you figure out what a job entails and what do you need to know to build it.
  • For most of the stuff you’ll build, you’re going to use other libraries. It helps having experience mushing things together. Iterate on it. Every little thing you learn, you’ll find ways of improving stuff.

What if your coding style is really different than other people’s? How do you handle that?

  • Get good at giving constructive feedback
  • “days of spaghetti code is behind us” at the mercy of other people’s crappy code — tech companies deal with this a lot less.
  • Don’t be afraid to say “no idea what this function ” learned a lot about better code by reviewing a lot of code

What kinds of positions can you get? And where do you want to go?

  • Really overwhelming to learn everything I needed to know to support product. It’s an all guys team, learned to love them all, took on a mother role.
  • Teaching stuff all guy team can be intimidating, but most of the guys I work with are college educated CS guys, me having no CS background was intimidating until I realized I knew and could learn this stuff as quickly as they could. No CS didn’t matter.
  • I’m doing tech support, wish I could do more coding. It’s a mixed bag doig support, you learn a lot about system. Found that management wanted everyone to level up in tech support and not go to other parts of the company. I’ve had to come to terms with managers trying to keep me in that role. Need to see how long they expect you to stay in that role before you can move on — ask up front.
  • Had similar experience — resistance to moving from tech support into other roles. Most people in support are looking to move into another role. Make sure you’re on the same page with manager rather than be surprised by it later.
  • On working with guys: my communication style was not really effective when I started. Sometimes had customers that said “can I talk to tech support?” “can I talk to an engineer?”. Had to learn how to be kind of cocky — “This is how this works.” If I was wrong, I was wrong, and had to fix it but that was much more effective at communicating with customers and coworkers.
  • Had to learn that nothing wrong with asking for help. Saves a lot of time.
  • Everything takes me longer than I think it will. Triple your estimates!
  • I needed to learn its ok to ask questions, ask questions confidently rather than despair of never being a programmer. We all tell ourselves crap like: “i’m just generally stupid and can’t learn anything” or “can’t learn javascript in a day, so clearly i’m an idiot”. But turning that around is important for yourself.
  • Be dilligent in the way you ask questions: 1) first google it, stack overflow, check reference book; 2) write out the question fully (rubber ducking) — articulate the problem fully and you might solve it for yourself — what did i expect, what happened, what else can i expect….
  • I’ve had people say to me: “I don’t know why pyladies needs to exist.” I said: “I think its nice its a safe place where that you can articulate your questions without fear.” I don’t know what to do about it other than say that.
  • Men might be made clear to you that they believe we are post-sexist, post-racist. If you have too many of those people around, find a new job.
  • “you need to be careful about where you are” when expressing opinions about feminism.
  • Be open and honest, and they tend to understand.
  • Sometimes it may be the case you have to figure out if an opinion is being expressed because of privilege or malice. If privilege, it can be worked on.
  • Try to internalizing confidence. Tell yourself: “I know how to program” more. Once I really believed that, my programming got better. Because I know I will solve the problem I’m working on!

Do you find that as a woman you communicate differently and you are interpreted differently?

  • Here’s an example: when someone says: “Can you pass the salt?” One person might respond by thinking, “I understand you’re being polite and phrasing that request as a question rather than a command. Sure, here’s the salt!” Or another person might respond with, “I could pass the salt to you. Is that actually what you want me to do?” Pretty different communication styles.
  • Try to be flexible and ride out conflict.
  • I question myself a lot — did i interrupt too many times, was i too aggressive. I worry I am too aggressive.
  • Be yourself. Take time to figure out if you are happy or not.
  • Try to compromise and avoid “truth bombs” where you “explain how the world is”. Take conversations case by case and try not to take it personally.
  • If it gets to be too much, get out of there!

Why PyLadies?

pyladies_blue

Hey Hacker News! If you’re coming here for the first time, you may also be interested in What I mean when I say I would like more women in the software industry

PyLadies is a group of women working on welcoming, encouraging and directly inviting women to join the Python community and to learn from each other.

I started a PyLadies chapter in Portland, OR last September (2012). We started out with weekly meetings to do homework from a Coursera class to make games with Python. That turned into weekly meetings — plus homework meetups on Saturdays at a local coffee shop, and IRC hangout time to test homework. And that turned into me giving mini-lessons at each Coursera meetup about the material from the class.

People seemed really excited.

Stats - PyLadies PDX (Portland, OR) - Meetup

Before we knew it, it was December, we had over 60 women subscribed to the Meetup, 30 of which had attended a meeting. Today, we’ve got 96 subscribers, 50 people have attended a meeting, and more have signed up to attend events in the future than ever before. And, it’s done by women. Using open source. Teaching classes. Learning developer tools. And writing software.

Since September, I’ve met even more women involved in running PyLadies chapters across the country. Much like the way the PostgreSQL community is organized, we’ve got a loosely connected group of people working independently. We offer support to each other, but don’t have hard and fast rules about what each chapter does. We encourage teaching and workshops, but don’t require them. We share our resources and are quick to put git repos out there of our materials. We send lots of pull requests. And we’re constantly looking for ways for women to get more involved in open source and Python.

All Group Reviews - PyLadies PDX (Portland, OR) - Meetup

I’m completely energized by the positive feedback we’ve gotten for every meeting. More recently, I’ve heard from people that they feel confident and sure of their knowledge because they’ve spent time in our meetups talking and learning from other women.

My goal is to make every get together like that – by having great lessons, a shared understanding of coaching and peer-based education and presentations from our members. Building these groups takes time, and I’m impatient to get to the part where I feel like every interaction with the group is rewarding for every member.

And I can’t do it alone. We’ve got four meetup organizers (although one is about to relocate to the Bay Area!). I work closely with Flora Worley, a kickass developer who chose programming as a career path after working on a PhD, on topic details and planning for the meetings. I’m so looking forward to meeting in person with the many members of the PyLadies community at PyCon next month.

Current status: little victories

I’ve got a lot going on right now.

Nothing feels momentous about any particular thing. I’m trying a lot of new ideas and work, struggling, failing and trying again. The transition from the last couple of years of insane travel and starting a business to development work and staying closer to home has been a very good one.

Work

For those that have asked about my work status recently:

Mozilla is great. You can see a lot of the work I do in the Socorro commit feed. Or, in my bug feed. I hang out in #breakpad, #db and a few other channels on irc.mozilla.org. And I’m going to give a talk about Postgres and Backups on February 6th, based on the research I’ve been doing into open source solutions for binary backups.

It’s wonderful to be working in public. I love how much time I have to write software and think about database architecture. I’ve been digging out of a backlog of application and DBA-related work and just coming up to speed on Socorro for a couple months, and that’s starting to pay off.

It’s also wonderful to have coworkers, working on the same things. Most of my work life has been solitary, both in physical proximity and the work itself. Now, all my code is reviewed and I work closely with developers and engineers, daily, on everything.

PyLadies

I’ve been organizing PyLadies meetups with Flora Worley and a few others. We now have more than 60 people who have joined the Meetup, and over 20 women show up to every workshop and hackathon. It feels quite unreal to have 20 women I didn’t know a month ago showing up, forking repos and sending me commits every day. I ask newcomers to send me a commit that links them to our github landing page.

Travel/Speaking in 2013

I’m giving a talk at Portland State University on Feb 1. I’ll be in Mountain View Feb 4-8.

I’m confirmed to be speaking at PyCon March 16 about K-12 teachers and what we in the open source community can do to help them.

I’ll be speaking at a conference in Taiwan in April, and another in the US in May.

Recent talks

My most recent talk was a plenary session at LISA 2012, a USENIX conference in San Diego. It was about the false dichotomy of Education vs Training, and what we can do to improve education of sysadmins. Specifically, I gave shout outs to opsschool.org!

And…

So many other little things are going on. I restarted my sourdough and I’m reorganizing my house, one room at a time. We’re remodeling bits of the basement. We replaced a terrible light fixture in the house, and got an ESPN subscription with cable (which I love and hate at the same time). I’m reading and re-reading some lovely science fiction, at a pace of about 2 books a week. I’m walking more, catching up with family and planning things all the way into 2014.

I’m saying “no” a lot recently to doing more things, volunteering for conferences, and travel. Which, is hard.

Of all the stuff I’m working on right now, PyLadies is the hardest and the most rewarding. So, I’m making space in my life for that, for the little bits of teaching I get to do, and for connecting more women with each other and the open source communities that I love.

Code review for the new PyLadies in your life

This goes out to all the geeky spouses, partners and friends of brand new programmers:

Code review is a cultural practice.

When you sit down to read the work of another, you bring with you all the experience you’ve had up to that point, the code reviews you’ve received, the mistakes you see yourself making and the bits of hard-won knowledge embedded in your coding personality.

Basically, you bring your coding baggage into your review.

When a brand new programmer shares their code with you, they are fundamentally vulnerable. They’re sharing something creative, and like any new creative endeavor, the product is a newborn taking it’s first few, shaky steps.

They are asking for your help and very likely, they’re asking for an indication that they’ve accomplished something. That all the time they just invested in learning something new — paid off.

And, in the case of PyLadies, women are all stepping out on a limb. Some are taking a Coursera class or maybe a workshop, but mostly working alone. We have each other to learn with and we’re all learning something new. Many people are spending 2 nights a week with a group, and another 15-20 hours a week struggling through the very first programs they’ve ever written.

Here’s the very best thing you can say when a PyLady shares her code with you:

“Thanks for sharing this!”

And then, after you’ve had a look:

“I’ve had a look and you’re doing a great job. Tell me about what you’ve written.”

Seriously. That’s about it.

If the PyLady asks specific questions, give your answers. Keep it short and sweet, and encouraging.

I’m laying this out because lots of the women who are trying this stuff out for the first time have loving, geeky spouses and friends who are very excited that the women in their lives are learning to speak their languages. And some of that enthusiasm comes in the form of detailed critique of style, formatting and design.

I’m here to let you off the hook. Just be encouraging, and ask a few open ended questions. That is all you need to do.

Because the reality is: the PyLady is her own worst critic. And, when she comes to a meetup, she can get the detailed help she needs from the other women who are struggling right along with her.

The people in the group have earned the right to share and receive feedback by strugging together. That’s the value of a cohort and one reason why PyLadies, and groups like them, are so important.

If you’re lucky, you’ll get your chance to share some code back, and maybe even write something together. But you build that coding relationship one encouraging step at a time.

If you’re interested in joining PyLadies-PDX, we’re meeting weekly through December, and then starting Monthly meetings on January.

And, if you want to read more about code review in general, here are some additional blog posts I found useful: