Feb 20, 2018
What to Expect After Code School, Part 1: I Graduated! Now What?
By: Steven Bateman
Wrapping up a Code 401 course is a huge achievement. It feels like the culmination of everything that’s been set aside in the pursuit of a different career. It’s a fantastic moment to look back at the first day of 201 and realize everything you’ve learned since then. It warrants celebration and a sense of accomplishment.
Then you remember that you don’t actually have a job yet. You have the tools to get one, along with some semblance of how to use them. Still, there are little surprises all along the way about these tools: which ones turn out to be the most important; which ones you realize are more rudimentary than you thought; which ones employers expect you to have such a familiarity with that they’re basically an extra limb.
My own thoughts and experiences will vary in relevance depending on the type of job you go into, but this article should give you a better idea of the journey ahead. You’ve got your hiking gear, I’ll show you a trail.
The Job Hunt
Following my graduation from Code 401: Advanced Software Development in Full-Stack JavaScript in February 2017 and a stint as a lead teaching assistant at Code Fellows in March and early April, I decided to devote myself full-time to seeking a job. I worked on a couple of personal projects, focused on diving deep with React and Redux (Angular 1.x being the MO at the time I graduated), and made use of Code Fellows resources to branch out and seek assistance.
How personal should personal projects be?
I had two major projects that I worked on between April and August. One was called Local Tourist. At its core, Local Tourist was spawned from the idea of, “I want to go out, but I don’t know where to go, and browsing Yelp or Google reviews is not doing it for me.” The other project spawned from the NG-Adventure project done for a 401 JS assignment. It was essentially a text-based multiplayer game with real-time interaction where you explored the world via a command line interface.
I’d like to think both projects turned out quite well. It kept me active on Github and ensured I had projects I could talk about in interviews. I could discuss good workflow, my documentation, interesting problems I ran into or complicated solutions I had to work out, and how I learned technologies, libraries, and frameworks I’d never used before.
None of that happened. Not one interview or employer I spoke with had any interest in either of those projects. What I did get routinely asked about was my 401 final project, Inventory Tracker.
Inventory Tracker was born from the need for a business to have its sales platform and its inventory management software integrated so that the two would have fewer miscommunications. A business would stop trying to sell something it was out of or say it was sold out of something it had plenty of. We even built an employee-management system into it to allow different employees different access rights to managing the storefront or the inventory.
Funny enough, I really didn’t feel Inventory Tracker was the strongest representation of my coding skills. We built the back end in a week and we built the front end in a week. The front end in particular was missing a ton of features our group wanted to include and we had to do some pretty hacky stuff to just get things working enough in time to show an MVP demo. Realistically, you just don’t churn out that size of a project with high-quality code in two weeks. If an employer now asked me what I could do in two weeks, I would say a feature enhancement is realistic, not an MVP of enterprise-level software.
However, it served a business need, just like the software that probably every employer you will ever work with is going to do. It was the closest thing to “commercial work” I had on my resume, so that’s what people wanted to talk about.
It was also the only project on my resume where I worked in a group. I got asked a lot more about what my role was on the Inventory Tracker team than how good my code was. Did I play a management role? Team leader? Solution or technical architect? How much did I contribute? Did I smooth over any social issues that came up?
Pet projects or personal projects can definitely just be something fun or something you’re passionate about. However, if the ultimate goal is to have something to build on and show off to employers and to strengthen your resume, then aim for practicality. What you’re truly trying to show off is, “Here is the work I did that is most similar to what I’ll be doing in this new role.” That means something that could be useful, but mundane. It also means working in a team with efficiency and good communication. Those are the qualities you want to consider when picking out a personal project to occupy your non-resume time.
Making use of resources
The position I ultimately was hired for was actually sent to me by my wife while she was randomly browsing job postings online. However, before that ever came about, I also contacted partner companies through Code Fellows. I went to the Code Fellows reverse job fair. I hit up the WTIA Draft Day event that was pointed out to me by Code Fellows. I sought out resume review through the career coaching they offer. If a Code Fellows alumni worked at a company I applied to, I set up informational interviews with them.
Even though a lot of the resources didn’t end up leading directly to a hire, they improved my interview skills and gave me good practice and another pair of eyes on what to work on. One of the Code Fellows instructors remarked to me once, “The hardest job to get in tech is the first one.” You will need all the help you can get, so reach out and make use of everything that’s offered!
The Interview
You made it past the phone screening, you’ve been called in for an interview. Awesome! Now what?
Before the interview: research!
You will be asked why you want to work for a given company, so you need to have a better answer than, “I need a job.” You will be asked if you have any questions for them, so you need to have a better answer than, “Nope.” You will be asked how you would handle a zombie apocalypse, so you need to have a better answer than, “What?”
For a number of positions I applied to, I was told, “You will be interviewing with X, Y, and Z on Tuesday.” Guess what I would be doing before Tuesday? Hitting up LinkedIn and Googling around for information on X, Y, and Z. What were their positions in the company? How long had they been there? Did they mention any hobbies, interests, or worldviews?
Sometimes, instead of being asked, “Why do you want to work for this company?” I would be asked, “What kind of company would you want to work for?” This can be even trickier, because you’re being asked to describe a company and the employer might say, “Well, that’s not us, so thanks.” However, if you do your research and discover that every quarter they have a big “give back to the community” event, you might mention that your ideal company would be a positive influence in the community it resides in. Showing up with some casual talking points will put everybody at ease. Showing up with information about the company suggests you care if you get hired there. Showing up with questions shows you have more than a passing interest in just some job you’re planning to quit in a few months, anyway.
What do the questions really mean?
You might be wondering what was up with the zombie apocalypse question. That was a question I received at one of my interviews: “You wake up, you look outside, your neighbors are out on your lawn, one of them’s eating the other one. It’s the zombie apocalypse, they haven’t noticed you yet, what do you do?”
What you’re really being asked is more along the lines of, “How do you handle unexpected emergencies? How do you handle unexpected questions? Do you happen to enjoy zombie movies and TV shows?”
Of course, every question, no matter what it is, really ends up leading to the same point. “Can we work with you?”
Let me just emphasize that point: “Can we work with you?”
Yes, you need to have the dev skills to be able to do the job, but the reality is, people want to work with someone they enjoy having around. If you never talk to anyone, you might make people feel awkward being around you. If you’re rude, the other devs will groan if you get assigned to work with them. Even worse from the company’s point of view, you might actively prevent them from getting business if you say the wrong thing or have a poor attitude towards a client.
To be completely upfront with you, there’s a harsh stereotype in the tech industry that devs are socially inept, but very smart introverts who should probably be kept away from clients as much as possible. If you can prove you’re actually a great person to work with beyond just your tech skills, you will have a huge leg up on your competition. At the end of the interview, the employer needs to like you as a person much more than they like you as a dev.
In part 2, we’ll go over what you can expect following your first days on the job as a new developer.
We make sure our grads are ready for their job search. Check out what our Career Development curriculum covers in every Code 401 course »
Want more great content as you learn to code? See what’s new on the Code Fellows blog »
