Application / Software 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, testing, build and CI tools, databases. Mark what you have used in production.

How do you test the code you ship?

Describe one piece of software you shipped that others depended on.

What did it do, how did you keep it correct as it changed, and what broke first?

03 How you would work here

A teammate changes the rule for public S3 buckets. All unit tests pass, but on the fixture library 37 findings change: 30 disappear and 7 are new. How do you decide whether the change can merge?

Say what you look at first and what evidence you want.

The analyzer must give the same findings, in the same order, for the same plan. A customer reports that two runs on the same commit listed findings in a different order, and once a finding was missing. Where do you look, and how do you prevent it for good?

In the plan JSON, an entry in resource_changes has "actions": ["delete", "create"]. What does that mean?

The resource is updated in place Two separate resources: one is deleted, another is created The resource is replaced: destroyed first, then created again The plan failed and Terraform will retry the change

04 Design problem

The analyzer takes a plan JSON and produces findings: rule ID, severity, affected resource, and the facts that prove it. Today the rules are hard-coded functions in one file. Adding a rule takes a day and often breaks another one.

We want 200 rules within a year, written by people who are not all on the core team. Every finding must stay deterministic and traceable to the plan.

How would you design the rule engine?

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

How a rule is written, and what it may and may not access
The resource graph: references, modules, count and for_each
Values that are only known after apply
Testing a rule, and proving a change did not break the others
Performance on a plan with 20,000 resources
Versioning rules so customers can pin behaviour
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.