Application / Backend Engineer

Tell us how you build.

Short, specific answers beat long ones. Your draft is kept in this browser until you submit.

01 About you

Full name

Location and timezone

Hours per week you can give

GitHub or portfolio

LinkedIn optional

This is a paid role, but the budget is still being negotiated, so we cannot give you a number yet. Does that work for you?

Yes, I can start before the budget is set I need the number before I start Contact me once the budget is set

02 Your experience

What is your stack?

Languages, frameworks, databases, queues, cloud services, testing. Mark what you have used in production.

How well do you know the GitHub API and GitHub Apps?

Describe one backend service you shipped and ran in production.

What did it do, what load did it handle, and what broke first?

03 How you would work here

GitHub delivers the same pull_request.synchronize webhook twice, 400 ms apart, and a third time an hour later after a manual redelivery. Our service posts a review comment for each. How do you make processing correct?

Cover idempotency, ordering, and a newer commit arriving while an analysis is still running.

A plan JSON from a large monorepo is 300 MB. The analyzer runs on a GitHub Actions runner with 7 GB of RAM and loads the whole file. How would you change it, and how do you prove the findings did not change?

The analysis finished, but uploading SARIF to GitHub returned HTTP 502 three times in a row. What should the job report?

Success, because the analysis itself worked Keep retrying until the upload succeeds Fail the check as "results not delivered" and keep the results as a build artifact Post "no issues found" so the pull request is not blocked

04 Design problem

Each pull-request run produces findings from the deterministic analyzer. We need history across commits, so a finding fixed in a later commit shows as resolved. Suppressions need a reason and an expiry, and every change needs an audit trail.

It must work for one repository and for an organization with 2,000. Plan contents, resource names and tags come from pull requests and are untrusted.

How would you design the findings backend?

Cover these points. If you think the brief is wrong in part, say so and explain why.

Data model: runs, findings, suppressions
How a finding keeps its identity when a resource is renamed or moved into a module
API for the pull-request comment, SARIF and the dashboard
Processing: webhooks, queues, retries, idempotency
Multi-tenancy and isolation between customers
Hostile input in plan values, resource names and tags
What you would build in the first two weeks

0 words. Most good answers run 300 to 800.

Your answers are used only to review this application.

Tell us how you build.

Thank you.