Backend Engineer — Systems & Product Engineering

We build software for problems that are not always solved by reaching for another framework or adding another API endpoint.

Our primary backend stack is TypeScript and Python. They're excellent languages for the kind of product development we do, and we use them extensively.

But we're looking for engineers who are interested in more than the stack.

We want people who enjoy understanding how things work, who can reason about systems, who learn technologies because they're curious, and who can take an ambiguous problem and turn it into a good engineering solution.

Minimum Experience: 2 Years.

What you'll work on

You'll design and build backend systems that need to be:

- Reliable under real-world failure modes
- Observable and debuggable
- Efficient at scale
- Simple enough to evolve
- Thoughtfully designed rather than assembled from frameworks
- Capable of handling problems where the obvious solution isn't necessarily the right one

Your day-to-day work will primarily involve TypeScript, Python, databases, distributed systems, APIs, queues, storage, networking, and cloud infrastructure.

Depending on the problem, we may also use other technologies. If some other language (cough cough go, rust, or even mojo) turns out to be better for the job, we have no problem incorporating it. Language is a tool. We care about whether you can choose and use the right tool.

What we're looking for

We're particularly interested in engineers who:

- Think in terms of systems and trade-offs
- Can design a backend system from first principles when required
- Understand concurrency, networking, databases, caching, queues, and failure modes
- Are comfortable reading documentation, source code, and technical papers when necessary
- Can learn an unfamiliar technology and become productive with it quickly
- Enjoy solving problems for which there isn't already a Stack Overflow answer
- Question existing designs instead of blindly following established patterns
- Can explain why a particular design is appropriate, not merely how to implement it
- Have opinions about engineering,



but are willing to change them when the evidence says they should
- Take ownership of problems rather than waiting for perfectly specified requirements
- Care about performance and can reason about where bottlenecks actually come from
- Care about the quality of work they produce, and aim for a very, very high-quality product.

We don't expect you to know everything.

We do expect you to be capable of learning almost anything you need.

The languages are not the filter

You don't need to already know every technology in our stack.

In fact, we're deliberately not making a long list of frameworks and libraries a requirement.

If you've spent the last few years writing excellent Go, Java, C++, Rust, C#, or another language and can demonstrate strong engineering fundamentals, we'd rather talk to you than reject you because you haven't used our preferred framework.

Similarly, if you've primarily worked in TypeScript or Python but have gone deep into systems, performance, distributed computing, databases, compilers, networking, or another technically demanding area, we'd like to hear from you.

What matters is what you did with a technology and, more importantly, why you learned it in the first place.

Things we find interesting

You might be a particularly good fit if you've done things like:

- Learned Go or Rust outside of work because you wanted to understand a different programming model
- Learned another kind of language, say OCaml, Haskell (ML family), or Clojure (Lisp family).
- Built a database, HTTP server, compiler, runtime, distributed system, storage engine, or other non-trivial piece of software
- Read technical papers and implemented something from one
- Contributed to open-source projects




- Built something just because you wanted to understand how it worked
- Investigated a difficult production problem all the way down to its root cause (maybe also fixing a third-party library bug, if that was the root cause)
- Designed a system where reliability, latency, throughput, consistency, or cost genuinely mattered

None of these are requirements.

They're examples of the kind of engineering curiosity we value.

What we don't care much about

We're less interested in

- How many frameworks you know
- Memorizing API trivia
- Having used exactly our technology stack before
- Collecting certifications
- Having a long list of technologies on your resume
- Saying "I know X" without being able to explain how X actually works

We'd rather see one technically deep, end-to-end project than twenty technologies listed on a resume.

How we interview

Our interview process is designed to test engineering ability rather than familiarity with a particular framework.

Expect conversations around - system design and engineering fundamentals. You may be asked to implement or modify or critique something non-trivial; we would be looking for clarity of thought, and how you approach the problem.

We may deliberately introduce technologies and problems (hopefully) unfamiliar to you. And we expect you to ask clarifying questions, or documentation if it comes to it, and then solve the problem.

Why this role

You'll have significant ownership over backend architecture and the opportunity to work on problems where engineering judgment matters.

We're not looking for people to spend their careers wrapping third-party APIs.

We're looking for people who want to build things, understand things, and make things better.

If you are the kind of engineer who learns a recent language because you wondered what it could teach you, you'll probably enjoy working here, and we'd like to meet you.

Primary stack: TypeScript, Python

Also relevant: Go, Rust, C/C++, networking, databases, distributed systems, cloud infrastructure, systems programming, open source

📌 Backend Engineer (Kolkata)
🏢 droplet.ink
📍 Kolkata