You are participating in a staff-level TypeScript technical ...

Prompt

You are participating in a staff-level TypeScript technical interview. Your task is to design and write the core application code shown below. This is a static code-review exercise. ## Important execution constraint Do not: * run commands * use tools * install packages * create a project * compile or execute the code * provide `package.json`, `tsconfig.json`, build configuration, or setup instructions Write the code directly in your response. The code will be assessed manually for correctness, design quality, TypeScript usage, maintainability, and engineering judgment. It should be internally consistent and plausibly type-check under strict TypeScript settings, but it will not be executed during the interview. ## Scenario Implement the application layer of a shipping quote service. The service receives an untrusted request, asks multiple external shipping providers for quotes, validates their responses, and returns an aggregated result. A caller should use this public API: ```ts export interface QuoteService { search( input: unknown, signal?: AbortSignal, ): Promise<QuoteSearchResult>; } export function createQuoteService( dependencies: QuoteServiceDependencies, ): QuoteService; ``` You must define the supporting types and implementation. ## Input A valid request has this logical shape: ```ts { originPostalCode: string; destinationPostalCode: string; currency: "PHP" | "USD"; parcels: Array<{ weightGrams: number; lengthCm: number; widthCm: number; heightCm: number; }>; } ``` Rules: * Treat the input as untrusted. * Do not access properties before safely narrowing their types. * Postal codes must be non-empty after trimming. * Normalize postal codes by trimming and converting them to uppercase. * There must be between 1 and 20 parcels. * Every parcel measurement must be a finite positive integer. * Validation failures are expected application outcomes, not exceptions. ## Providers External providers implement: ```ts export interface QuoteProvider { readonly id: string; getQuotes( request: QuoteRequest, signal: AbortSignal, ): Promise<unknown>; } ``` Provider responses are `unknown` because they cross an external-system boundary. A valid provider response is an array with this logical shape: ```ts Array<{ serviceCode: string; amountMinor: number; currency: string; estimatedDays: number; }> ``` A valid quote requires: * a non-empty `serviceCode` * a finite, non-negative integer `amountMinor` * the same currency requested by the caller * a finite positive integer `estimatedDays` Validate provider responses at runtime. Do not convert `unknown` to a trusted type through an unchecked assertion. ## Provider failures A provider may reject with any JavaScript value. The following structured failure may be recognized when it can be safely validated: ```ts { kind: "transient" | "permanent"; code: string; message: string; } ``` Requirements: * Retry a transient failure at most once. * Do not retry permanent failures. * Do not retry malformed provider responses. * Do not retry after caller cancellation. * Retry delay must use an injected `sleep` dependency. * Do not expose raw thrown values, stack traces, or sensitive provider messages to callers. ## Aggregation * Query all configured providers. * One provider failure must not prevent valid quotes from other providers from being returned. * A malformed response counts as a failure only for that provider. * If all providers fail, return a typed failure result rather than throwing an expected operational error. * Include structured information identifying which providers failed and whether each failure was transient, permanent, malformed, cancelled, or unexpected. * Deduplicate quotes using `(providerId, serviceCode)`. * When one provider returns duplicate service codes, retain the quote with the lowest `amountMinor`. * If duplicate prices are equal, retain the quote with the lowest `estimatedDays`. * Sort quotes deterministically by: 1. `amountMinor`, ascending 2. `estimatedDays`, ascending 3. `providerId`, lexicographically 4. `serviceCode`, lexicographically ## Cancellation and timeout * Caller cancellation must stop the search promptly. * Each provider attempt has its own timeout. * A timeout must abort the relevant provider attempt through an `AbortSignal`. * A failed or timed-out provider must not abort unrelated providers. * Clean up timers and abort listeners when they are no longer needed. * Do not leave rejected promises unobserved. You may define a small helper for combining cancellation signals. ## Dependencies Define a minimal `QuoteServiceDependencies` interface containing the dependencies genuinely required by your design. It should include at least: * configured quote providers * provider timeout duration * retry delay * injected sleep operation Do not introduce a dependency-injection container. ## Design expectations The implementation should demonstrate: * clear separation between boundary validation, orchestration, and domain decisions * dependency inversion at external-system boundaries * explicit modeling of expected outcomes * exhaustive handling of discriminated unions where appropriate * high cohesion and low coupling * deterministic behavior * easy addition of another provider without changing orchestration logic * appropriate use of composition * minimal but meaningful abstractions Do not add design patterns merely to demonstrate knowledge of their names. Avoid: * `any` * `@ts-ignore` * `@ts-expect-error` * unchecked double assertions * pervasive type assertions * non-null assertions used to bypass weak modeling * inheritance-based service hierarchies * `BaseService` or `BaseProvider` * decorators * service locators * dependency-injection frameworks * generic repository abstractions * middleware frameworks * event buses * factories that only wrap constructors * speculative abstractions unrelated to the requirements Ordinary functions and small interfaces are preferred. Classes are acceptable when they make state or lifecycle management clearer. ## Scope limit Keep the production implementation below approximately 350 lines of TypeScript. Do not provide tests. Instead, after the implementation, list at most eight high-value test cases that should be written. Do not spend response space on routine project configuration. ## Required response format Return exactly these sections: ### 1. Design Explain the architecture and major design decisions in no more than 180 words. Identify: * the main boundaries * how expected failures are modeled * how cancellation and provider timeouts interact * one design pattern or abstraction you deliberately did not use because it would add unnecessary complexity ### 2. Code Provide the complete TypeScript implementation. You may divide it into at most four logically named files. Put each file in a separate code block with its path above it. The code must not contain: * placeholders * ellipses * pseudocode * omitted implementations * comments claiming that production code would do something differently ### 3. Review In no more than 150 words, discuss: * the most important invariant maintained by the design * the most likely concurrency or cancellation bug in a naïve implementation * the first architectural change you would make if provider-specific authentication and rate limiting were later required ### 4. Test cases List at most eight behavior-focused test cases. Do not provide an internal chain-of-thought transcript.