In a classic non-module script, what does `console.log(typeof foo); var foo = 1; function foo() {} console.log(typeof foo);` print, and why?

## One name, one binding The first thing to see is that this snippet does not create two variables. `var foo` and `function foo` are both var-scoped declaration forms, and in the same scope they name the same binding. Declaring a name twice with `var` is legal and harmless; mixing `var` with a function declaration is equally legal — the question is only what value the single binding holds at each moment. ## Step one: scope instantiation Before the first statement of a script or function body executes, the engine sets up the scope's bindings. Walking through it for this code: 1. It sees `var foo` and creates a binding named `foo`. If the binding is new, it is initialised to `undefined`. 2. It sees `function foo() {}`, builds the function object, and initialises `foo` with it — this step deliberately overwrites whatever the `var` left there. The order in the source does not matter for step 2: function declarations are processed after the plain `var` names, and a `var` never re-initialises a binding that already exists. So when the first statement finally runs, `foo` holds the function. ```js console.log(typeof foo); // "function" var foo = 1; function foo() {} console.log(typeof foo); // "number" ``` ## Step two: execution Now the statements run top to bottom. `var foo = 1;` splits into two halves: the declaration part, which already happened during instantiation, and the *assignment* part, which is an ordinary statement executed here. It stores `1` in the binding, replacing the function. The function declaration line does nothing at run time — its entire effect happened at instantiation. That is why moving it above or below `var foo = 1` changes nothing about the output. Swap the two lines and you still get `"function"` then `"number"`. A related detail: a bare `var foo;` with no initialiser is not an assignment at all, so it cannot clobber anything at run time: ```js function f() { var foo; // no assignment happens here function foo() {} return typeof foo; // "function" } ``` Many people expect `"undefined"` from that, reasoning that `var foo;` "resets" the name. It does not; it only ensures the binding exists, and the binding already does. ## Duplicate function declarations The same instantiation step explains what happens with two functions of the same name in one var scope: ```js function pick() { return "first"; } function pick() { return "second"; } console.log(pick()); // "second" ``` Both are processed in source order during instantiation, so the later one overwrites the earlier — and it wins even for calls written *above* both declarations, because the overwrite happened before any statement ran. No error, no warning; the first function is simply unreachable. Linters flag this (`no-redeclare` and `no-func-assign` in ESLint) precisely because a duplicate name is nearly always a merge accident or a copy-paste mistake. Note that the tolerant behaviour comes from these being *var-scoped* declaration forms. Block-scoped forms are stricter: two `let` declarations of the same name in one scope, or a `let` and a `var` colliding, are a `SyntaxError` caught before anything runs. ## Why this shows up in interviews On its face it is a whiteboard trick, but it tests something real: whether you can separate *when a binding is created and initialised* from *when an assignment executes*. Candidates who think "hoisting moves code to the top" get this wrong, because under that mental model the function declaration would have moved above `var foo = 1` and then been overwritten — which is right here by accident, but produces the wrong answer for the first `typeof`. Candidates who think in terms of an instantiation pass followed by ordinary execution get both lines right and can also explain the `var foo;` variant and the duplicate-declaration case. In real code, of course, none of this should appear. A single name meaning both a function and a number is a defect; the value of knowing the rules is being able to read the intent out of code someone else already wrote, and to explain a confusing stack trace in a legacy file.