How We Approach Backend Development

We believe backend engineering is about more than just writing code — it’s about building resilient, observable systems that can gracefully handle the messy reality of sales communication. Our team practices defensive coding and rigorous testing not because we’re paranoid, but because our customers rely on Close to capture every call, email, and SMS without fail. Every pull request goes through automated checks (unit, integration, and end-to-end tests) before a human review, and nothing merges without a passing build in our CI/CD pipelines. We invest heavily in monitoring, logging, and alerting so that when something does go sideways — and it will, eventually — we know about it before our users do.

We’re also pragmatic about architecture. We default to simple, modular Flask services that do one thing well, and only pull in something like our TaskTiger-based asynchronous infrastructure when a workload clearly benefits from it. You won’t find cargo‑culted microservices here; we split a service when it makes operational or team‑scaling sense, not because a blog post told us to. That said, we’re not afraid to adopt new tools when they solve a real problem. Recent examples include leveraging Kafka (via AWS MSK) for event‑driven communication between critical domains and experimenting with gRPC for select internal services where performance and type safety matter most.

What Success Looks Like in Your First Six Months

We know that ramping up on a complex codebase and a fully remote team takes time, so we’ve designed an onboarding path that sets you up for meaningful contributions without feeling overwhelmed. Within your first month, you’ll have shipped at least one small, scoped improvement — it might be a performance tweak to a slow MongoDB query, a new endpoint for an internal tool, or a production‑safe refactor that reduces tech debt. You’ll pair with a dedicated onboarding buddy and participate in your first on‑call rotation (with a shadow, of course), because we believe nothing accelerates understanding like seeing how the system behaves under real traffic.

By month three, you’ll own a complete feature from design through deployment, working closely with product and frontend colleagues to reconcile technical constraints with user needs. You’ll have deep‑dived into at least two of our core data stores — maybe optimizing an Elasticsearch index mapping for faster search, or partitioning a PostgreSQL table to keep maintenance windows reasonable. Around the six‑month mark, we’ll look for you to be a go‑to person for a specific component of the backend, actively participating in architectural discussions and mentoring newer team members. Throughout this journey, your manager will focus on removing obstacles and providing candid feedback, not micromanaging your schedule.

Our Commitment to Developer Autonomy and Growth

Close was built as a remote‑first company from day one, and that philosophy extends to how we manage engineering work. We don’t do daily stand‑ups that feel like status theater; instead, we rely on well‑written design documents, asynchronous communication in GitHub issues and Slack, and a culture that assumes good intent. If you need a block of uninterrupted focus time to explore a tricky concurrency problem, you block it on your calendar and the team respects it. We also give every engineer a generous annual learning budget — whether that means books, online courses, or attending a conference like PyCon or KubeCon — because we know that stagnant skills benefit no one.

Beyond formal learning, we encourage internal knowledge‑sharing. Engineers regularly host brown‑bag sessions on topics ranging from deep dives into how PostgreSQL’s query planner works to practical Type‑Driven Design in Python. We have a strong tradition of contributing back to open source projects we depend on, and several team members maintain their own popular libraries. Career progression at Close doesn’t force you into management to increase your impact and compensation; our technical track lets you grow as a Staff or Principal engineer while staying close to the code, guiding technical strategy, and mentoring without losing the hands‑on work you love.

Our Interview Process

We’ve designed our hiring process to be thorough but respectful of your time, and to evaluate the skills that actually matter for this role — not to see how many algorithms you’ve memorized. After an initial 30‑minute chat with a recruiter to answer your high‑level questions, you’ll have a 45‑minute technical conversation with a senior backend engineer. This isn’t a whiteboard drill; it’s a collaborative discussion about system design, data modeling, and trade‑offs you’ve made in previous projects, using a shared online document or a simple code snippet. We want to see how you think, not whether you can invert a binary tree under pressure.

If that goes well, you’ll move to a paid, take‑home project that mirrors a realistic backend task — perhaps building a small API that integrates with one of our data sources, complete with tests and a brief write‑up of your design decisions. You’ll then walk us through your solution in a 60‑minute review session, where we’ll discuss alternatives, error handling, and how you’d evolve the feature over time. Finally, you’ll meet with a few more team members across functions (product, engineering management) for a culture‑add conversation. The entire process typically takes two to three weeks from application to offer, and we’re committed to providing transparent feedback at every stage.