Blockchain developer (DAML / Canton, remote worldwide): what 2 proof signals get you shortlisted in a 10-second screen?

For a DAML / Canton role, my first 2 proof signals are:

1) A small repo that models a real workflow, not a toy template.
I want to see whether the candidate can model parties, choices, authorization, and lifecycle clearly — for example issuance, transfer, settlement, cancellation, exception handling.

2) Tests that prove they understand failure and permission boundaries.
A lot of people can write happy-path logic. Far fewer can show what happens when the wrong party tries to exercise a choice, when timing assumptions break, or when business rules conflict.

What usually gets my attention is not “blockchain interest,” but whether the person can translate a messy business process into precise ledger behavior.

My round-1 questions:

1. How would you model a multi-party approval flow in DAML without creating unnecessary complexity?

2. Where do candidates usually misunderstand authorization in ledger applications?

3. Tell me about one workflow you modeled that became simpler only after you removed features.

Hey that's a good discussion @ShubhadaJP For me, the top 2 signals would be:

1) A small PoC that shows clean DAML contract modeling and choice design.
I would want to see whether the person actually understands how to model a workflow properly — when to split contracts, how to keep templates tight, and how to avoid turning the whole business process into one big object that becomes painful to reason about later.

2) A short note explaining design tradeoffs.
This matters a lot. If a candidate can explain why they chose a certain contract structure, keying approach, or workflow boundary, that gives me more confidence than just seeing code without context.

For a DAML / Canton blockchain developer role, I care less about how many repos someone has and more about whether they understand ledger semantics, state transitions, authorization, visibility, and real workflow design.

My round-1 questions would probably be:

• What is one DAML modeling mistake that looks okay early on but creates pain later?

• How would you design a workflow that will need to evolve over time without becoming messy?

• In a settlement or transfer flow, what would you test first, and why?