Last Friday was graduation day for the most recent cohort of Flatiron School students, and today is the first official day of the post-school job search process. I’m reminded of the my first day after the last day of Flatiron, when I went back into school just out of habit and a desire to continue the accelerated learning process that I had become so accustomed to. In light of that and with an eye toward helping out the newly-minted Flatiron graduates, here are a few thoughts that I hope can be useful to those who are enduring the frustration, anxiety and, ultimately and hopefully, joy of looking for a junior-level developer gig.

Don’t stress out about it!

Its easy for me to say this from the perch of employment, but anxiety about finding a job can be counter productive. If you find joy in what you’re doing so much so that you continue to do it in your free time or practice it now that school is done, the job offers will inevitably come. Stress should be a motivating factor to seek out opportunities and explore the start-up landscape; it shouldn’t devolve into worry and anxiety about where your career will go or whether or not you’ll go hungry. The best careers seem to progress in a non-linear fashion - every other step seems to be sideways and sometimes even backwards. So don’t worry if it doesn’t seem like things are going your way early on, just pursue opportunities to learn new things, continue to write and blog and be as vocal about what you don’t know and want to learn as you are about what you already can accomplish.

Know what you’re looking for

Granted, that’s not especially useful advice. Knowing what your looking for seems to be an oxymoron - if I already know what I’m looking for, why would I need to be looking for it? What I mean here is not to have in mind already what the ideal job is, but rather know what you want to be characteristics of that ideal job. Are you passionate about something other than code? Go find a music startup or media company to work at. Are you looking to build rock-solid fundamentals in test-driven development and pair program daily? Go seek out a reputable dev shop. Coming out of a school like Flatiron you have a lot of opportunities, and as all sectors of the economy rapidly digitize and incorporate technology into their products and services, the demand is outpacing the supply of new engineers and developers. And even though positive churn (i.e., developers frequently changing companies for better opportunities) seems common in the technology space, your first job as a developer will invariably have an indelible impact on your future career in technology.

There’s a whole lot more out there than Ruby…

Its clear that Ruby is the lingua franca at Flatiron, as well as many of the other new development schools that are popping up. In the real world though, its just one of many languages that are used to solve engineering problems. At the New York Times, I encounter engineers who are skilled across a range of languages and frameworks, and many do not have Ruby experience. The NYT is a truly polyglot organization - everything from Python to C to Javascript to Go are used to solve the technical challenges of the NYT. Although its great to be an unabashed Rubyist, at the same time its important to understand the criticisms of Ruby and the benefits of a more statically typed language like C or Java. For me, I’ve learned how different languages really are built for different problems, even if a scripting language like Ruby has applications beyond the web development purposes that so many people use it for today.

…Yet if you’re applying for a Rails job, know your Ruby

One thing the TAs at Flatiron really emphasized that stuck with me was the importance of knowing core Ruby rather than just Rails. Understanding Ruby will help you better understand Rails, but the opposite isn’t always true. A mature framework like Rails can sometimes make it feel like you’re just configuring a system or adding magical keywords into your classes rather than actual programming. But at its core, Rails is just Ruby code - it can be extended, modified, pushed and pulled. The more you understand Ruby, the easier it will be to understand how gems or other bits of code can integrate into a piece of software.

Plus, knowing Ruby is good just for job interviews. Most of my technical interviews were focused on Ruby rather than Rails. And if they were focused on Rails, they were typically more high-level, software design questions that happened to use Rails as the development framework. In other words, I would either get questions like, “How would you sort this array and extract just every third word in Ruby?” or, “How would you build a software platform like Kickstarter?” Knowing Ruby is instrumental (and Rails pretty useless) to answering the former. Yet the latter can be reasoned through by understanding model associations and software design, rather than knowing how to apply specific macros in Rails. Obviously, understanding Rails will be critical for building software if you go to a Rails shop, but in the interview process, its better to walk in as a confident Rubyist rather than as someone who can just program in Rails.

What I did when I left Flatiron to prepare for job interviews mostly focused on Ruby. I worked on Project Euler problems and tried building multi-class command line programs, which helped me structure my code and think from an object-oriented perspective. Tasks like trying to build a restaurant bill-splitting tool or a sports draft room via the command line can help you think about the fundamental business logic of an application and how to model your schema, rather than focusing on how the front-end looks. While building software requires an understanding of both back and front-end technologies, the core of any good engineer is being able to break down a problem into its constituent parts and to understand how those parts can be composed to build a coherent whole. These skills can be end-agnostic; the effective use of both back-end frameworks like Rails or front-end tools like Backbone.js requires an ability to structure data and process user input.

Being a developer is pretty damn fun

Sometimes I go to work thinking that its unfair to others that I get to do what I do. Learning to code and working as a developer has been an amazing and fun experience, and I’ve thus far thoroughly enjoyed working at the NYT. Yet at the same time, coding has a certain escapist quality to it. I can easily zone out for hours at a time, put on my music and just see where my creativity takes me. I’m a firm believer that the work we do should be service-oriented, despite being a profit-seeking enterprise. Developers have this great skill of solving modern problems, many of which can be addressed by using the powerful connective capabilities of the Internet and accessibility of distribution platforms like smartphones. Solving these problems (which are most often outside the strict domain of an engineer) requires not just technical abilities, but also an empathetic understanding of why those are problems in the first place.

I’ve always thought that the most fascinating problems developers are meant to solve with software are problems outside the traditional realm of software. This means that to effectively solve problems, knowing who you’re solving problems for is as important as being technically able to solve those problems. Avi talks a lot about empathy as a developer, and I think he’s really right about it. I work on a daily basis with editors who are the end users of the product I’m currently building. Empathy for the needs and interests of my clients (i.e., users) is critical to prioritizing my development tasks and knowing when to hone in on the annoying details and when to back out of a rabbit hole. While solving problems is objectively fun, it can be a fruitless exercise if those problems are not actually the problems faced by the people you’re tasked to serve in your work. Empathy, understanding, communication - these are all the soft skills that connect you back to the real world as a developer, rather than just zoning out, donning your headphones and coding away at a fantasy world problem.

Hope that was useful for anyone out there looking for a developer job. Best of luck!