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.

Interesting Reads 5/24 - 5/30

There's a whole boatload of good stuff this week! First, There are links to three more talks from RailsConf. Then another talk about leveling up. After that a few interesting blog posts. Finally, agood explanation of dotfiles.

Enjoy!


Sean Marcia is awesome and this is his great talk about Bees and saving the world: http://www.confreaks.com/videos/3318-railsconf-saving-the-world-literally-with-ruby-on-rails

Harking back to my management days a bit, this is a good talk about decision making and team working in tech: http://www.confreaks.com/videos/3487-railsconf-workshop-teamwork-ain-t-always-easy

Okay, I think I've only made it through 5 databases so far but interesting overviews: http://www.confreaks.com/videos/3374-railsconf-an-ode-to-17-databases-in-33-minutes

Another talk, but not from RailsConf, about taking your engineering role to the next level: https://www.youtube.com/watch?v=lgxEmiMJVq4

Information anxiety and how to parse through what you need/want to learn: http://blog.codinghorror.com/keeping-up-and-just-in-time-learning/

Great post on mentorship: https://medium.com/theli-st-medium/have-some-coffee-9e468d958e77

Interesting post on coding principles every engineer should know. Do you agree? Which would you add?: https://medium.com/on-coding/coding-principles-every-engineer-should-know-b946b48cc946

Lastly, this week I had to set up my first new computer for development. A friend passed this along to me. It's a great step-through of dot files which, I think, seem super intimidating, but aren't IRL: http://code.tutsplus.com/tutorials/setting-up-a-mac-dev-machine-from-zero-to-hero-with-dotfiles--net-35449

Interesting Reads 5/17 - 5/23

Lots of really great links this week. There are a few more RailsConf talks since I had a chance to watch a few more of those this week. Some great posts on terminal and keyboard shortcuts and tricks, and some fun team-related posts.

Enjoy!


Amazing tips and tricks in this post for keyboard shortcuts.

AND amazing tips for terminal in this one.

Leading a team is really hard. Jessie does a great job talking about some of the ways to actually be a GOOD manager.

Some great tools and thoughts for thinking from railsconf.

Love this! https://speakerdeck.com/aviflombaum/20-things-i-love-about-code

A really interesting talk about imposter syndrome

I've always looked at the stages of group development in the context of leadership groups and immersion experiences but this is an interesting post on the high performing team dynamic in programming

Does the size of a team affect the quality? This post talks about some of the data behind it.

Building Analytics

A key part of any build is figuring out what colleagues want to track and how to effectively manage that data. In this case, there is a lot of stuff to track. I recently finished building a hefty analytics components to the app and wanted to share my approach and some things that drove me crazy.

First, I had to really think through which analytics were important. The initial ask was for about 30 different types of analytics, but then, when adding in timeframes, and additional category components, we were talking about close to 400 queries… not super useful for an early launch. Additionally, through my experience with Neighborsations, I could look at these requests and know which ones were most important for raising funds, for identifying user paths, and which ones wouldn’t really be useful until we had a larger critical mass using the application. I also made sure to ask my team what the most important success factors were to them (ie- if this number isn’t what we want it to be, then the business is not successful and we need to make some hard choices, quickly… that’s actually a vital part to determining core metrics and something I learned from Steve Wendel who’s awesome at pushing you on those hard questions.)

The easiest way to do the queries was through writing DB queries, putting them into a model with methods and then creating a view. The app is an ember-appkit-rails app which kinda mushes the rails api and ember together but I decided to keep this simple and just run everything outside of the ember piece and just keep it as typical rails.

There were also a couple of options for running the number… we could have done a rake task or set up a chronjob. Right now, the approach is just to have the business folks hit that page whenever they want new numbers (with the understanding that they shouldn’t hit it too often because it kicks off a bunch of queries that hit the database).

To seed the data, I was originally leaning towards factory girl but decided to start with just creating the data I needed in the tests. What I didn’t realize is that the app automatically pulls in fixture data, so everytime I had a to eq it would fail because the number would be incorrect. That taught me… after spending probably too much time trying to figure out how to not have the test pull in the fixtures, I realized I should just embrace them, learn how to set up the fixtures for my tests correctly and use them to generate the data I needed.

Then I created a model with the class AdminAnalytics. Each analytic was a separate method. I think if I wanted to go back and continue to refactor further, then I could easily break the model into separate classes. For example, instead of having one overarching AdminAnalytics class, it would probably make more sense to have a Users class, a Posts class, and Ingredients class, etc.

Then it was down to the queries. I didn’t have much SQL experience and some of these queries were pretty complicated so it helped me to first write out all of the steps that I was looking for before translating it into an actual query. Once I did that, I could take those queries and use ActiveRecord to give me the rails magic that made the queries a little easier. For example, when joining tables in queries, you don’t have to note the join table… you can just note the two tables and activerecord will figure out the relationship between the two tables on its own. Then, because a lot of the queries involved profile type names or time parameters, I refactored by making those things arguments on the method that could be put in place in the view.

Then I created a controller which was literally one line and was able to create a view that just called the instance variable @analytics and the method with whatever arguments I needed. Bam! Analytics.

Now, once this was all done, we actually decided to pull the analytics out of the app. Instead of bundling these things together, we made it a separate app entirely that talks to the primary app in order to get the numbers needed. When we pulled it out, we used sequel which made it easier to pull those queries in (although still more difficult than just doing it right in the app). The nice part about the app was being able to use ActiveRecord but it also made the analytic piece dependent on a bunch of different models. For example, to get the total number of users, you just do User.count or to get the total number of posts, Post.count. You’re already depending on two different models here, User and Post. So, part of pulling this piece into a separate app was so that we were no longer relying on multiple models in order to get these numbers.

The other thing I really wanted to do was set up a simple dashboard using Dashing. I’d seen people whip these dashboards up in no time flat, so I figured I’d take a stab at it… boy was I mistaken. I think my journey to a dark place started with the decision to use dashing-rails instead of dashing. See, I figured, if I used dashing then I would have to create the connections to the database in order to get the information for the queries I was running. If I used dashing-rails, then the dashboard would be a part of the app and this part would be easier. (If you’re thinking about the paragraph above and thinking, wait a second, you pulled the whole thing into it’s own app anyway in the end, yes. I realize this and boy is hindsight 20/20). Dashing-Rails involves a bit more setup. You’ve gotta set up concurrency, you have to use a database that has lots of threads like puma, etc. The issues started there and just didn’t stop. First, I had an issue with puma and so I upp’ed the number of threads possible and that seemed to fix it. Then, there was a database connection issue. The DB connection would time out almost immediately. We got this working as well, but it still times out. After a certain number of rounds, the thing just kicks the bucket. Then, I had an issue where all my dashboard widget boxes would show up but nothing would show up in them. Sometimes, if I commented things out and then reimplemented them one at a time, they would work again. And there was no rhyme or reason about when the dashboard would start up and kick off, versus when it wouldn’t.

So, here’s the really annoying part. I FINALLY got the issues fixed (with the help of lots of pairing with a few different, very patient people) and pushed the dashboard to production, where everything promptly broke and nothing rendered correctly. Then we got it rendering correctly, but the queries still aren’t running correctly. All the while, I’m kicking myself because I was the one who said, “oh, and I’ll build this awesome dashboard to go along with the simple analytics view. It’ll be fun and shouldn’t take too long.” I think the dashboard was mostly a lesson in when to give up. I should have scrapped it after the first week and a half, but I was a little too stubborn and a little too determined to get it done.

So, that’s how I built the analytics. For my final thoughts, I think the moral of this story is to always keep it simple. Start small, get that shipped and continue to add and improve.

Interesting Reads 4/5 - 4/11

Some really good reads this week on a variety of different topics.

Enjoy!

Read on effective flows

Conference proposals and a good step-through process to create your proposal

Really in depth thoughts on crafting a talk

Improv and coding

Scientists and Code reviews

Write Code Everyday. I talk about this a lot in regards to learning to code. This post breaks things down really well.

Ember for Children

I thought it was nice that this session was included in the first ever Emberconf. With so much information to cover and so many interesting components of the technology, it was nice that the organizers made sure there was a talk that focused on the community and what we can be doing together for underserved communities in technology. Highlighting an achievement like this, really shows that even though we’re cranking out amazing technology, building the community is important and giving back is core to that idea.

DeVaris Brown (who also does ember hot seat) talked about a new initiative he’s launched which takes at risk youth and teaches them about programming and code. He started by talking about the bootcamp idea (something I have mixed feelings about and have written on before) and wanted to provide a bootcamp-type opportunity to high school students that wouldn’t be able to afford something like that. He walked us through the curriculum he used to teach these students, the time he put in, and where the students were today. He worked with Black Girls Code and other organizations to find students. He also spoke honestly about the challenges he faced like reasons students couldn't come to class or the basic typing skills necessary (for which he recommended typing.io).

DeVaris received a standing ovation and got a lot of questions from people on how they can help and get involved. I think it’s great that the community is so interested in providing these opportunities and focusing on these sorts of initiatives. I hope that they can work together and some of the already established organizations to make more things like this happen instead of trying to reinvent a new initiative.

RetroRuby4 What's Next? Presentation

Here are my slides from retro yesterday! Enjoy!!

Building a Bot

I recently mentioned in my mentorship goals that one of the things I wanted to quickly dive into were databases. There are a variety of database types and ways to work with them. I was able to get an introductory handle by looking over Learn SQL the Hard Way and doing some additional research but databases are difficult to understand until you really start doing work with them.

At the same time, the bot in an IRC channel I often use was acting up. Basically, the bot was/is pretty much broken and needs to be restarted but no one knows who is actually able to restart the bot. Chris and I decided that a great first project for us to work on via the mentorship program would be to build a bot and to add a database component to it.

So first, what is a bot? A bot is a program that you can connect into a chat room (in this case an IRC channel) which will then respond to different conversations or things happening in the chat room. Most workplaces I’ve spoke to that utilize hipchat, campfire, or other internal chat communication tools have some sort of bot that hangs out in the room as well and makes it more entertaining. It’ll pop up funny gifs or respond to things people say. It can also be useful by providing information about testing or alert the room when someone deploys code.

My bot’s name is Rosie. She’s awesome. I’ll write up a few posts in the future that describe more about what she does but for now, I just want to go over the setup. First, I used cinch. Cinch is a great, easy way to set up a bot and gives pretty straightforward instructions that get you moving quickly.

This is what the setup code looks like.

bot = Cinch::Bot.new do 
  configure do |c| 
    c.server = 'irc.freenode.net' 
    c.realname = 'Rosie' 
    
      c.channels = ['#rosie'] 
      c.user = 'rosie_' 
      c.nick = c.user 
  end

Now, to walk through each line.
The first line bot = Cinch::Bot.new do creates a new bot using cinch. This new method takes a block.
In the next line configure do |c| , we are in the block configuring the method. This method also takes a block and passes in the cinch configuration for the bot which means it passes in a reference to itself that you can configure.
The third line c.server = 'irc.freenode.net' shows the server we are connecting to.
Then c.realname = 'Rosie' is the real name that will show up when someone asks who is in the IRC channel.
Next, c.channels = ['#rosie'] is the channel that the bot connects to. Right now I’m just testing her out, so I have her connecting to an independent channel that no one is using.
Coming to the end, the 2nd to last line c.user = 'rosie_' gives the nick name of the bot that will show up in the channel.
And finally, c.nick = c.user sets the nickname to the same thing as the username.

So, there’s the initial setup. I’ll do future posts on both functionality and integration of a database, as well as one on what is IRC in general for those not familiar with it.

Mentorship Goals

As many of you know from past posts, I was recently awarded Chris Sexton from the Arlington Ruby group as my mentor. I say awarded because it’s been going really great and I think he’s awesome. I’m so glad Chris is my mentor and we’ve been meeting regularly to make sure I’m learning what I want to. This brings me to my next point, as many of you also know, I think it is very important to set goals. In addition to setting goals for myself so that I can achieve them, goal setting is a vital part of a mentor/mentee relationship. Part of being an effective mentee (I’m going to do a full post about this in the near future) is making it easy for someone to mentor you by being proactive and knowing what you want to learn and accomplish.

One of the first things I did, before chris and I even had a chance to sit down for our first meeting, was let him know what my goals were during this time period. These goals have already changed once or twice and I can always continue to add new goals as we go along, but providing Chris with my goals sets us up for success. I know I’m going to learn a lot and he knows exactly what I want to focus on to learn.

Here are the goals I sent him:
- Pair program at least once per month
- Determine projects to work on (building off of what I have already done and building new things)
- Feel more comfortable with defining my abilities
- Feel comfortable with looking at/thinking about projects that are in progress (not just building rails apps from scratch)
- Learn more about databases and become more comfortable working with them
- Determine how to set good programming goals (there's so much to learn, how do you determine what gets you to the next level and how to get there)
- Commit to OSS

I’ve already started my first project with him of building a bot! The bot is going to be awesome and we’re going to incorporate some information that needs to go into a database in order for me to really get a better sense of working with databases, how they work, and what problems might arise when using them. I’ll definitely be doing some posts soon on the process of building a bot.

The One Where I Get a Mentor

I am excited to announce that I’ve been selected as one of the first mentees for the new Arlington Ruby mentorship program! There is a lot of informal mentoring that goes on in Ruby communities which is really amazing, but sometimes it’s really difficult to get a mentor. Sure, there are lots of people you can ask questions to but having a more formal mentor is different. Knowing that time and dedication are required also makes it more difficult to ask someone to commit to you in that way. It involves both the mentor and mentee developing goals for what they want to learn and both people are invested in the relationship and progress.

Arlington Ruby has recently formalized their mentorship program. The goal of the program is not just to connect new programmers with experienced ones and it is not to just benefit the two people involved. The program involves peer mentoring and a lot of thought into how the mentors and mentees will additionally contribute to the rest of the community. You can check out the official guidelines here. In the meantime, I’m super excited to have Chris Sexton as my mentor!! For the next six months, I’ll ask him hundreds and hundreds of questions (he may not know what he’s gotten himself into) and I’m looking forward to developing some goals and posting about my progress and what we work on here.

Thanks Arlington Ruby for putting some serious thought into how to continue to make the Ruby community even better. Hopefully other Ruby groups will copy this format and it’ll become a way to build stronger local communities for all of us.

On Accomplishing Goals

I've always been a listmaker. I use evernote to take ideas and things down. I make lists for everything and I keep a running weekly to do list for what needs to be done. I have it listed as Monday, Tuesday, Wednesday, etc. through weekend with an "other" underneath for things that should be scheduled in future weeks. On Sunday every week, I look at my upcoming week, my meetings, and my projects and try to balance my days. I've done this with every job and every project I've ever done. 

To do lists for coding and development are way more difficult. I LOVE crossing things off of my to do list, and when your to do list involves coding projects, you are just less likely to cross stuff off your list, let alone be able to cross a bunch of things off your list. So, to help with this, I've also been making 6-8-week goal chunks. For example, at the beginning of August, my first set of goals included finishing a few specific tutorials, "building something", and making a decision about if, after the 6 week, I would continue working on my former startup or continue doing just development and stop working on that site (the "former" suggests what I decided to do).

I was super excited this time around because I accomplished almost all of my 8 week goals in just 5 weeks! These goals included establish a blog, post on the blog often (at a minimum twice per week), build something that teaches me some javascript and jQuery, shadow at a few companies, learn how to and then build a technical resume, and speak at a ruby meetup. The only goal currently not accomplished is get a job... so, I'm still working on that one. But, it looks like it's time to set some new goals and maybe think bigger for the next set.