This is a collection of frequently asked questions about engineering at ClassDojo that we shared with candidates as a way to both cover recurring topics and to encourage questions.

What’s the stack at ClassDojo?

• Web frontend: React / TypeScript
• Backend: A “majestic monolith” JSON/HTTP API server written in Node.js/TypeScript (our framework is mostly homegrown, based on koa). Teams generally have clear ownership of different parts of the API.
• Other services: We use Golang & node.js for services that don’t make sense in the monolith (like cpu-intensive things, or things that need to go behind a queue). We do not default to separate services or micro-services though.
• Platform: AWS (Terraform, EKS (K8s), Consul)
• Databases: MySQL/Aurora, Mongo (though we’re migrating away), Redis
• iOS: Swift (iOS 15+, UIKit, SwiftUI, CoreData)
• Android: React-Native

How are we organized?

• We currently have ~20 teams of ~5-8 people each. Example teams:
  • PayPlus team
  • Teacher Growth team
  • School team
  • Communication team
  • Tutor team
  • Accounts team
• Our teams do change over time as we grow or move in different directions as a company
• The teams are cross-functional with each team usually having
  • Full-stack developers
  • Mobile developers
  • UX designer
  • Product manager
  • Data scientist

Do we follow a software development methodology?

• Our approach is inspired by Kanban, mostly.
  • Agile, but not scrum: We don’t do sprints, and don’t do traditional estimates.
• Daily stand-ups. Weekly prioritization meetings. Retrospectives twice a month.
• We pursue Continuous Deployment very aggressively, deploying many times per day in almost all codebases.

How are we different from most engineering organizations?

• Heavy focus on automated testing, production monitoring and quality in general, especially quality measures that keep us fast. (eg. Heavy production monitoring makes Canary Deployments possible, we have 14,000+ tests on the API that run in less than 3 minutes)
• Low reliance on human inspection: Pull requests are neither mandatory nor blocking in most cases. We hire people that care about quality and collaboration, and we don’t want to police it.