Anchorage Digital Interview Questions: Process and an Approval-Policy Exercise

TL;DR

• Anchorage Digital publishes a general recruiting sequence: application, an initial conversation, team interviews, a co-founder meeting and an offer decision. Confirm the stages for your role.
• Engineering preparation should connect correctness, authorization and recovery. Being able to describe a happy-path transaction is only the beginning.
• Use the original approval-policy exercise below to practise distinct approvers, expiring decisions, revision changes and invalid input without touching real assets.
• The examples are independent interview preparation, not Anchorage’s production authorization model, private questions or a financial recommendation.

What is the published Anchorage Digital interview process?

The Anchorage Digital careers page presents five broad steps: application, an initial talent-team interview, conversations with the hiring manager and team, a co-founder meeting, and an offer decision. It also describes a team working across security, finance and distributed systems. Your invitation may provide a more specific sequence for the role, location and seniority.

Ask what the team interviews assess, whether coding or system design is included, and whether a project presentation is expected. The public sequence does not justify inventing round durations, an exact technical question list or a hiring probability.

The company’s custody page discusses authorization and operational controls. That provides context for practising reliable systems reasoning. It does not expose the company’s internal implementation, and the simplified policy below must not be mistaken for it.

Public company context was checked on September 14, 2026. All practice scenarios in this guide are original.

Question 1: can an old approval authorize a changed request?

Imagine a fictional internal system where a request needs approval from two distinct eligible people other than its creator. Each approval refers to one immutable revision of the request and has an expiration time. If the request changes, approvals for an older revision must not satisfy the new revision’s policy.

This separates two concepts that are easy to blur: a person is allowed to approve requests, and that person approved this specific version. A valid identity alone does not prove that the user saw the current request details.

For the exercise, assume a trusted upstream process has already authenticated each approval. Our function evaluates the policy only. It does not verify signatures, authenticate users, read a permissions database, transfer funds or perform a transaction.

We will use simple string revision identifiers. A real design would need to bind the approved content precisely and explain how the representation is created, compared and protected against modification.

Question 2: implement a deterministic approval decision

The function receives the current revision, creator, eligible people, requested quorum, evaluation time and approval records. A record is current only while created_ms <= now_ms < expires_ms. Repeated approval from one person counts once. Approvals for other revisions, ineligible people or the creator do not count.

def approval_decision(revision, creator, eligible, required, now_ms, approvals):
    def valid_id(value):
        return isinstance(value, str) and bool(value.strip())

    if not valid_id(revision) or not valid_id(creator):
        raise ValueError("revision and creator required")
    if type(required) is not int or required < 1:
        raise ValueError("positive integer quorum required")
    if type(now_ms) is not int or now_ms < 0:
        raise ValueError("nonnegative integer time required")
    eligible = list(eligible)
    if not all(valid_id(person) for person in eligible):
        raise ValueError("invalid eligible identity")
    allowed = set(eligible) - {creator}
    accepted = set()
    for item in approvals:
        person, version = item["person"], item["revision"]
        created, expires = item["created_ms"], item["expires_ms"]
        if not valid_id(person) or not valid_id(version):
            raise ValueError("invalid approval identity or revision")
        if type(created) is not int or type(expires) is not int:
            raise ValueError("integer approval timestamps required")
        if created < 0 or expires <= created:
            raise ValueError("invalid approval lifetime")
        if (person in allowed and version == revision
                and created <= now_ms < expires):
            accepted.add(person)
    return {"approved": len(accepted) >= required,
            "approvers": sorted(accepted)}

approvals = [
    {"person": "alice", "revision": "v2", "created_ms": 10, "expires_ms": 100},
    {"person": "bob", "revision": "v1", "created_ms": 10, "expires_ms": 100},
    {"person": "carol", "revision": "v2", "created_ms": 10, "expires_ms": 100},
]
result = approval_decision("v2", "carol", ["alice", "bob", "carol"], 2, 50, approvals)
assert result == {"approved": False, "approvers": ["alice"]}
approvals.append({"person": "bob", "revision": "v2", "created_ms": 20, "expires_ms": 100})
assert approval_decision("v2", "carol", ["alice", "bob"], 2, 50, approvals)["approved"]
assert not approval_decision("v2", "carol", ["alice", "bob"], 2, 100, approvals)["approved"]

In the first decision, Alice counts, Bob approved the wrong revision, and Carol is the creator. Adding Bob’s current approval satisfies the quorum. At time 100, the approvals have expired because the upper boundary is exclusive.

The output includes sorted identities so the explanation is stable even when records arrive in a different order. If the quorum exceeds the number of possible approvers, the function returns an unapproved decision; it does not weaken the rule to make progress.

For e eligible identities and a approval records, validation and scanning take O(e + a), plus O(k log k) to sort k accepted identities. The sets and eligibility list use O(e + k) memory. This is a small in-memory teaching function, not a production policy engine.

Question 3: which tests protect the policy?

Test two distinct valid approvers, two copies of one person’s approval, a creator approval, an ineligible identity, a wrong revision, a future approval and an approval at the exact expiration boundary. Reordering records should not change the output.

Add malformed timestamps, a zero quorum, a missing field and an approval whose expiration precedes creation. A malformed record should raise an error, including when it belongs to an irrelevant revision. Silently dropping corrupted records can conceal an upstream integrity problem.

One useful test changes only the revision argument after a successful decision. The same old approvals should then fail to authorize the new request. Another removes a person from the current eligible list; that person must no longer contribute even if their approval record remains in the log.

This model does not include explicit approval revocation. If revocation is required, introduce a defined event or state model and test ordering and conflicts. Do not pretend that deleting a row from an in-memory list is an adequate audit design.

Question 4: what happens between approval and execution?

The most important limitation is the gap between checking the policy and performing an action. Another process might modify the request, revoke a permission or execute the same request during that interval.

Describe an execution boundary that binds the decision to the exact request revision. Explain which state is read and written atomically, how concurrent attempts are serialized or rejected, and how a retry finds the prior result. Naming a database transaction is insufficient unless the protected invariant is clear.

If an external action succeeds but the response is lost, the caller has an uncertain outcome. Repeating the action blindly may duplicate it. A strong design discussion separates safe retries from reconciliation: identify the external operation, retrieve its status when supported and retain enough evidence to investigate ambiguity. To practise the retry side of that discussion, work through the payments API sample question in this distributed systems interview deep dive.

Do not promise exactly-once behavior simply because a local table has a unique key. The local uniqueness constraint and the external system’s behavior must work together. Our exercise makes no external calls and therefore does not demonstrate those guarantees.

Question 5: how do you investigate an authorization incident?

Use this fictional scenario: an operator reports that a request executed after an approver lost access. First establish the timeline and preserve the relevant records. Determine whether the policy was checked before or after the permission change and whether the execution path used current or cached eligibility.

Identify the immediate containment appropriate to the affected path, then reconstruct the request revision, authorization decision, execution attempt and result. Explain what evidence would support each hypothesis. Avoid announcing a root cause before correlating the records.

For a behavioral answer, use an incident from your own experience. State your responsibility, how you communicated uncertainty and what changed after the investigation. A useful outcome could be a regression test, a clearer ownership boundary or a reconciliation process. Do not invent a security incident or claim to have handled regulated custody systems if you have not. Once the story is accurate, rehearse it in a mock behavioral interview with STAR grading to check that each part comes through clearly.

Questions to ask the hiring team

Ask how the team balances correctness, delivery and operational simplicity; what kinds of incidents engineers own; and how changes are reviewed across relevant functions. For the interview itself, confirm the expected language, tools and format.

Prepare a short project summary with one concrete invariant. Examples include “a retry must not create another invoice” or “a permission change must take effect before the next protected action.” Explain where the invariant was enforced and how you tested it.

The phone-screen preparation checklist can help organise your introduction and recruiter questions. Use practice tools to challenge your explanations, and follow the assessment’s stated rules during the interview.

Frequently asked questions

No. They are original engineering and behavioral practice prompts. The recruiting overview comes from the company’s public careers page; private technical assessments were not accessed.

Requirements depend on the opening. Read the role description and ask recruiting which domain knowledge is expected. This guide develops software reasoning and does not recommend assets or trading strategies.

Not as a complete authorization system. It deliberately assumes authenticated input and omits signatures, durable state, concurrency, revocation and execution. Its purpose is to make the policy contract easy to explain and test.