Founding Software Engineer

Why MOOV exists Students walk into their buildings, hallways, and classrooms completely unaccounted for. As recent-ish public schoolers, we know the drill: put a backpack on, look the part, blend into the crowd. Teachers took attendance manually. They gave us blocks of wood and tissue boxes for hall passes. Finding one student meant logging into an attendance portal, calling into a classroom, and hoping. We also know what it's like to hear about a school shooting and start texting friends, wondering if you'll get a reply. MOOV is our hope to make schools safer and seamless. It's an entirely new category in education technology: a student movement OS. You cannot take one step into a MOOV school without noticing our impact. Anyone entering the building, a classroom, a bathroom, or a common area moves with MOOV. We are changing the culture of schools: from manual tasks, afterthought safety, and declining attendance, to automated attendance, accountability increased 10,000x (yes, that's a real number), and students earning points for getting to class early. A principal at one of the biggest high schools in America was asked what would happen if MOOV were removed. He said his school could not function. Security Directors have said verbatim that MOOV "is a need, not a want." We grew 252% last year, and we're breaking into some of the country's biggest districts, all without a sales team. Our mission is a relentless pursuit to reshape the schools that shaped us: saving time and saving lives. The job MOOV is hardware and software in the same product. A student taps a card in a classroom in California. A few hundred milliseconds later, an attendance record has to be right, a hall pass has to start counting, and an administrator's dashboard has to reflect it. When it's wrong, someone is wandering in a hallway and nobody can say where. This role is mostly backend. The interesting problems at MOOV are underneath the screen: the ingestion path that takes tap events off thousands of devices, the sync layer that reconciles them against student information systems that were not designed to be integrated with, the provisioning and fleet health of hardware sitting in buildings we don't control. Front-end work exists, and you'll do some of it. It is not why we're hiring you. Engineering at MOOV has been deliberately small, which means the scope in front of you is enormous: entire surfaces of this system are unclaimed, and you will own them from your first month rather than your third year. You report to Kevin, and you build alongside him. Own backend surfaces outright. The SIS integration layer, the event pipeline, or device provisioning and fleet health. Yours end to end, not yours to assist on. By month three Kevin should not be reviewing your work line by line, because he doesn't need to. Make the tap path fast and correct at real school-day volume, with roster data as it actually arrives: duplicate IDs, three date formats in one file, a district that renamed every room over the summer. The messy rows are not an edge case. They are the job. Keep the fleet honest. Readers, kiosks, and handhelds sit in buildings, on networks we didn't configure, 2,500 miles away. You'll care about what a device does when the Wi-Fi drops for six hours, and you'll be able to tell the difference between a firmware problem, a network problem, and a school that moved the Reader. Be further out on AI than Kevin is, and he is already out there. We want the person who shows up with the thing he hasn't seen yet: a better harness, an agent setup that actually holds up against a real codebase instead of a demo. If your answer to "what's changed in the last month" is what everyone else's answer is, you're not the hire. And be able to do all of it with the tools switched off. AI is how fast you go. It is not how you think. We will sit you in front of an unfamiliar system with no assistance and expect you to read it, find the thing that's wrong, and write the correct fix. Anyone who can only operate through a model is a liability here. What you're walking into We'd rather you hear this from us than find it in week one. This is a young engineering organization and you are early in it. Decisions a larger company made five years ago have not been made here yet: how we test, how we review, what deploys look like as the team grows. You'll be in the room for those, and sometimes you'll be the one who makes them. If you want a system where all of that is settled, this is the wrong job. The product is live, renewing, and running in districts every school day. What it hasn't been is built by more than a handful of people. How we'll both know it worked By week two: you've shipped to production. Something small and real, in front of users, without anyone holding your hand through the deploy. By month three: you own a surface outright. You've taken something that only worked because someone knew how to hold it and made it work on its own. By month six: you've made the codebase easier for the next engineer and can point at exactly what. You've killed at least one whole category of support ticket with a product change. MOOV is shipping more per week than it was the day you started, and a meaningful share of that is yours. This is a fast-track role. We check in formally every 30 days, and the honest ceiling on this seat is leading engineering at MOOV. We promote execution, quickly, and we'd rather build our leadership team out of people who earned it here. Who you are You're better than us. We don't have to push you; you push us. You're asking us to keep up.You care deeply. Not about "the platform" in the abstract, but about whether a specific kid in a specific hallway is accounted for.You ship. 1-3 years shipping software professionally, or a shorter track record with unusually strong evidence of finished things in front of real users. Side projects count. Coursework doesn't.You're high agency. A district goes live in 14 hours, the sync is failing, and the person who owns that vendor's API is unreachable. You move.You take accountability. When something breaks that wasn't technically yours, you fix it first and sort out whose it was later. You have a specific story like this ready, because it's how you already work.You debug as a discipline: form a hypothesis, test it. You don't change things until it works and then move on.You're obsessively curious. A device that won't provision is interesting to you, not someone else's problem.You scope before you execute. Handed something unfamiliar, your first move is finding out what it actually is, not two confident hours in the wrong direction.Your questions have specifics in them. "The eSchool sync dropped 40 students last night, all from one building renamed in the SIS. Is room mapping keyed on name or ID? If it's ID I can fix it now, but tell me if something else depends on that."You use AI as leverage and own the output. If a prompt misses something, that's your miss, not the tool's. You can tell us about a time AI got something wrong and you caught it, because you were checking.You're confident without needing to win. You'll push back on Kevin with evidence, and take a "no" without wilting or sulking.When a problem repeats, you build the fix instead of getting faster at the answer.You're legible to people who don't write code. You'll sit ten feet from the people who talk to districts every day, and they need to understand you.You're credible in a school building. Some of this work happens on site, in front of a technology director who has been sold to before.Helpful, not required: firmware, IoT, RFID or NFC, or device fleets. Building against a messy institutional system with a committee behind it. Being a first or second engineer somewhere. The hours, and why This job is in our Brooklyn office at 15 MetroTech Center, five days a week, 7am to 7pm. Why 7am? That's when our schools start. Why 7pm? That's when schools on the West Coast end. When something breaks, it breaks during a school day, and the engineer is not asleep for it. You'll also be out at schools with us several times a month, travel covered. We are flexible and accommodating, but we are not aiming to be good, or even great. We will be the greatest system a school has ever used. Lives are on the line. We believe we can help prevent the next school tragedy. This is what it takes. Compensation We'll offer you a choice between three packages: more cash and less equity, more equity and less cash, or somewhere in the middle. Base: $150,000 - $190,000Equity: 0.30% - 0.50%Early-exercise stock options for tax benefits Benefits Health, dental, and vision coverageLunch every day, and dinner if you're here lateDaily commuter stipend; school and conference travel coveredUnlimited PTOAccess to whatever tools you need, plus a monthly book budgetRelocation stipend if you're moving to New York for this How hiring works Intro call, 25 minutes with Kevin.In person with Kevin, a conversation, not a presentation: walk us through one thing you built end to end and one bug you solely caused, in real detail. We want to see how you think out loud.A paid day in our office. You spend a full day with us building against a real MOOV problem: a stream of tap events, a roster file with the messiness ours actually have, and a question the product has to answer correctly. We pay for your time because we're asking for real work. Ask us as many questions as you want, and walk us through what you built at the end of the day. This is the part we weigh most heavily.References, then an offer, usually within 48 hours of your day with us.