Preparing the next view without exposing private workflow data.
Engineering task library · Version 5
Work that feels like work.
Design a system. Diagnose tail latency. Ship a migration. Recover a failed rollout. Pick a focused ticket or follow a project through its delivery phases.
Operations wrote zone == 'north' OR service == 'express' AND weightGrams < 500. Two engineers read it differently, and there is no grammar to decide which parcels qualify.
The current rule model has separate fields for one AND group and one OR group. A warehouse needs (north OR west) AND (express OR under-500g), which cannot be represented without duplicated conditions.
A rule containing weightGrams == 'heavy' parses successfully, then fails when a parcel reaches the evaluator. Support needs all actionable type errors from the saved rule before attempting a run.
A carrier feed omitted weightGrams and the evaluator coerced it to zero. The parcel passed a weight limit despite having no measurement; OR branches also mask inconsistent missing-value behavior.
The rule editor reuses a builder to produce two templates. Adding a condition to the second template mutates the first because both saved objects reference the builder's child array.
The support inspector duplicates recursive loops for a tree outline, field usage report, and copyable diagnostics. These loops disagree on child order and sometimes skip a nested condition.
A heap profile suggests thousands of cached rules repeat the same field and operator metadata. The proposed optimization shares entire nodes, including source locations and tenant rule identifiers.
Warehouse rules repeat long chains such as zone == 'north' OR zone == 'west'. Adding IN to evaluation alone would leave validation, inspection, and serialization unaware of the new node.
The editor rejects a deeply nested rule only after parsing its entire text. A pasted megabyte of repeated parentheses stalls the local worker, and explanations allocate one message for every attempted comparison.
The membership release introduces version 2 rules, but a rollback plan assumes every stored rule can still be opened by the version 1 editor. Saving an unrecognized node would silently discard a condition.
Replace a growing set of warehouse eligibility switches with a small, bounded rule language that support can inspect and engineers can evolve.
10 tickets · 3 phases
Take the brief into your own workflow.
For engineers
Practice scoped changes, keep a portable implementation and verification record, and learn to explain operational tradeoffs. Choose a ticket whose prerequisites you can provide.
For companies
Use realistic work to structure onboarding, internal practice, and conversations about engineering decisions. Each project names the delivery benefit. Agree scope and compensation before requesting company-specific work.
CSV contains one row per ticket. Map fields and issue types in your tracker; project grouping and dependency keys are descriptive. JSON preserves the complete project structure. These downloads do not synchronize with Jira.