Given `interface Logger { (message: string): void; level: number }` in TypeScript, why does `const logger: Logger = (message) => {}` fail to compile, and how do you build a conforming value without an `as` assertion?

## Why the obvious code is rejected ```ts interface Logger { (message: string): void; level: number; } const logger: Logger = (message) => {}; // Property 'level' is missing in type '(message: string) => void' ``` The annotation on a `const` is checked against the initializer at the point of declaration. The arrow function matches the call signature, and nothing else. Adding `logger.level = 1` on the next line does not help — the error is at the initializer, and by then `logger` is already required to have been a full `Logger`. This surprises people because the JavaScript would work fine: functions are objects, you can hang a property on one at any time. The type layer is stricter than the runtime here, deliberately: it wants the value to be complete when it claims the type. ## Fix one: `Object.assign` The standard library types `Object.assign` so that the result is the intersection of the target and the sources: ```ts const logger: Logger = Object.assign( (message: string): void => { if (logger.level > 0) console.log(message); }, { level: 1 }, ); ``` The expression's type is `((message: string) => void) & { level: number }`, which is assignable to `Logger`. Nothing is asserted; if you misspell `level` or give it a string, the assignment fails to compile — which is precisely the property you want. One sharp edge: an object literal widens its property types. If `Logger` declared `level: 'debug' | 'info'`, then `{ level: 'info' }` infers `level: string` and the assignment is rejected. Fix it by narrowing at the source — `{ level: 'info' as const }` — or by annotating the literal. ## Fix two: properties on a function declaration TypeScript folds properties assigned to a function declaration (or a `const`-bound function expression) into that function's inferred type, within the same scope: ```ts interface Counter { (label: string): number; count: number; } function tick(label: string): number { tick.count += 1; console.log(label, tick.count); return tick.count; } tick.count = 0; const counter: Counter = tick; // ok ``` Here `tick`'s inferred type already includes `count`, so the final assignment checks. The property's type comes from the assignment, so the same widening caveat applies: `tick.level = 'info'` infers `string`. This form reads well when the hybrid is a module-level singleton; `Object.assign` reads better when you are producing values in a factory. ## Why the assertion is the wrong answer ```ts const logger = ((message: string) => {}) as Logger; // compiles logger.level.toFixed(0); // runtime TypeError ``` `as` is an assertion, not a conversion. It performs no check, generates no code, and simply instructs the compiler to stop disagreeing. The whole point of the hybrid type was to guarantee that callers can read `level`; asserting deletes that guarantee while leaving the documentation in place, which is worse than having no type at all — the next reader trusts it. There is a narrow legitimate use: building the value in steps where the intermediate state genuinely cannot be expressed, ideally isolated inside one small factory function whose *return* type is the honest one, so the unchecked region is three lines rather than a whole module. ## Choosing between the two fixes - **Factory or per-instance value** → `Object.assign`, because it composes and its type falls out of inference. - **Module-level singleton with self-reference** → function declaration plus property assignment, because the function can refer to its own properties naturally and hoisting makes ordering forgiving. - **Value produced by a third-party call** → wrap it in a factory that returns the hybrid type, and keep any assertion inside. ## The runtime picture None of this exists after compilation. `Object.assign` is a real runtime call and really does attach the property; the function-declaration form emits a plain property assignment. The *interface* emits nothing, checks nothing, and defends nothing — it only decided, at compile time, whether your construction was honest. That asymmetry is exactly what an interviewer is probing with this question: can you produce a value that genuinely has the shape, rather than one the compiler has been told to stop asking about.