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!

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

Comments are closed.

  1. “Take conversations case by case and try not to take it personally.” is really good advice.

    Heated/passionate discussions occur on a fairly regular basis in and around IT projects. Now I don’t want to debate the merits of whether this is a good or bad thing or what could be the causes of these discussion but just to acknowledge that it does exist. It’s amazing the difference in the reactions to these discussions between the sexes.

    In one scenario two guys could be in a heated discussion and maybe it has been going on for a while, like 2 hours. One of them looks at their watch and realizes they should have already started lunch and the looks at the other guy and says “Want to get some lunch?” They grab lunch, talk about something besides work while having no hard feelings one way or the other about the heated discussion they just had.

    Now on the other hand, take 2 gals in the same scenario and the result will likely be that neither one of them will want to talk to the other for 6-12 months.

    Woman need to realize that 95 out of 100 times when a man gets into a heated discussion about IT/SW, he is not expecting you to take it personally. Guys on the other hand need to recognize these situations can be very intimidating to woman and they need to try to, turn down the heat a couple of notches, and maybe even explicitly tell the woman that he does not want her to take it personally if it looks like it’s going in that direction.

    • Thanks for the insight.

      One thing I really liked about the things the women said was that they talked specifically about their own experiences rather than generalizing their thoughts about entire classes of people.

      I caution everyone against making assumptions about what “two men” or “two women” would do in the situation you describe.

      • Sure it’s a generalization and as a SW developer where its always necessary to look for generalizations it sometimes hard to turn the generalizations off.

        Although, when I wrote my previous comment I did pause a bit before submitting it and debated whether or not to remove the generalizations but decided against it. The only reason why I even gave it a second thought was due to the comment being read mostly by woman. Making this same comment to another guy I would not have even second guessed it as I know guys don’t split hairs for “touchy” things like generalizations. On the other hand they will split hairs on technical things.

        I know another generalization and a feminine tone by saying “touchy”. But rest assure I have not meant anything negative in any of these comments I have made to this post.

        In the blog post you wrote

        “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
        …”

        but what I read was

        “How did you find your first job and know it was the right one?
        * I knew a founder
        …”

        See how I didn’t read any of the relationships and changed some of the wording. You could have said anything you wanted in the words I removed, even something very foolish and I would have never noticed. I just don’t read every word unless I force myself to do so which feels awkward. I suspect most men skip the same words I do.

        If instead of reading this blog, we were in person and you we talking to me, the words I would not have read would be moments I would be thinking about something else and would not have heard you say them.

        Now I don’t skip reading the words or hearing them on purpose, or to be rude, but it just how are brains are hardwired. Just like it is hard for us to see a magic trick even though we know it’s happening right in front of us due to our brains being hardwired to focus on events we feel are important. The magician just has to create an event the brain feels is important and we will focus on it for the brief second the trick is being performed.

        That’s why in this case I think it is somewhat “ok” to generalize some of the differences between the sexes when it points out the differences in values that we have that can lead to misinterpretations. When we understand how we can be misinterpreted or how we might misinterpret someone else we have a better chance of correcting issues that come up in conversations.

        • You just described how I read things. I am not a dude.

          The most important aspect of this conversation is recognizing the difference between personal experience and your opinions (which you know), and what other people think and do (which you mostly don’t know).

          Generalizing is where people get into trouble because, as you can see by my example, I just violated your assumptions about “what women do”.

          -selena

    • On the contrary, I’ve been on more than one team where tensions between male colleagues were high and complicated production. At one place, it became a series of passive-aggressive games, including having private meetings with our manager to sway the direction of whatever we were working on at the last minute and reverting the other’s commits to push their own instead. They didn’t even talk to each other before I got there (and they’d been working with each other for a year at that point), and it didn’t go away even after I tried to combat it with humor to lighten the mood and actually have meaningful dialogue that wasn’t arguing about which flavor-of-the-month-language is best. Even after we hired another [male] developer who had the same mindset as the other dev and I about not taking things too seriously in order to function best as a team, these tactics were still going on out of bitterness and jealousy (stubborn dev was writing bad code in a dated language and had no interest in learning another despite the needs of the company). This went on for years, culminating in the good one finally quitting because he couldn’t deal with it anymore and he didn’t deserve to. Instead of understanding or caring about what a detriment this was to our team and our morale, stubborn dev used this opportunity to act as though “he won” and instead of picking up the slack, used the knowledge monopoly he now had of our infrastructure to slack off, knowing full well our manager was completely clueless and afraid that he’d leave him teeming with liabilities.

      Meanwhile, every team I’ve been on with another woman has been enlightening.

      You see and hear these same stories all the time on HackerNews and Reddit, Github and any comments section of any dev blog. The amount of unnecessary cockiness for the sake of needing to feel above others in this industry is palpable. Also unnecessary are men like you spreading false stereotypes about “how women are” when your experience is rooted in a complete lack thereof.

      Just for the record, there are studies proving exactly the opposite of the story you made up: the more women you have on your team, the quicker the task will be solved based on the fact that women instigate communication and don’t have a problem asking questions to get there (so long as they feel comfortable in their environment). Just as studies have shown men are much less likely to ask for help, while being far more competitive and falsely confident. But since you didn’t post any studies proving that women let their emotions override their professionalism for “6-12 months”, while men can apparently take a hit to the ego in stride (despite what thousands of years of history has shown), I’m not too terribly distressed by not providing you with the sources.

      In your reply you have the audacity to say that “generalizations” are “splitting-hairs” and that only women would stoop to care about such things. By that logic, racism is splitting hairs too. I mean, talking to the white guy about it doesn’t make him uncomfortable, so what’s the problem? If only those [minorities] weren’t so sensitive, then I could go around living my life as I always have; not considering anyone else’s point of view.

      Then you talk about hesitating to post at all because of some perceived delicacy in women’s interpretations, when the reality is that you hesitated because your post has nothing to do with the actual content of this entry and was just an excuse for you to espouse your opinions on women. You even admit that this hesitancy was brought about because you assume this post will be read by more women than men. Gee, I wonder what it’s like not to have anyone batting for you or being able to empathize with your views.

      And pro tip: maybe instead of having “heated debates” or assuming that that’s somehow normal or the most effective means of coming to a conclusion, especially in the workplace, you should resort to lists of pro’s and con’s. It’s a lot more effective, and keeps you from assuming stupid things like women not belonging in software or IT because they don’t want to participate in your over-the-top dick-slinging contests.

      Selena, feel free to delete my comment if you would like. I just couldn’t be as considerate as you about this.