Associate Product Engineer — DeepDive (Markopolo AI)

Associate Product Engineer — DeepDive (Markopolo AI)

About the Role

DeepDive is an AI-powered social listening and narrative intelligence platform built by Markopolo AI. It helps brands track what people are saying about them across social media and news, then turns those conversations into clear, actionable insight on a live dashboard.

This isn't a role for someone who wants to write tickets and wait for instructions. As an Associate Product Engineer on DeepDive, you'll own features from the first "why are we even building this?" all the way to the code sitting in front of clients. Nobody hands you a finished spec. More often than not, you're the one writing it.

Inside three months, you'll have production code live and a real say in how analysts, marketing, PR and brand teams experience DeepDive. We mean this literally, not as a someday promise. The bar is high, and the milestones below are specific.

We're looking for someone who writes code because they like making things people use, who cares about why a feature exists as much as how it's wired together, and who is a little sharper at the end of each week than the start. If that sounds like you, keep going.

What You'll Do

Write full-stack features across our TypeScript monorepo: Next.js and TypeScript on the front end, Node services on the back, and Python where the scraping and annotation pipelines live. Clean enough to hand off, solid enough to ship.

  • Own features the whole way: understand the problem, scope it, build it, ship it, then actually watch what happens after launch. The pull request is the easy part. The outcome is yours.

  • Throw together prototypes and MVPs to test ideas quickly. Get something rough in front of real analysts, learn from it, and iterate. Early on, learning fast beats polishing slowly.

  • Work close to the data pipeline (scraping, conversation merging, the two-stage LLM annotation flow) and care about whether what lands on the dashboard is actually correct, not just present.

  • Sit with designers, PMs, and the founders while they make product decisions, and have an opinion when you're there. Pick up bugs across the stack without waiting to be asked. If you see a bug first, it's yours until you fix it or hand it off properly.

  • Tell the team what you're learning from users. The engineers who matter most here are the ones who notice what's confusing people and say so out loud.

  • Leave a trail. If it isn't in the PR, the ticket, or a doc, then as far as the team is concerned, it didn't happen.

Requirements

We receive many applications for this role. Here's what separates the ones we actually interview:

  • A bachelor's in Computer Science, Software Engineering, or a related field, or equivalent demonstrable skill. 1-2 years of experience; internships, freelance work, and serious personal projects count.

  • Proof you can build. Show us something real: an app, a tool, a side project, an open-source contribution, a hackathon win. We want to see code you wrote and a thing that runs.

  • Real coding ability. You're fluent in at least one modern language (TypeScript/JavaScript, Python, or Java) and you'll learn ours quickly. Our stack is TypeScript end to end with Python in the data pipeline. Knowing it already matters far less than being able to pick it up.

  • Product sense, not only engineering sense. You think about the person using the product, not just the feature. Put a screen in front of you and you can say what's confusing and why.

  • Foundations in system design. You understand databases (SQL and NoSQL), APIs, and how the parts of an app fit together. Bonus if you've touched data pipelines or third-party data/APIs, since much of our work is moving messy real-world data from source to insight. You don't need to have built at scale yet, but you should know the building blocks.

  • Use AI as a force multiplier, not a crutch. We expect you to move fast with AI tools, but the thinking stays yours. You can explain why your code works, defend the decisions behind it, and catch where the model got it wrong. Velocity should never come at the cost of clarity.

  • An agile mindset that survives a bit of chaos. Requirements change. Priorities shift. We ship fast. You roll with it and you don't get precious about code you wrote last week.

  • Accountability without anyone reminding you. You flag your own blockers, keep track of your own work, and turn up with solutions instead of just problems.

Nice to Have

This is not a rough guide, it's the standard we hold Associate Product Engineers to. At day 90, your manager conducts a formal review against these milestones. Strong performance leads to a permanent Associate Product Engineer offer. We share this upfront because you deserve to know exactly what you're signing up for.

Days 1–30: Learn

Month one is not a gentle ramp-up. We expect you to write real code in the first week.

  • Clear onboarding: policies, Code of Conduct, security, and data-handling in your first few days. We handle client social data, so the privacy of that information matters.

  • Get your first PR merged into production by day 5. Small and real is fine. It just has to be live.

  • Ship small, reviewed changes to production at a steady cadence, a mix of bug fixes and small improvements across the dashboard and pipeline. We care that you're getting code through review regularly and getting comfortable with our deploy process, not sitting on long-lived branches. Every change tested and reviewed, no rubber-stamps.

  • Take a core product flow you didn't build (a dashboard module, or a stage of the annotation pipeline), map how it works end to end, and write it up clearly enough that the next new hire could learn from your doc alone.

  • Use DeepDive the way a paying client would: set up a brand, run a feed, read the dashboard. Come back with at least 8 specific friction points, and for the worst 3, a concrete idea of how you'd fix them.

  • Day 30 review: you walk the team through a part of the codebase you didn't write, say, how a conversation goes from scrape to merged record to annotated row, and explain how it actually works. If you can't, we'll both know you weren't looking closely enough.

Days 31–60: Build

Month two, the training wheels come off.

  • Own and ship at least two small-to-medium features scoped, built, tested, and deployed: a dashboard widget, a new filter, a pipeline improvement, and your call with your manager.

  • Tests are not optional and not an afterthought. Whatever you ship, it ships with coverage.

  • Take one of your day-30 friction points all the way to shipped. Not "proposed." Shipped.

  • Own bug triage for at least one full week: nothing sits more than 24 hours without you either fixing it or moving it forward with a clear next step.

  • Review at least 8 of your teammates' PRs with feedback actually worth reading, not a rubber-stamped "LGTM."

  • On quality: your PRs should clear review in two rounds or fewer by day 60.

  • Day 60 review: a feature you built is live, real clients are using it, and you can pull up the numbers to prove it.

Days 61–90: Own

By month three, you're an engineer we're relying on.

  • Own a feature area (a dashboard module, the ingestion layer for a platform, a slice of the annotation flow). You're the person the team turns to when anything in that area comes up.

  • Lead one feature entirely on your own, from writing the spec to launching it. Nobody sequences the work for you.

  • Ship something that moves a number (annotation accuracy, time-to-first-data, dashboard load time, a client-facing metric) and be able to name both the number and how far it moved.

  • Find one thing that's measurably bad (latency, a flaky scrape, a noisy bug, a slow build) and make it measurably better. Show the before and the after.

  • Stand up in front of the team and walk through something you got wrong: a bug you shipped, an edge case you missed, a call that didn't land. What happened and what you'd do differently. We trust people who can do this. We worry about the ones who can't.

  • Day 90 formal review: assessed against everything above. Then you tell us what you want to own next quarter. If you want a quiet maintenance job, this isn't it, and we'd rather you knew that now.

Why Markopolo

A manager who gives you honest feedback, not just encouragement. You'll always know exactly where you stand.

  • Real features and real clients starting in month two.

  • A front-row seat to building AI-native data infrastructure: multilingual NLP, large-scale scraping, and LLM annotation at scale. The kind of work that will define engineering careers this decade.

  • A fast, ambitious team that will push you. If you want a quiet maintenance role, this isn't it.

How to Apply

We read every application, but we pay much more attention to the ones that show us something real. Here's what we'd like from you:

  • Your CV: Send it to hr@markopolo.ai with the subject line "Associate Product Engineer | [Your Name]". Two pages maximum.

  • A 60-second Loom video: Record a short video (loom.com, free) and include the link. Tell us: who you are, why you build, and why DeepDive specifically. Don't script it. Sixty seconds is a strict limit.

  • A build task: Share a link (GitHub, CodeSandbox, or a live demo) to something you've built. It can be an existing project or something small you build for this purpose; your call. Add one or two lines about what it does and what you'd improve with another week.

  • A product teardown: In under 150 words, pick any feature of DeepDive, Markopolo, or a product you admire and tell us one thing you'd change and why. We're testing judgment, not politeness.

Applications that do not include the Loom video, the build link, and the teardown will not be processed. We know that's a higher bar than most. That's deliberate. We're looking for people who'll put in a little extra before they've even walked in the door.

Good luck!