TypeScript Certification Test (Intermediate)

The TypeScript (Intermediate) test is about the types you read more often than you write: the signatures a library exports, the helper types in a shared types file, and the errors the compiler raises when a change in one place breaks a promise made in another. It examines whether you can work out what a type resolves to, why the compiler accepts or rejects a line, and — just as often — what the program does once every type has been erased.

The questions are short. Some show a few declarations and ask what a type is, or which lines compile with strict: true; many show a complete program and ask exactly what it prints. A few ask you to choose every correct option, and only the exact set scores. A coding section follows, answered in TypeScript and judged on hidden test cases.

Is this your level?

Sit Intermediate if TypeScript is the language of your job or your main projects: you write generic helpers, read the types a package ships with, and know which tsconfig flags your project turns on. It assumes everything on the TypeScript (Basic) test, from inference and literal types to typeof narrowing and parameter properties, because the harder questions stand on that ground.

TypeScript runs as JavaScript, so a fair share of the questions turn on runtime behaviour that no annotation changes, such as how an object spread copies properties or what instanceof actually tests. If those parts feel uncertain, the JavaScript (Intermediate) test examines them directly.

What each topic examines

Each area below is a topic on your result, so a weak one shows up by name. The TypeScript module of the JavaScript study plan covers inference, structural typing, generics with keyof, the utility types, narrowing and type guards, and tsconfig, with exercises checked on a judge.

• Basic types and inference. When literal types widen and when they stay narrow, unknown against any, typeof in a type position, as const, and satisfies, which checks a value against a type without giving up the type inferred for it.
• Unions and narrowing. Discriminated unions and exhaustiveness checks with never, narrowing with in and equality, user-defined type guards (x is T), assertion functions (asserts x is T), and the places where a narrowing stops applying.
• Interfaces and type aliases. Declaration merging, what only an alias can express, excess property checks on object literals, index signatures, and what an intersection does with properties that conflict.
• Function types and overloads. Which overload a call resolves to and what callers can see, this parameters, when one function type is assignable to another, and what strictFunctionTypes checks.
• Classes and modifiers. Abstract classes and members, protected access, parameter properties, private members and compatibility, and what implements does and does not do.
• Generics. Constraints such as K extends keyof T, indexed access types such as T[K], default type parameters, how inference chooses a type from several arguments, and const type parameters.
• Utility and mapped types. Partial, Required, Readonly, Pick, Omit, Record, Exclude, Extract, NonNullable, ReturnType, Parameters and Awaited; mapped types with the readonly and ? modifiers, removing them with -, and key remapping with as.
• Conditional and template literal types. infer, distribution over unions and [T] extends [U], template literal types built from unions, and the string helpers such as Capitalize.
• Enums and literal types. Numeric, string and const enums and what each compiles to, which values an enum accepts, keyof typeof on an enum, and keeping literal types with as const.
• Types at runtime. What assertions, the non-null !, readonly, private and abstract amount to once compiled, and the places a wrong value slips past the checker unnoticed.
• Modules and compiler options. What strict switches on and what it leaves off, noUncheckedIndexedAccess, useUnknownInCatchVariables, strictPropertyInitialization, isolatedModules with export type, and the difference between target and lib.

How to prepare

Work in a scratch file with strict on and ask the compiler rather than your memory. Before you hover over a type or save the file, write down what you expect: the type a helper resolves to, or which lines will be underlined. A quick way to test a guess is a line that compiles only if you are right, such as assigning the value to a variable annotated with the type you expect. Treat every surprise as a rule to find. Most questions at this level come down to a handful of rules applied carefully: which direction an assignment is checked in, when a conditional type distributes, when a literal widens, and which checks exist only at compile time.

Then compile and read the JavaScript. Run tsc on a file holding a const enum, an abstract class, an overloaded function and a type guard, and open what it writes: overloads collapse into one function, const enum members become plain numbers, and guards are ordinary functions that return booleans. Questions that ask what a program prints are answered from that output, never from the annotations.

Finally, change one compiler flag at a time. Turn on noUncheckedIndexedAccess, exactOptionalPropertyTypes or isolatedModules in a small project and fix what breaks; you will remember what each one does far better than from a list of options.

What trips people up

• Reading a type as a fact about data. An annotation, an as or a ! changes what the compiler believes, not the value. Anything from outside the program is whatever arrived until code has checked it.
• Forgetting distribution. A conditional type over a bare type parameter is applied to each member of a union separately, so a helper can answer differently for a union than for the union taken whole.
• Assuming the checker sees everything. Narrowing can be lost inside a callback, a method written in shorthand is checked more loosely than a function-typed property, and implements never types a class body for you.
• Assuming strict turns on every check. It enables strictNullChecks, noImplicitAny, strictFunctionTypes and several more, but not noUncheckedIndexedAccess or exactOptionalPropertyTypes.
• Rushing the multi-answer questions. They score only when the whole set is right, so judge each option on its own. There is no negative marking, so never leave a question blank.

The coding section

The coding problems come from the catalogue, reach medium difficulty and must be answered in TypeScript. At that level the algorithm matters as much as the code: Submit runs every hidden case, so an approach that is only fast enough for the visible examples can still lose marks. Review costs with the Big-O notation lesson, then practise the patterns medium problems lean on — hashing, two pointers and sliding window — with problems from Hash table, Two pointers and Sliding window, solved in TypeScript.

The editor hands you a typed function to complete: return the answer rather than printing it. Solutions are compiled for an older JavaScript target, so a for…of loop or a spread over a Map or Set does not compile; use forEach, or keep the data in arrays. Keep the types plain, since the judge checks what the function returns, not how clever its signature is. Pasting into the editor is switched off during a sitting, so practise writing solutions from an empty function. The other skill tests are listed on the skill tests page.