Rithm’s final interview is comprised of a 30 minute behavioral interview followed by up to a 90 minute technical interview. Learn more about our final interview here.
The technical interview
What pre-requisite knowledge do I have to have before the interview?
NaN, nested loops, and callback functions.
What we do test is for problem solving and your ability to talk through a solution to a problem, and then write the code necessary to solve the problem. In order to assess for this, we do not allow you to run your code and use tools like
console.log. The purpose here is to make sure that when you write code, you understand what that code is doing. If there are bugs in your code, we’ll ask you to step through your code and tell us what is happening during each line.
What can I do to prepare for the interview?
- TIme yourself as you code, and aim to solve each new problem a little faster than the last. This will help you get comfortable coding under time pressure.
- And perhaps most importantly, practice whiteboarding or writing out problems by hand. ✍️ It will make a big difference in your speed / comfort-level during the interview. You can find some tips on whiteboarding here.
How long is the interview?
The technical part of the interview usually lasts for up to 90 minutes. About half of that time will be spent working through coding challenges, while the other half will be spent getting to know you better and answering any questions you may have.
What is the format of the interview?
Interviews are held one-on-one via Zoom, with your camera on and screen shared. They typically consist of 2-4 technical coding problems to be completed in the code editor of your choice. During the interview, we will ask you to do a virtual version of whiteboarding, meaning you will be solving coding problems without running your code.
We find that new learners often pick up bad habits such as:
- Beginning to code before they’ve thought out their problem-solving approach
- Relying on
console.logto constantly test their code
- Reaching a solution that may work, but not understanding why the solution works
Whiteboarding is meant to address those bad habits. We want you to think about the problem in front of you in human terms before you ever touch your keyboard. Once you understand what’s required of you, use pseudocode to map out what your solution should do. When you think you have a working solution, practice “being your own computer”—step through each piece of your code manually, explaining to your interviewer what should happen when you run the code. This will help you identify logic errors or bugs. This problem-solving approach is extremely helpful and will serve you well in bootcamp and beyond.
Why do you do whiteboarding interviews?
Whiteboarding is extremely common in the software industry as an interview technique. It is certainly not always the best measure of a person’s professional competence or qualifications for a role; however, as a coding school preparing developers to enter the tech industry, we want to make sure our prospective students are ready to handle this interview format from the get-go, because at the end of the cohort, students will inevitably have to whiteboard again for a number of job interviews.
Who will interview me?
Every interview is conducted by a member of our instructional team.
How difficult is the interview?
We might give an easy/warm-up problem, and then a couple of moderate to difficult problems. On Codewars, they would probably be 5th or 6th kyu; on LeetCode they would be considered “Easy”, although this is a vague approximation, and everybody has a difference frame of reference for what is considered easy or hard.
What are you looking for in the interview?
There are a handful of criteria we use to evaluate candidates in an interview. The most important criteria are:
- Problem solving ability: Can you think abstractly, ask critical questions, understand the problem statement, and come up with a viable solution?
- Behavior and communication: Do you exhibit professionalism, do you communicate your thought process effectively, can you articulate what the code should do, can we tell that you understand the problem?
- Coachability: Are you willing to accept input and feedback from your interviewer and possibly adapt your strategy to hints or suggestions from us? Do you learn quickly? What kind of student will you be when you enter the program?
What if I get stuck?
No worries, everybody gets stuck sometimes! Simply let your interviewer know where you’re at. Make sure you tell him/her what you understand already and what you think you need to learn to get unstuck. We don’t consider getting stuck a big problem unless you just sit there and don’t say anything. However, getting stuck more than a few times can be an indication that you may need more preparation.
Also, we are always willing to help out if you forget how some methods work or make a few syntax mistakes. As long as we can see you are doing your best, we won’t hold it against you if you forget, for example, that the
.splice() Array method returns an array of the removed elements.
If you have any questions about the technical portion of your interview that weren’t answered above, feel free to reach out to email@example.com for support. To learn more about your final interview, click here.