A couple of days ago I attended a seminar for women in technology with LadyCoders Boulder, held at the amazing offices of Google Boulder. It was a two day workshop but I only attended Saturday, as I had some other obligations this weekend. Here are the highlights, the advice and observations I felt were most critical to someone looking for work as a web developer or other technical position.
Managing Your Career
After an introduction from Ed Schwalenberg and a great story from his time working in the Antarctic, we heard from recruiter Kimberly Lucas. Kim gave general career advice on actively managing one's career, by being in the “driver's seat” instead of just a passenger. She had us work through some exercises to help us understand if we are more passive, maybe without realizing it, as well as defining what we want (and don't want) in a position. I think this will be really helpful so when I start to interview, I can go back to these core values and check positions against them. Often we fall in a trap of taking our first offer since interviewing is so difficult, which can lead to accepting a really poor fit.
Next, Kim went over her suggestions for résumés and being mindful about one's personal brand. Specifically, she emphasized the importance of being consistent with online and offline profiles, ensuring that you aren't undermining yourself on Twitter and Facebook.
- Write down what you want, don't want; compare job offers against this list
- Write down your top strengths & weaknesses so you're prepared for these questions in an interview
- Use natural language on your résumé, not business hyperbole
- Look into a “functional format” résumé, and remember it's a marketing document (not a historical record)
- Review your online brand and set a Google alert on yourself
Mock Technical Interview
The mock interview was my biggest reason for attending this seminar. Being totally new to the industry, I wasn't sure what to expect. Boy, was I surprised.
Two gentlemen from Spotify conducted the interview, Kinsuk Mishra (Software Engineer) and Howard Smith (Lead Tech Recruiter). They first reviewed what would be covered in the interview, which I found to be very CS-heavy. I'm in a training program that offers real-world job skills, and have never studied CS, let alone went to college for it. I didn't understand a lot of the bullet points on their slides, and was confused if it was concepts I didn't understand, or just the Java jargon they were using.
Something else I didn't expect was the use of a whiteboard instead of a computer. I guess I assumed the coding part of an interview would be done on a computer, but instead interviewees need to write it out on a board with their interviewer. I can see how it would be easy to be thrown off from the different tools/environment, and plan to practice whiteboarding more. We all received small portable whiteboards in the seminar, so I can keep mine in my bag and pull it out with my team when working on a group project. I think I should buy a larger one for home, too.
Their tips for preparing for the interview:
- Know most concepts in your language/framework
- Know standard data structures (arrays, hashes, etc)
- Know standard library structures
- Have a good grasp of object-oriented design principles
- Read Cracking the Coding Interview by Galye Laakman McDowell (this was seconded by a lot of the ladies in the seminar)
- My suggestion: Find a group of people that want to practice technical interviews, and someone who could conduct them so you get a feel for how they're administered
During the interview:
- Start by writing out the question and confirming you understand it correctly
- Don't make assumptions: ask questions
- Don't jump right into the code, start with higher-level design and examples
- Write out your thought process/pseudo-code
- Ask yourself: What is the interface? What functions does the API need?
- Exude confidence and be coachable
- Interviewers are typically more interested in your thought process than a correct solution
- If you know you got the problem wrong, solve it later and send it in – this shows passion and persistence (I would add: refactor your solution and send that in too!)
Advice from a Role Model
Next up was the CTO for the State of Colorado, Sherri Hammons. Sherri is a great public speaker and was really engaging and funny. She started by telling us how she oversees a lot of agencies and web applications we may love or hate, from Parks to the DMV. She gave us a brief personal bio, and I was surprised to learn she didn't get into technology until her late twenties/early thirties. She talked about early in her career, finding a mentor by seeing someone she was working with struggling with a heavy workload, offering to help bear some of the burden in exchange for mentoring. She believes mentoring is a partnership, not a one-way street, but also said not to be intimidated by experts. People who are subject matter experts often love to share and teach others.
Sherri's story was inspirational but she had some really concrete advice for us as well. “Understand the bits” of what is driving the technology you're using underneath. “We're moving up the stack – you may lose sight of what is actually going on underneath the covers.” Later in the day, John Foley with Pivotal Labs seconded this advice. He told me that if I want to deepen my understanding of Ruby, to learn C. It might seem painful, but is really worth it. She suggested we read Tubes by Andrew Blum to get a better understanding of how the internet works.
When confronted with a challenge, Sherri likes to say: “The answer's not no, it's how... when you have a roadblock and you don't try to get around it and say no, you're not going to solve problems.” This motto has changed a little bit over the years to “The answer's not no, it's how... unless I say no!” she laughed.
Another piece of advice I really agreed with was to understand the business, not just the technology. She's as successful and knowledgeable as she is because she's been involved in the business and worked in bleeding-edge technologies. It's made for more unique experiences and widened her knowledge-base.
Common Employment Law Myths
The next speaker was Amy Hartman, and employment lawyer. At several points during her presentation, hands shot up, as she was blowing our minds with the ways employers have pulled one over on us. In this post I just wanted to highlight one particular point she made, as it's very relevant to web developers. I am in no way suggesting I understand the law, am not giving any legal advice, just sharing what I heard. As always, contact an attorney to help you with legal matters.
It's very common for companies to hire someone as an “independent contractor,” with the promise to make them an employee at the end of the contract if everything goes well. Amy explained how being an independent contractor is NOT negotiable... you either meet the specific criteria under the law, or you don't. If you hire someone to just build a web site or paint a house – that's an independent contractor. If you hire someone and directly control when and how they work – that's an employee. For example, if you have to come to the office on a set schedule, sit at a desk, attend meetings, that sounds like an employee, not a contractor, right? She said you can't “try before you buy” with an employee, and in Colorado if everyone is at-will, what's the point? As an independent contractor, you're responsible for paying into social security, income taxes, etc... so if you aren't prepared to do all that, understand the risks of being audited.
Amy Ho leads the Staffing Research Team at Google, working with application data to create reports and analytics for their recruiters. She's also the Chapter Lead for Mosaic Colorado, which is a program that promotes diversity at Google. Beyond the typical race, gender, etc types of diversity, they also try to find people from different socio-economic backgrounds. They even have a neuro-diversity agenda, and recently wrapped up events on the contributions from people on the autism spectrum. Although Google receives over two million job applications each year, they review each and every one of them by humans.
When asked about what hiring staff look for, she said applicants should talk about more than just projects they worked on, but what the impacts of that project were, and what YOUR specific contributions were. When describing a problem, how challenging was it? Were you the lead or more passive? She suggested attending any Google events you can find to build a network/meet Google staff.
The Art of Networking
Last but not least, Elaine Marino spoke about how she coordinated the event, all through networking. There wasn't a single speaker or resource, including the venue, that she didn't get through knowing people, who knew other people. She said she's built most of her network from a single group, the Boulder Open Coffee Club. They meet every other Tuesday morning, and have a group that meets in Denver as well. I'm really keen to join them when I can, which might be hard until I'm out of school.
At the end of Saturday, I had four pages of notes and a pretty long to-do list. A few of us are planning to get together to practice technical interviews, and I invited someone I've met a few times at these meet-ups to come in and pair with me on my next project in school. This was the best, most robust technology meet-up/seminar I've been to yet, and I really look forward to more events by LadyCoders Boulder. Networking over alcohol is fun, but events like these leave you with tangible, real-world advice to advance your career. Thank you Elaine, for all the hard work you put into this event!