Interview Process

Overall process

notion image

📞 Introductory call

This is a first 30-min call with 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, 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 in 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 learnt.
    • You learned a new tech stack from scratch for your past project and delivered things on production - we want to know.
  • 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 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, or how did you implement continuous integration for your codebase, or how authentication and authorisation works for the APIs that you implemented, etc.
  • Communication
    • Can you effectively describe your work in layman language without jargons?
    • Can you zoom-in and zoom-out when talking about particular technology or design decision in your project and what impact it had?

🧑‍💻 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 either be a live, pair programming round (in office or remote) or an offline exercise that you complete in your own 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 favourite 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.
For offline exercise, you are expected to submit the solution 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 upto 6 hours max. This way, you can treat it like an actual project in real world, with deadlines. Submit the solution via 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 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 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 related to rote memorisation 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 deployable state?
  • Code quality
    • Is the code easily understandable by other humans? Do the variable, method, class, 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? 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 so that it can 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), and the overall application is very slow. 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 in which the discussion goes. If the problem is too open-ended, we will ask you to focus on specific parts, thus minimising too many unknowns.
In real world, we never get the perfect requirement docs handed over to us. Instead, we have to 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 that similar spirit.

What we look for in the tech discussion

  • How you deal with unknowns
    • Ability to make progress even when there are unknowns is one of the most important skills you can develop. We want to understand you 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 down into modules that you can combine and reason about? Can you apply domain driven design techniques to model the problem domain?
    • How you prioritise requirements or features and what rationale you use.
  • How you evaluate trade offs
    • Engineering is all about context and trade-offs. We want to understand how you take 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 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?
In all the above rounds, we recommend you not to jump into a solutioning mode immediately. We want you to ask questions and seek clarifications from us 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, your ability to engage actively with us and whether you respond positively to the feedback or not.
This is how we’ll collaborate with you on a day to day basis if you decide to join us. Hence, we want the interview discussions to be a reflection of 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 over and over.
In this final round, we provide you feedback from discussions from past rounds. 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!