How we hire engineers at Classkick

Here at Classkick, we believe that publishing our entire hiring process is transparent to candidates, holds us accountable and keeps our process intentional. We also recognize that hiring is a challenging process that we are committed to improving regularly. No hiring process is perfect, but we can continue to improve and iterate on our learnings. Who we are in the market to hire today will be different from who we hire in the future because the context of Classkick will be different.

Some context about Classkick:

• We have explosive growth. The pandemic has triggered massive adoption of online learning, and many schools and districts are in need of Classkick.
• We have a small engineering team. We have less than 5 engineers, and we all wear multiple hats, from building backend APIs, to frontend UX, to infrastructure.
• We serve diverse customers. Our customers are schools all over the world with different cultural backgrounds, so we champion diversity and inclusion in our team. It’s great for people, and it’s great for building our products.
• We build products that drive curiosity and learning. The mission of Classkick engineering is to build an educational infrastructure that helps learners learn and teachers teach.

Given the context, an ideal engineering candidate for us is someone who:

• can learn and contribute quickly. Our business domain is dense but simple to comprehend, compared to more complicated domains like trading or payments. We are looking for engineers who are hungry to learn and can technically contribute.
• believes in the mission. Startup work is hard work, and having a genuine desire to push education forward is critical for being successful on the team.
• comes from diverse backgrounds. Tech companies are predominantly white and Asian males. We want to hire more people from underrepresented genders, races, and ethnicities, LGBTQ identities, and abilities because a diverse team enables us to be more resilient and learn from each other. And a diverse team builds a better product to serve our customers who are from different backgrounds.
• takes ownership. We constantly face different challenges and step up individually to drive things to the finish line.
• asks why. We encounter many problems for the first time ever with no prescribed solutions. To take optimal action, it’s important to ask what a problem really is about before attempting to solve it.
• has a growth mindset. We can always improve, and it’s important to ask ourselves “how can I do better” or “what did learn from this success/failure”. This mindset reflects in our engineering work and design.

hiring process

We optimized our hiring process based on what we currently look for. After applying via jobs@classkick.com, engineering candidates go through a 3-stage process:

• code project
• phone screen
• onsite

code project

We intentionally designed a code project that relates to Classkick. We recommend all candidates to spend no more than 4 hours on the project. We intentionally designed our project so that it can be finished within that time frame. Using this 4-hour honor system, we have a clear baseline against which we can compare candidates’ code submissions. While the code project may have drawbacks, it remains a powerful tool to assess candidates’ ability to technically learn and contribute quickly. We accept solutions in any language. While we may look at code that candidates have published on sites like Github, solutions to our own coding problem help us easily compare candidates who are solving the same problem against a fresh set of constraints.

We evaluate the code project based on the following rubrics:

• Correctness. The code can run locally without trouble on our machine (MacBook), and the code meets all the requirements in the project specification.
• Quality. The code is well structured (e.g. well-defined Classes and Interfaces), it follows good design patterns such as the single-responsibility principle. And there are no major code smells (e.g. lots of duplicate code).
• Testing. The code is well tested and demonstrates TDD (test-driven development).
• Documentation. The documentation is well-written and informs readers clearly about the project, such as how to run the project, edge cases, and potential limitations.

phone screen

The phone screen usually lasts between 30 minutes to 1 hour and we divide it into two sections: one section is to review the code submission together, and the second section is to solve a code problem together. In the first section, we provide a stage for candidates to showcase their code: how did they decide to structure the code? Was there anything they found interesting when solving this problem? The second section is not about getting to a solution in such a short amount of time. We’ve purposely chosen code problems where it would be quite unreasonable to expect anyone to complete the problem in that time frame. Rather, the purpose is to learn more about what it’s like working with the candidate. We want to create an environment where we as a group are presented with a tough code problem together, to see how we might communicate and collaborate together with the candidate at the helm.

The phone screen is our first real opportunity to assess candidates’ communication skills. We evaluate the candidate based on the following rubrics:

• Communication. Do they understand questions clearly? Do they ask thoughtful questions and communicate back patiently?
• Problem-solving. Do they solve problems based on first principles?
• Creativity. Can they come up with creative solutions?

onsite

An onsite interview generally takes 5 hours, and it can be done either in 1 day or split into 2 days. Because most people are working remotely due to COVID-19, the increased cost of doing multiple-day onsite is minimal, and we believe that giving candidates options also provides a better experience.

The onsite interview has 5 sessions: introduction, algorithm, system design, pair programming, and culture. After the 5 sessions, we will do a brief exit session with the candidate.

introduction

The introduction session is for the candidates and the team to get to know each other. We ask candidates about who they are and their work experience as an engineer. We also spend time discussing who we are as Classkick.

During the introduction, we also communicate session norms and do our best to make candidates feel comfortable. We want candidates to be their best self, and have them ask us questions. The onsite interview is also a long process, so we want candidates to have a chance to pause and take a break when necessary.

algorithm

The algorithm session measures candidates’ understanding of common data structures and algorithms. The problems are non-trivial but there are no tricks. The problems are chosen because they demonstrate our daily technical challenges.

While we want candidates to arrive at a solution, we want to understand their thought process and how they orient themselves to the problem. During the interview, we operate as thought-partners for the candidate and can provide necessary guidance to the problem. It is helpful when candidates share their thinking out loud so our team can collaborate.

We evaluate this session based on the following rubrics:

• Execution. Did the candidate understand the problem? Did the candidate solve the problem?
• Adaptability. With coaching, did the candidate improve the solution or the approach to the problem?
• Software engineering quality. Can the candidate write compilable code? Did the candidate have the understanding of data structure and algorithms that we look for?

system design

Teachers and students around the world are using Classkick, and the engineering team needs to build features to solve real user problems at scale. The system design session evaluates candidates’ technical knowledge in building a scalable product. Candidates will develop a hypothetical product from scratch.

Candidates will do most of the talking and thinking in this session, and we operate as business stakeholders and chime in with questions. The questions are technical, and we want the candidates to guide us through their solutions and backup their solutions with detailed answers. While the session requires building a hypothetical solution for a product idea, it remains an effective way to assess candidates’ ability to design scalable, industrial software.

We evaluate this session based on the following rubrics:

• Execution. Did the candidate understand the problem?
• Domain expertise. Did the candidate design a reasonable architectural solution to the problem?
• Team collaboration. Did the candidate communicate the thought process well? Did we learn something new and technical from the candidate?

pair programming

The final coding portion of the onsite is pair programming, where we work with candidates to extend their submission of the code project. This is our best opportunity to evaluate their collaboration style and get a sense of how they are as coworkers on a day to day basis.

At the beginning of this session, we ask candidates to walk through their code submission to re-familiarize themselves with their work. Although the session is called pair programming, it is important to note that we let candidates drive most of the session. Our team is here to help out when they get stuck, or when we spot spelling errors, but we want the candidate to do most of the heavy lifting.

We evaluate this session based on the following rubrics:

• Execution. Did the candidate understand the problem? Did the candidate solve the problem?
• Software Engineering quality. Did the candidate demonstrate good engineering practice, such as test-driven development?
• Team collaboration. Did the candidate communicate with us? Can we see ourselves pairing with the candidate in the actual job?

culture

The last session is focused primarily on fit for the role. It is an opportunity for other team members to get a sense of what it’s like to work with the candidate, and it is also for the candidate to get a sense of what it’s like to work with us. The conversation centers around Classkick’s core values, working styles, and past work experiences.

exit

After 5 different sessions, we close the onsite session by checking in with the candidate and listen to their feedback about our process. We also notify candidates of next steps after the onsite so that they leave the onsite with a clear expectation.

Conclusion

We’ve constructed our interview process around our visions and values. Our process has evolved and will continue to evolve over time. If you’re interested in joining a team to improve education, we’re always looking for exceptional developers of all experience levels to join our team. Check us out at https://classkick.com/jobs. We’d love to hear from you!