Last Friday, Rithm School’s seventh cohort finished the outcomes section of the course and graduated! This was Rithm’s second iteration of our in-house outcomes program, during which we had quite a few industry guest speakers come speak with students. Our guest speakers hailed from a wide range of companies from small startups like Desmos to massive corporations like Netflix. Most had substantial experience interviewing candidates, and all had sound advice to share with our students about the job search process. In this article, I have compiled what I believe to be the top three job search insights based on that experience.

1. The Hardest Parts Are Not Always Technical

The first worry many developers have when they want to search for a job is getting grilled on technical questions in an interview. Indeed, many interviews feature topics ranging from vanilla JavaScript to data structures & algorithms that are often not a big part of daily life as an engineer (unfortunately) which is a barrier for current professionals who want to find a new job. Bootcamp graduates, on the other hand, may have prepared more recently for such topics but may have issues with retaining / recalling that information due to the vast amount of knowledge absorbed in such a short period of time.

While answering technical questions correctly in an interview is obviously very important, behavioral (aka “soft”) skills are arguably more important. Here’s why…

First Impressions

In order to get the interview in the first place, you have to represent yourself in a way that makes people want to hire you. This manifests in several ways:

• having an attractive résumé (both aesthetically and content-wise)
• having an online presence (GitHub, LinkedIn, personal website/portfolio, etc.)
• having good email and phone etiquette
• being able to describe yourself and your work with confidence

These things are essential pre-requisites to take care of before starting the job search process, so you should focus on these areas first.

Some simple concrete tips corresponding to the above points:

• always keep your résumé up-to-date, even if you are not currently job searching
• push code to GitHub daily to get your green squares (solve a random algorithm for instance and commit & push it)
• take an online course, watch videos, or read articles about business & technical communication / writing
• practice your “elevator speech” (1-2 minute “tell me about yourself”) with your friends or family and ask for feedback

Providing Context for Your Background

One thing we tell students in outcomes is that everything on your résumé is a talking point that you should be able to expand upon much further in a conversation. If someone sees that you have a non-technical background, e.g. a degree in an unrelated field, you should be able to provide context regarding how you got to be a skilled developer from there, and why it adds value to who you are now. Here is an example:

My original degree is in music, which led me to intern as a web designer for a music startup. I had to teach myself enough HTML, CSS, and JavaScript to build their website as quickly as possible. That experience put me on the path to becoming a full-stack web developer, which I accomplished by attending Rithm School, an intensive full-stack training program. Because I entered development from a place of ‘how do I deliver this website’, I have always had a product-focused, big-picture perspective which is what motivates me to this day as a developer.

Note that the above example isn’t something you should try to replicate. You should figure out how to frame your own background in the best way possible that makes it yours. If your background doesn’t seem related, it’s not easy to get started; you might need to get creative. But keep yourself honest! Most people from non-traditional backgrounds that make it this far have a compelling story, even if you do not think you do at first. When in doubt, ask a friend what they think makes you unique.

Discussing Your Experience: Achievements and Challenges

Every bullet point of experience on your résumé should be backed by at least a paragraph of a more detailed explanation. I highly recommend writing paragraphs about your experience before making bullet points for your résumé. It should be challenging to condense all of your experience into bullet points. That is a great sign that you’ve done some meaningful work.

Additionally, several of our guest speakers indicated a key technique for finding out if a candidate is a good fit: for any experience item, how deeply can the candidate explain it? How detailed can they get when breaking down the exact technologies used, the problems faced, or the design trade-offs? One of our speakers specifically said that he would spend an entire interview (30 minutes to an hour) talking extensively about a single project on the candidate’s résumé, which he found more indicative than asking tech trivia questions.

A common question about experience is “what was your biggest challenge working for x?”. Questions like this should be anticipated and outlined before making your résumé. You should always start by stating why something was a legitimate challenge, and then pivoting to a positive resolution and why it was a good learning experience.

If you’re still doing your internship or working at a company, I highly recommend journaling your achievements and challenges to prepare for your next job search! In fact, this is something we require during Rithm School’s company project internships.

2. Interviewing is a Separate Skill

Interviewing is not at all similar to daily work. You can be a great engineer and a terrible interviewee. In fact, you can even be a great interviewer and not the best interviewee!

Thus, whenever you need to find a job you will either need to:

(a) level-up at interviewing for the first time
or
(b) re-teach yourself after your interview skills atrophy on the job.

Always Ask Questions

A common thread among all of our guest speakers was that they strongly wanted their interviewees to communicate as much as possible. Specifically, they wanted them to ask lots of questions. This applies to both behavioral and technical interviews. In every interview or screening, the person on the other line will say “do you have any questions for me?”. The consensus is in: you should always ask questions, never answer “no, I don’t have any questions”. In a behavioral interview, ask questions to show interest and enthusiasm. In a technical interview, ask clarifying questions to show that you break down and understand problems before you attempt to solve them.

Here are some great example questions to ask:

Behavioral Questions

• what are some problems the company or team is working on right now?
• what do you find most rewarding working for x?
• how does your company or team measure success?
• I was wondering if you could tell me more about y? (something I researched on your website)

Technical Questions

• So if I understand this right, you’re asking blah blah blah? (repeat back the question in your own words)
• Is x an example of a typical input? (ask about the expected use cases)
• Should y be the output in this case? (give example test cases)
• I can imagine z affecting my strategy a lot, is it okay to ignore this or should I design around it? (troublesome input / edge case)

There Is Only One Way to Practice Whiteboarding

You have to actually practice whiteboarding with someone. It is much harder to improve by yourself. If you don’t have any technically-inclined friends ( ), or if can’t make your schedules work, consider an online service such as pramp.

Ideally, your friend will play the role of interviewer and know the solution ahead of time, and you are the interviewee, and then you can switch roles and both benefit from it! Give each other constructive feedback.

At the very least, get a mini whiteboard and Cracking the Coding Interview, then set a 30-45 minute timer on your phone, solve a “medium” difficulty problem from LeetCode and rinse-and-repeat.

Explaining Technical Concepts

There is a difference between understanding something for yourself and being able to explain it to someone else. Maybe. Actually, as a teacher, I feel I only truly begin to understand things when I can articulate them to others! But to each their own.

Suddenly, all of your declared knowledge is on the line in an interview. You wrote “Proficient at Ruby on Rails” on your résumé, and now your interviewer is free to ask you to explain anything about Rails, good luck!

I recommend two things to prepare for this:

1. Try to explain a technical topic to your friends, even if they already know it, or if it is something that is way above their heads. If you don’t have developer friends ( ), you can try explaining it to a rubber duck .
2. Watch courses. As a teacher, I will watch courses for things that I already know because I want to see how other people, who are good at explaining things, explain things. You can check out courses on udemy with our partner Colt Steele (great explainer-of-things) or even come to Rithm School’s free weekly Meetups!

As for what to study, well there are plenty of lists of questions around, but you should also be able to explain any of the skills / tech that you’ve listed on your résumé.

3. Persevere and Keep Up Your Momentum

As Rithm School co-founder/lead instructor Matt mentioned in a previous blog post, the job search funnel is daunting, time-consuming, and emotionally draining.

Applying is a Marathon, Not a Sprint

The number one piece of advice here is to brace yourself for a long haul. You cannot predict which jobs will lead to offers. Even if you are a perfect fit, you also have to prove to each individual person in that company’s funnel that you are a good fit. AND the company has to keep the position open until you accept your offer. Companies are fickle. It is not uncommon for companies to shut down a job opening for a number of reasons: someone else accepted a position; the team realizes they need someone senior or a different skillset; etc.

Also, all of the engineers we talked to have gotten rejected several times at some points in their careers. Especially for junior engineers, rejection should be considered the default / expected result. It is certainly hard to stay motivated in the face of incessant rejection, especially since developers are stereotypically pessimistic (I mean, how can you be an optimist when typeof null === 'object'?).

There is an upside. Every screen or interview that you pass is progress. Getting a phone call back means you can get more calls. Getting an on-site means you can get more on-sites. Getting more on-sites means you can eventually get an offer. And you will actually get good at passing interviews and on-sites throughout the process. This is why a lot of people end up failing for months, but then suddenly get 2 or more offers. It turns out constant failure can be a great training mechanism, as long as you persevere!

Keep Going Until You Accept an Offer

Finally, I want to emphasize that you should continue applying until you have signed an offer. Your momentum should be like a freight train barreling forward with no brakes until your signature is down . This is because, if anything at all happens such that your current interviews do not yield offers, you will feel like you’re starting from square one at the end of your latest rejection, which is incredibly emotionally-taxing. In fact, one of the best ways to recover from a late-stage rejection is to move on immediately: “at least I have two other interviews next week”. This is why momentum is key. Also, in the worst-case scenario you have to turn down companies because you received an offer, which is a great feeling to turn the tables for once and can lead to good connections in the future.