In a TypeScript interface, a callback member can be written as `onDone(result: string): void` or as `onDone: (result: string) => void`. Do the two forms differ in the emitted JavaScript, and are they interchangeable?

## Two ways to write one member Inside an `interface` or an object type alias, a member whose value is a function can be declared in two syntaxes: ```ts interface Job { run(id: string): void; // method shorthand } interface Job2 { run: (id: string) => void; // property holding a function type } ``` Both say the same thing in plain English: an object of this type has a member called `run`, you call it with one string, and you should ignore the result. Any object literal, class instance, or imported value with a suitable `run` satisfies either declaration — TypeScript is structurally typed, so no `implements` clause is needed for the shapes to line up. ## Nothing survives compilation The first thing to say in an interview is that neither form generates code. TypeScript's type layer is erased: `interface` declarations produce zero output, so the emitted JavaScript for a file containing `Job` and a file containing `Job2` is byte-for-byte the same. There is no runtime object named `Job`, nothing to `instanceof`, and no per-call check that the argument really is a string. Everything the two forms do, they do to the compiler. ## Where they actually differ The difference shows up only when the compiler has to decide whether one type is assignable to another, and only in the **parameters**. ```ts interface MethodForm { handle(e: Event): void } interface PropForm { handle: (e: Event) => void } const a: MethodForm = { handle(e: MouseEvent) {} }; // OK // const b: PropForm = { handle(e: MouseEvent) {} }; // Error ``` For the method-shorthand member, TypeScript compares the parameter types **bivariantly** — the relation is accepted if either type is assignable to the other. `MouseEvent` is assignable to `Event`, so the narrower implementation is waved through, even though calling `a.handle(someKeyboardEvent)` would hand the implementation something it does not expect. For the property form, the member is an ordinary function type, and `strictFunctionTypes` (switched on as part of `strict`) compares parameters **contravariantly**: the target's parameter must be assignable to the source's parameter. `Event` is not assignable to `MouseEvent`, so the assignment is rejected. Return types are unaffected — they are always compared covariantly in both forms. One detail worth knowing: it is the **declared (target) type's** form that decides. Writing the implementation as a method does not buy back the loose check when the type it must satisfy declares a property function type — the commented-out `b` above is still an error. ## A class body is a different question The "no runtime difference" claim is specific to interfaces and object type aliases. Inside a class body, `handle(e: Event) {}` and `handle = (e: Event) => {}` are genuinely different JavaScript: the first lands on the prototype and is shared by all instances, the second is a per-instance field whose arrow function captures `this` lexically. That is a JavaScript-semantics choice about `this` and memory, layered on top of the type-checking difference described here. ## Which one to write A practical default: use the **property form** for callbacks your callers supply — options bags, event handler fields, dependency-injection hooks — because you want a mismatched parameter type to be a compile error rather than a surprise at runtime. Use **method shorthand** for members of container-like or generic types where the loose check is what keeps the type usable, and for members you expect many types to implement with slightly different parameter types on purpose. Teams often pick one form as the house style and let a linter enforce it, precisely because the two look interchangeable but are not.