Landing the Gig

I recently started as an Engineer at General Assemb.ly. The past few weeks have been really great! After posting that I was starting there, I got a request via twitter to do a blog post on interviewing, so here it is and hopefully, it’s helpful.

General Assemb.ly is actually my second paid programming position. The first, was as a developer on contract for Foodstand, a new startup powered by Purpose. My experience looking for my first position versus my second one was incredible different so I’ll go into both a bit.


The first job ever.

I’m not going to lie, this job hunt was tough! Yes, there are a lot of places hiring developers out there, however, not as many are open to hiring junior developers, especially when that junior developer has no previous paid programming employment and no CS degree. I completed an average of 5 interviews per company for my first search. Most of these interviews were short consisting of just meeting someone and having a conversation for about 30 minutes. Generally, there were two longer parts; the code part (which for me happened to be primarily a take home code exercise) and the more technical interview when we reviewed the code.

Of these five interviews, three were somewhat technically focused and two were just schmoozing and answering the same questions you would in any other interview. To get into a little more specifics, the first interview was generally just a phone screen. It had lots of getting-to-know-you questions (like “tell me a little bit about yourself”) and then some more broad technical questions. These were questions like “what does MRI stand for?” and “what is the difference between include and extend?” From what I understood, the expectation was not that I would know all the answers but that I would know some of them and exude a sense of broad general knowledge. For these, I brushed up on my ruby, went through ruby monk, took notes, and actually made flashcards to help me remember all the different pieces.

The second technical part of the interview was usually something having to do with code. Yes, I was asked to fizzbuzz with paper and pencil, but I also received a few take-home assignments. Build a bot was one. Another was giving me a set of failing tests and making them pass. These generally didn’t have timeframes associated with them and employers were open to asking questions as I completed the assignment.

The third technical part was usually reviewing this code work and/or asking some more in depth questions. They usually started with “so, walk me through how you attempted to solve this problem” and then conversation branched into different subjects from there. I, personally, didn’t have any interviews that involved pairing which I was relieved about at the time (but changed my opinion on that for my second search).

So, now here are some general tips and thoughts.

First, for my first job hunt, I did not apply to a single job where I didn't get a soft introduction meaning that at no point did I blindly send a resume to a company. This is where being involved in the community is really important. At RubyConf, I met a ton of people in person. My primary job hunt strategy was posting on twitter where incredible people made amazing introductions for me. It is rare, I think, for a company to hire a junior developer just from a blind resume drop so these intros were really priceless.

Second, I was very careful about interviewing them as much as they were interviewing me. While I wasn’t picky about what industry I was looking to be in, I was picky about the type of environment and culture I was looking for. Furthermore, as a women who is new to developer but has major career accomplishments pre-career transition, it was important that I not sell myself short and find a company that recognizes both my future potential but also current worth as an employee. I asked potential employers a lot of questions about support provided to junior developers, what sorts of structures and systems they have in place to foster learning, and other questions I felt were important as I made this transition.

Third, you should hear about positions and decisions quickly. Yes, there were a lot of interviews, but generally, there was a less than 3 day turn around time for scheduling the next interview. There is such a desire for developers these days that companies know that even if I’m not the right fit now, I might be in the future. Therefore, I found that companies are pretty transparent and quick to let you know if you’re moving forward or not… which is a welcome change from my last industry where you’d interview and then wait a month to hear if you were being offered a position or not.

Fourth, think about what you want out of this first position. I know a lot of newer developers who start as QA engineers, project managers, sales engineers, and other positions that involve code but aren’t specifically developer or engineer roles. When I interviewed at these positions, I was very careful to ask about the path to transitioning and becoming a full-time developer because I didn’t want to get stuck and I didn’t want my professional developer to be siloed away from the other developers. I was also pretty adamant about getting a developer role as opposed to one of the roles mentioned above but either path is fine, as long as you have asked the right questions, are clear with what you want your end goal to be, and are comfortable with being in that role.

The final piece that I think I realized more in hindsight that when I was looking for a position is that if I walked out of an interview feeling stupid, or awful about my abilities, then it was not the right place for me. Mostly, I felt interviews went well and it was great to meet lots of different developers and talk to them about what they were working on but sometimes, I left an interview feeling completely awful, like an idiot, and like I would never ever ever find a job. The places that made me feel that way, probably would have also made me feel that way if I was on the job and made a mistake or didn't know how to do something. An important thought to keep in mind when you’re slogging your way through.

The position I ended up with was great for me at the time. It was a full time contract position in a subject matter I was very interested in. The dev culture was just starting to develop so I was able to have an impact on what that looked like. The team seemed really great and while I was a little concerned about being the only fulltime developer on the project, there was outside support and structures in place to provide more support once I started. This was a great position for me at the time. I was there for 4 months with my contract being extended a few times. In the end, however, there wasn’t enough senior-level support so I felt my learning was moving as quickly as I knew it could.

Onto the second hunt.

This job hunt was completely different. After I got my first position, I continued to stay involved in the community. Others around me knew how much I was learned and I had shown that I was able to succeed as a developer so when I started looking again, I didn't have to look very far. I actually didn’t even launch a full job search. I spoke to two local companies I was interested in and General Assemb.ly. The other primary difference is that this time I had 1-2 interviews for each company as opposed to 5. At all three companies, I had great initial conversations. For the local ones, the interviews were relaxed because they had seen me progress over the last few months. At one, I had worked with most of the developers already in informal capacities so it was nice to already know a majority of the team. At the second company, I requested to go into the office to pair to get a better sense of what learning from the developers there would be like. At the third company, I had a soft introduction but didn’t know the folks there as well. I had a great initial conversation and then was set up to pair with two of the senior developers. These sessions were great. At one, we went through an old piece of code and discussed how I might refactor it. At the second, we looked at a piece of code and just discussed how I’d get a sense of what the code was doing and then we worked on a test and a method. And that was that… all the places I spoke with and all the interviewing I did.

The second time around, interviews were also so much easier because I had real experiences to pull from. The one thing that was a bit more tricky was being able to show code. The first time I looked for a position, I had just been building sites or projects and had everything on github. The second time around, I had progressed significantly in my coding abilities but EVERYTHING I did was private and I couldn’t share any of that code so it was challenging to prove how much I had grown. A nice work-around that someone suggested to me was to focus on blog posts instead. I tried to make time to blog about challenges or things I learned at work so, while I wasn’t able to show code, I was able to show a blog post and talk a bit about the related challenges.

In the end, I received offers from all three companies. It was a really really tough choice but General Assemb.ly seemed like a really great fit. I thoroughly enjoyed their interview process (and, I mean, who enjoys an interview process?!), enjoyed the pairing I did, and they’ve got great structures and ideas in place for developers to keep learning and challenging themselves.