Interview Process

Overall process 📞 Introductory call What we look for in the first call 🧑‍💻 Programming exercise (Pair Programming or Offline exercise)What we look for in the programming exercise 🖥️ Tech discussion What we look for in the tech discussion 🤘 Final discussion

Overall process

📞 Introductory call

This is a first 30-min call with the One2N core team to see if we are a right fit for each other. Fitment is a two-way street, we understand that just like we are evaluating you, you are evaluating us.

What we expect from you:

Ask any specific questions about the company, work, job expectations etc., that are not already covered elsewhere

Go through our website and job description before the call.

What you can expect from us:

The interview panelist ensures they go through your Resume before the call

We will ask specific questions about your contribution to the project, how you learn new things, etc.

Typically, the call progresses like below:

Introductions - panelist introduces themselves, and we ask you for your intro (~ 5 mins)

We give a brief about One2N and job expectations and answer any specific questions you may have (~ 5 mins)

We ask you to describe your past work, or we talk about a relevant problem based on your experience. Here, we want to know your own contribution to the project/work you have done. This is your chance to talk about challenges you faced and overcame, technical details about the project, etc. (~ 15 mins)

Final comments or any further questions along with next steps (~ 5 mins)

What we look for in the first call

Curiosity

Are you genuinely interested in technology? If yes, you’ll love what we do at One2N.
If you’re not, and you’re not honest about this with us (and yourself), you may not enjoy the learning-oriented environment at One2N.

Ownership demonstrated in your past work experience

You led a team that moved a business metric - tell us how it went and what you learned.
We want to know if you learned a new tech stack from scratch for your past project and delivered things on production.

Willingness to learn (and un-learn)

Nobody knows everything. Do you know areas that you’re good at? How about areas that you’re not so good at?
Can you be open and honest about this, and do you have the right attitude to learn things continuously?

Technical competence

Can you answer the “why” and “how” questions related to things that you worked on?
e.g., why choose a particular database for your backend, how did you implement continuous integration for your codebase, how authentication and authorization work for the APIs you implemented, etc.

Communication

Can you effectively describe your work in layman's language without jargon?
Can you zoom in and zoom-out when discussing particular technology or design decisions in your project and their impact?

🧑‍💻 Programming exercise (Pair Programming or Offline exercise)

Based on your background and the first call, we expect you to write code for a problem statement. This can be a live, pair programming round (in the office or remote) or an offline exercise you complete in your free time.

The typical duration for a live programming round is about 1-1.5 hrs max. We will let you Google search syntax and use your own favorite IDE when solving the problem. From our side, we will also share any pre-requisites beforehand (e.g., setup a skeleton CLI project in Go or Java with unit test libraries). If you have never done pair programming before, please read this.

We expect you to submit the solution for the offline exercise within a week or two. It should not take you more than 4-6 hrs straight to complete the solution. In fact, we would like you to time-box the effort to up to 6 hours max. This way, you can treat it like an actual project in the real world, with deadlines. Submit the solution via the GitHub link + Demo. We expect you to do your best and honest attempt (and not plagiarise or copy the codebase from someone else).

For Site Reliability Engineer role, the problem statement can be

Write infrastructure as code using Terraform

Write Ansible playbooks for automating some tasks

Write a simple CRUD API and deploy it using simple automation on VM/docker

Deploy a common web application stack (e.g. LAMP stack) on AWS (or the cloud provider of your choice)

Write CI, CD code for a sample web application repo

Create helm charts or Kubernetes manifest files for a typical backend application stack

Write bash scripts for automating common tasks on Linux VMs

Live-debug why an application deployed on AWS using ALB + VMs is not healthy

For Software Engineer role, the problem statement can be

Write a simple REST API for a specific problem domain

Write code for a simple Linux CLI utility

Solve a standalone, code-kata style small enough problem statement with unit tests

We try our best to make the programming exercises as close to the actual work we do in practice. Thus, we don’t ask you questions about rote memorization of data structure or algorithms (no reversing linked-list or advanced graph traversal algorithms). Instead, we focus on practical applications of tools and principles we use daily in our job - object-oriented and functional programming, clean coding principles, API and database design, automated testing, one-click deployment, CI/CD automation, everything (infra, config, security, policy, code build) as code, etc.

What we look for in the programming exercise

Code correctness

Is your code doing what it is supposed to do? Code that works is better than beautiful code that doesn’t work.
Does your git commit history indicate smaller commits that are always in a deployable state?

Code quality

Is the code easily understandable by other humans? Do the variable, method, class, and module names reflect the intent?
Is the code well documented? (document the why, not the what)

Test cases

How do you know your code does what is expected? Have you written test cases to prove that it works?
Quality of tests, understanding of unit vs. integration tests and their trade-offs

Presentation

Code formatting, following the language or tool conventions
Does your project have a good readme.md file that describes the details about the project, assumptions made, open todos, setup instructions etc?

Demo

Have you submitted a 5 min video demo showing your code, test cases, and working API?

🖥️ Tech discussion

Based on your performance in the previous round, we may choose to schedule a tech discussion with you. This is where we want to see how you can design a system end-to-end.

In this round, we typically cover open-ended problem statements. We want to find out whether you can think like a CTO and design something from a one-liner requirement. This round typically requires 1 hour. For this round, we expect you to share screen and collaborate to identify the requirements and architect a solution.

For Site Reliability Engineering role, the problem statements can be

How will you “productionise” a monolith application deployed on a single VM manually? Assume there’s no CI, CD, security, infra automation, scaling, etc., in place.

How do you go about making systems reliable? The target is to go from current availability(typically unknown) SLO to 99.5 percentile.

How can you implement a Continuous Integration and delivery practice for a new micro-services based project?

Given a typical backend application (monolith APIs + background workers), how will you architect it to scale out?

For Software Engineering role, the problem statements can be

Design a REST API and backend database schema for an OTP based auth system.

Design a patient-doctor appointment booking system

Design data model and APIs for an online B2B eKYC use case

We have a typical three-tier application (JS frontend + REST API + relational DB), which is very slow overall. How will you figure out the problem?

We purposely keep these problems open-ended. We want to understand how you deal with unknowns, identify the core from the fluff and focus on what matters. You are encouraged to ask questions and control the direction the discussion takes. If the problem is too open-ended, we will ask you to focus on specific parts, thus minimizing too many unknowns.

We never get the perfect requirement docs handed over to us in the real world. Instead, we must work with various teams (frontend, backend, product, business, compliance, customer success, operations, etc) to ideate and reach common ground. We like to conduct the tech discussion in a similar spirit.

What we look for in the tech discussion

How you deal with unknowns

Making progress even when there are unknowns is one of the most important skills you can develop. We want to understand your appetite for dealing with unknowns.
We want to understand how you make certain assumptions or use pre-fabricated components (e.g., Redis, Elasticsearch, etc.) for typical use cases in the problem domain.

How you discover things that matter

Can you break a problem into modules you can combine and reason about? Can you apply domain-driven design techniques to model the problem domain?
How do you prioritize requirements or features, and what rationale do you use?

How do you evaluate trade-offs

Engineering is all about context and trade-offs. We want to understand how you make pragmatic decisions.
There’s always an opportunity cost associated with everything. We want to understand how you reason about it. e.g., piling up tech debt vs. having a very good codebase, launching MVP vs. big full-feature release, etc.

Communication

How effectively can you articulate your thought process, decisions, known unknowns, etc?
How do you respond to changing customer requirements, and how it impacts your design?

Apply technical knowledge for practical use

We want to know how and whether you can apply your previous knowledge and experience to build something from scratch.
Just knowing technology is not enough. Can you apply it in practice to solve a problem that is unfamiliar to you?

We recommend not jumping into “solution mode” immediately in all the above rounds. We want you to ask questions and seek clarification regarding the problem statements. If you make assumptions about the problem, make sure that you validate those assumptions with us.

Apart from technical implementation and problem-solving skills, we are also evaluating your collaboration skills, ability to engage actively with us, and whether you respond positively to the feedback.

This is how we’ll collaborate with you daily if you decide to join us. Hence, we want the interview discussions to reflect our day-to-day mode of operation.

🤘 Final discussion

Congrats! you have made it through. Our expectations from the previous rounds may have seemed a bit hard. We acknowledge that nobody is perfect and we all make mistakes. What matters is continuous learning and not repeating the same mistake repeatedly.

In this final round, we will provide feedback from past rounds' discussions. If we decide to offer you, we will make you our best offer and share the appointment letter. Looking forward to working with you in One2N!

Back to

Next to