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, Nomad, 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 ~8 teams of ~5-8 people each. Example teams:
- Family Plus team
- Activation growth team
- School Team team
- Messaging team
- Communities 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 10,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.