Introduction
Interviewing is right up there with public speaking in the hierarchy of fears for most people. Not only are you performing for someone else but they’re actively judging you the whole time… yikes!
Far be it from us to try and get you over that psychological hurdle but it’s definitely best if you can actually treat the interviews as a chance to show off the cool stuff you’ve built and the interesting new skills you’ve learned. The best interviews are enthusiastic conversations with technical depth.
The first step before everything is to prepare. You’ll want to figure out the questions you might expect to be asked (and the general responses you’ll have for each which demonstrate your brilliance) and you’ll want to research the company too. Your knowledge of the company will help you tailor your pitch to their needs and also allow you to ask intelligent questions about their product and technology when the time comes. Again, refer to the Happy Bear article for some great general job hunting tips.
How the process works once you’re in the funnel
Just a quick overview of the process a typical tech company will go through when hiring developers:
- Phone Screen
- Technical Interview
- Technical Challenge
- Fit Interviews
- Job Offer
- Offer Negotiation
- Offer Acceptance
The phone screen
Congratulations! Your resume wasn’t a total train-wreck and they’ve invited you for a phone screen (note – sometimes you actually do the tech challenge first). The real purpose of this screen, which is often roughly a half hour with someone from Human Resources (not the actual hiring manager), is to make sure you’ve got a good chance of passing their technical interview and fit interviews. So consider it a light version of each of these.
You’ll probably be asked about some of the technical things you’ve listed on your resume but not actually dive into the depths (though some places do a brain teaser too) and you’ll probably be asked some more “softer” questions about why you chose the job and what you’ve done before. Companies vary widely in how they use the phone screen. The basic tactic here isn’t a tactic – be honest and enthusiastic and open. And don’t be afraid to practice talking about yourself in front of the mirror.
FINAL NOTE – this is not one-size-fits-all and many companies skip the light stuff and dive right into a technical screen so you’ve got to be prepared just in case! The Coding Horror link below is more descriptive about that case.
The tech interview
The technical interview is usually the most terrifying part of the interview process. It’s where they will assess whether you’ve got the technical chops to make it. That means you’ll not only be asked very specifically about the work you’ve done, but also to solve logic problems or code live or whiteboard some new features.
In fact, one point of the interview is often to push you to your limit just to see how you react to not knowing something. If you do an exercise too easily, they’ll go to a much harder one. Especially as a beginner, you will hit a lot of stumbling points. The biggest asset you have is honesty and intellectual curiosity.
When solving a problem, make sure to do so in a clear and logical way, explaining out loud why you’re doing each step. Talk through your roadblocks and give examples of how you’d find the solution in the “real world”. Often, that answer would be to Google for some particular function. Say so! They know you’re not a Ruby/JavaScript expert, but they need to know that you’ll be able to seek out solutions to the problems you’ll inevitably encounter on the job.
It’s also totally okay to use a brute force (inefficient) solution to a coding problem. That’s often the best place to start, just so you can be sure you’ve got the right feel for the problem. You’ll usually be asked how you can make the solution better, but that’s much better than trying for a brilliant solution and running out of time with no work to show for it. Again, your job isn’t to be brilliant as much as to be adaptable and thoughtful in the face of challenges.
And if you don’t know something, it’s better to say so and work with your interviewer to figure it out. Trust me, they want you to succeed as much as you do because there’s nothing tougher as an interviewer than seeing someone silently crashing on a problem and getting more and more frustrated but not asking for help or providing any window into their thoughts.
You’ll need to read up on a variety of things that weren’t focused on in the previous few courses, including data structures and algorithms, just because they’re favorite targets of interviewers. They may not be great indicators of coding skill, but the world is stuck in its ways and you’ll be asked those more “Computer Science-y” questions.
Links
- Peerfect.net free online practice for behavioral, technical, and coding mock interviews with peers.
- Exponent.com allows you to prepare for coding interviews and practice your coding skills with peers.
- Interviewing.io gives you a chance to practice tech screens anonymously online.
- Interview Tips
- How to Ace Your Technical Interview
- How You Can Stand Out in Your Next Web Developer Interview
- Post on The Interview
- Read 40 Key Computer Science Concepts Explained In Layman’s Terms
- Google’s Guide for Technical Development (advanced)
- Ruby on Rails Popular Job Interview Questions
- Cracking the Coding Interview is OPTIONAL READING and it has the potential to be your best friend. It comprehensively covers all the kinds of challenges you might face in a coding interview. It goes beyond the scope of what we’ve covered so far in this curriculum and touches on other subjects that are good to know because they will probably come up.
Coding test questions:
- 8 Queens is a classic problem.
- Coding for Interviews: Know Thy Standard Libraries may be a bit of overkill for a junior, but never hurts if you’ve got the time.
- Project Euler has more generic and challenging problems that must be solved efficiently (they can be very computationally intensive).
- Code Wars has programming problems and examples of best practice. Join ‘The Odin Project’ clan for allies.
- HackerRank provides challenges, drills, and competitions on algorithms & data structures.
- LeetCode also has some great resources, with problems, explanations, and challenges. Best of all, you don’t have to create an account to view the questions.
The real value of the sites mentioned above comes from engaging with them productively. A popular recommendation around the internet is to just “go grind Leetcode.” As you’re aware of by now, common algorithms typically have a “trick” or a specific set of steps in order to get to a solution. When you are preparing to interview, the value and utility of wrestling with a problem for hours/days is little. It is more productive to search for the algorithm/pseudocode, then practice problems that require awareness of that algorithm.
This would be like being tasked with getting the length of a Hypotenuse in a triangle but having no awareness of the Pythagorean theorem. Without awareness of that theorem, that calculation can feel impossible. But just knowing the “trick” makes getting the result easy.
A more practical programming example:
If you arrived at a problem that required awareness of a Depth First Search of a Tree, but you had zero awareness of what a Depth First Search is, sitting there for days trying to arrive at a solution will yield little benefit. In that situation, it is more productive to just search common tree algorithms then return to the problem that was giving you difficulty.
Algorithms training:
- Udacity course on Algorithms (asynchronous)
- Coursera course on Algorithms (semi-synchronous)
- Visualgo visualizes many common algorithms to help students better understand data structures and algorithms.
Architecture:
The tech challenge
The take-home tech challenge may occur before or after the in-person screen, depending on the company. They will give you an application or problem which will take up to a full day to complete on your own time. Examples of take-home tech challenges include building out a sample web app with tests or solving a challenging algorithmic problem using code.
They’ll evaluate you on the completeness of your solution and the quality of your code. If it occurred before the technical interview, it’s a good mechanism for them to test your commitment (up to half of people never even turn in a solution).
The final step: “fit”
The final step before the final decision is usually to meet the whole team and get put through the paces at their offices over the period of several hours. They’ll probably test you technically but the goal is also to make sure you’d be a good person to work with. If any one member of the team doesn’t think you’d be a good fit, you usually won’t be hired. Advice? Don’t be weird or awkward even if you are at home :)
It’s also a chance for you to test them out. If you’ve gotten this far in the process, there’s a reasonable likelihood that you’ve got a good match. You’ll need to figure out if this is the kind of company you want to work for so bring a list of questions and make sure they get answered.
A note on compensation
Be mindful when providing your salary expectations. Companies will always ask you “how much do you expect to get paid”, often in the initial phone screen. Providing a single concrete number can be the opposite of beneficial, because you may offer a number higher than their range and thus be deemed too expensive, or you may have come in too low and they now know they may be able to cap your offered compensation at a lower number than they might have. It’s safest to provide a range (e.g. “I am looking for something between $80,000 - $90,000.”) in order to better meet their budget and also allow some wiggle room for negotiations.
Once you have an offer, you can check it against fair market rate by asking other people (hopefully you’ve got some people by now who you might ask) or going to the below resources to compare. While “junior” doesn’t equate to being underpaid, do be mindful to adjust for years of experience (0-1) as to get the most accurate picture.
Finally, if a recruiter has reached out to you, it can also be helpful to ask what the budget for the role is up front. However, this must be done tactfully. If you have not been asked your compensation expectations and have not been told the budget up front in the initial message, it can be a great way to understand if both parties are wasting each other’s time, but do keep in mind that asking must be done in a respectful manner. It can be helpful to phrase this ask by saying, “Is there an allocated salary range for the role?”. Sometimes they may reply that the salary is based on experience, so do keep in mind your range as you move through the interview process!