We're hiring our first ops person. Here's what we wrote.

A job description is a mirror. Before a single candidate reads it, it tells you what a company actually believes about people, work, and trust.

We spent a long time writing ours — not because the role is complicated, but because getting it wrong would be expensive in ways that don't show up on a spreadsheet. This post is that process, made public: the job description itself, the interview we designed, and an honest accounting of what we refuse to do.

Why now, and why this role

Brightgoal is a SaaS product for study-library owners across India. We build the infrastructure they run on — slot assignments, seat and locker management, payment collection, GST bills, renewal reminders, pro-rata refunds. We've been shipping for a while. The core product is stable, real libraries are using it, and real money is flowing through it.

That's exactly when a company like ours gets dangerous.

When things are working, it's easy to fall in love with your own assumptions. You stop asking the uncomfortable question — is the thing we built actually solving the thing owners care about? — and start asking the comfortable one — how do we grow faster? The two questions look similar on a roadmap and feel completely different on the ground.

We need someone whose entire job is to stay close to the ground truth.

The person we hire will talk to owners every week. They'll help new libraries get set up, sit with them through their first few billing cycles, and surface the patterns that don't make it into support tickets — the confusions people solve themselves, the features they work around, the moments where they almost gave up and didn't. That intelligence is worth more to us than any A/B test.

They'll also own the operational scaffolding that lets us do this at scale: onboarding checklists, support workflows, a feedback system that actually routes insight to the people building the product. Not glamorous. Absolutely essential.

The job description

We wrote this once, rewrote it twice, and cut anything that sounded like we were describing someone impressive rather than someone useful. Here's what's left.

1. 1

   You know at least 15 owners by name.

   Not just their library names — their situations. Which ones are growing, which ones are struggling, which ones have asked for a feature we haven't built yet.

2. 2

   Onboarding runs without you holding it.

   A new owner who signs up today can get to their first paid student in under a day, following a process you designed and documented.

3. 3

   We have a feedback loop that works.

   The product team is receiving structured owner input at least once a week — not raw messages, but organized patterns with enough context to act on.

4. 4

   You've surfaced one thing we didn't know.

   Something real owners experience that we didn't know, or didn't take seriously, before you started. This is the most important one.

How we'll interview

We've thought carefully about this. Most interview processes are designed to protect the company from bad hires. That's the wrong frame. An interview process should give a serious candidate enough signal to know if this is a place they want to work — and give us enough signal to make a fast, confident decision.

Here's exactly what ours looks like.

1. 1

   Application review (us, 2 days)

   We read every application. You'll hear back either way — within 48 hours. We don't believe in the silence that passes for a "no" at most companies.

2. 2

   A short written screen (you, 30 minutes)

   Three questions over email. One is about a past experience. One asks how you'd handle a specific owner scenario. One is an honest question about what you want from this job. There is no trick. We're reading for clarity of thought and evidence that you've thought about the role, not that you've rehearsed a persona.

3. 3

   A paid work sample (you, 2 hours, ₹500)

   We'll send you a real — anonymized and sanitized — set of owner feedback messages. Your task: make sense of them. What patterns do you see? What would you tell the product team? What would you tell the owner who sent the most frustrated message? This is compensated because your time has value and we want serious engagement. It also gives you a preview of what the job actually is.

4. 4

   A conversation (both of us, 60 minutes)

   Not a quiz. A real conversation about what you saw in the work sample, how you think about operations, what you want to build professionally. We'll talk about the company — the real version, including the parts that aren't smooth yet. You should leave knowing whether this is a fit. So should we.

The way we won't

There are things that have become standard in hiring that we believe are bad for candidates and bad for companies. We're naming them specifically because we want you to know what you won't encounter here.

• No unpaid multi-day assignments. Asking someone to spend a weekend on a case study is asking them to pay for the privilege of being considered. We pay for the work sample. If we ever need something more substantial, we commission it properly.
• No panel interviews that feel like interrogations. You'll talk to two people, total. Anyone else who has input on the decision will review written material, not sit in a room making you perform under scrutiny.
• No trick questions or brain teasers. We are not testing whether you can solve a logic puzzle under pressure. We're trying to figure out if you'll be good at this job. The work sample is as close as we get to a test — and it's a real task from the real role.
• No ghosting. Every application gets a response. Every candidate who reaches Stage 2 gets a real close. This is the minimum we owe anyone who takes time to apply.
• No 'we're a family' language. We are a team, not a family. You have a life outside of work. Healthy boundaries make everyone more effective. If we ever use family metaphors to justify unreasonable expectations, hold us to this paragraph.
• No hiring loops that drag on for weeks. Four stages. Three weeks total, end to end. If we're taking longer than that, something has gone wrong on our side and we'll tell you.

What a JD tells you about a company

We've been thinking about this a lot lately — the way a job posting functions as a signal, independent of its content. Candidates are sophisticated readers. They clock the gap between "we value work-life balance" and "must be available evenings and weekends." They notice when the responsibilities section is three times longer than the compensation section. They feel the weight of a JD that asks for five years of experience for an entry-level salary.

A badly-written job description doesn't just fail to attract the right people. It actively attracts the wrong ones — people who are experienced at playing a game, not experienced at doing a job. And it repels exactly the kind of thoughtful, honest professional you actually want, because they read the JD carefully and correctly conclude that this company doesn't know what it wants.

We tried to write a JD that treats the reader as a serious adult. We tried to design an interview that tests real judgment, compensates real time, and closes with real information. We might not have gotten everything right. But the intention is transparent: this is what the job is, this is what we'll pay, this is how we'll make our decision, and this is what you can hold us to.

A few honest admissions

Brightgoal is small. There are things about working here that are better than a large company and things that are worse.

Better: you will see exactly how your work connects to outcomes. When an owner stays because you onboarded them well, you'll know it. When a product decision changes because of feedback you surfaced, you'll have been in the room when it happened. There is no layer of management between you and the people building the product.

Worse: we don't have all the processes figured out yet. Some things that exist at larger companies — formal career ladders, structured performance reviews, a dedicated HR team — don't exist here in a polished form. You'll be building some of them as you go. If that sounds exhausting, this isn't the right role. If it sounds like an opportunity, read on.

The libraries we serve are run by real people — often a librarian who opened a space to help students in their town study for competitive exams. UPSC, SSC, railway exams, state-level boards. The stakes are real. The families paying ₹500 or ₹1,500 a month for a seat are making a real sacrifice for a real aspiration. The software behind that experience should work cleanly, and the company behind the software should treat its users like adults.

That's the job.

Apply

If this role fits where you are professionally — or where you want to be — we'd like to hear from you.

Send us an email at brightgoal.in@gmail.com with the subject line Ops role — [your name]. Include two things: a short note (a few paragraphs, not a formal cover letter) on why this role, why now, and what you've done that's most relevant; and a CV or work history — whatever format feels most honest.

No referrals required. No LinkedIn Easy Apply. Just an email, written by you, about you.

We'll read it and respond within 48 hours.