Private corporate batches, live online cohorts and 1-on-1 mentoring in static typing, compiler configuration and typed contracts across a JavaScript codebase — taught by a practitioner who runs it in production.
20 years across DevOps, SRE and Security · 10,000+ engineers trained · Trained teams at JPMorgan Chase, Verizon, Nokia and the World Bank
Principal DevOps Engineer & Architect
Rajesh teaches TypeScript around the compiler rather than the syntax — tsconfig and the strict flags, module resolution, declaration files, and where a build should type-check versus merely strip types. Sessions go deep on the parts teams get wrong in production: modelling API responses with discriminated unions and exhaustiveness checks, generics and utility types that stay readable, runtime validation at the boundary because types vanish after compilation, and a staged migration path that turns strictness on incrementally without stalling delivery.
Twenty years across DevOps, SRE and Security, in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe and others. He has trained engineers at JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus — more than 10,000 people personally. He teaches what he runs, not what he reads.
You are booked with a named engineer, and that is who turns up. Marketplaces and larger providers rotate whoever is free, so the person who sold you the agenda is rarely the person teaching it.
The same trainer is available for the next engagement, which matters when a team builds on what it learned last time.
Your batch is assigned a named trainer before it starts, and that is who teaches it. See the full faculty.
Engagements are matched on the tool, not the calendar. For TypeScript that means a trainer who has run it in production — static typing, compiler configuration and typed contracts across a JavaScript codebase — rather than whoever is free that week. You are told who is teaching before you commit, and that person is on the discovery call that shapes the agenda.
Where a batch is large enough to need a second trainer, the pairing is declared up front. The lead trainer stays accountable for the syllabus and the assessment either way.
Principal DevOps Engineer & Architect
Twenty years across DevOps, SRE and Security in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe, IBM/Emptoris, Ness, MindTree and Accenture. He has trained more than 10,000 engineers personally, at organisations including JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus. He teaches what he runs, not what he reads.
Teams of 8–30
Custom agenda, your timezone, onsite or online, NDA-friendly.
Request a quoteIndividual engineers
A private instructor and a curriculum built around your goal.
₹99,999Individuals who want peers
Scheduled batch, max 8 to 10 hours of live instruction.
₹34,999A private batch starts with a discovery call. We look at the stack you actually run — the CI system, the cloud, the constraints — and map the agenda onto it, so examples use your topology rather than a generic one.
Delivery is onsite at your premises, live online, or hybrid, scheduled around your release calendar rather than ours. Batches run 8 to 30 engineers.
Every attendee leaves with recordings, slides, lab repositories and a completion certificate. You receive an attendance and assessment report. Invoicing supports PO and GST.
Talk to us about a private TypeScript batchTypeScript is a statically typed superset of JavaScript that compiles to plain JavaScript. Every valid JavaScript file is already valid TypeScript; what the language adds is a type system that runs entirely at compile time. The compiler, tsc, checks the program against declared and inferred types, reports the errors, then erases the annotations and emits JavaScript for the target you configured. Nothing about the runtime changes, which is why TypeScript can be adopted a file at a time rather than as a rewrite.
The type system is structural rather than nominal — compatibility is decided by shape, not by declared lineage — and it is expressive enough to describe most real JavaScript patterns. Unions and intersections, literal and template literal types, generics with constraints, keyof and typeof queries, mapped and conditional types, and the utility types built from them let you model an API response, a configuration object or a state machine precisely. Narrowing turns runtime checks into compile-time knowledge, and discriminated unions with exhaustiveness checking make whole classes of missing-case bugs impossible to merge.
The rest of TypeScript is configuration and tooling. tsconfig.json controls target, module resolution, strictness and output, and the strict flags are where most of the value sits. Declaration files describe untyped libraries, DefinitelyTyped supplies them for the ecosystem, and project references and path mapping make a monorepo build incrementally. In a pipeline the compiler is a gate: tsc with noEmit runs alongside typescript-eslint and the test suite, while the actual bundle is produced by esbuild, swc or Vite, which strip types without checking them.
TypeScript has become the default for new JavaScript work. The major frameworks ship types, the large runtimes and cloud SDKs publish them, and most job specifications for frontend, Node and full-stack roles now name TypeScript rather than JavaScript. Teams that adopted it did so for a specific reason: on a codebase of any size, the compiler catches the refactoring mistakes that tests do not, and does it before code review.
The operational argument is stronger still. Most production incidents in JavaScript services trace back to a value being a different shape than the code assumed — a null where an object was expected, a renamed API field, a string where a number was intended. A type system moves those failures from three in the morning to the pull request, and typed API contracts generated from OpenAPI or a schema keep client and server honest as both evolve.
What organisations actually struggle with is not syntax but adoption. Turning strict mode on across an existing codebase, deciding where types are worth writing, keeping build times acceptable, describing third-party libraries that ship no types, and validating data at the boundary where the type system stops — those are the problems that need an experienced hand, and they are what this course is built around.
What TypeScript is, what it is not, and what happens between source and shipped JavaScript. Static against dynamic typing, compile time against run time, then a real project setup: tsc, tsconfig.json, target and module settings, editor integration, and the strict flags that decide how much the compiler is allowed to help.
Topics: What TypeScript adds to JavaScript, and what it erases · Static and dynamic typing, compile time and run time · Installing and running the TypeScript compiler · tsconfig.json — target, lib, module, outDir, sourceMap · Module resolution strategies and path mapping · The strict family of flags, one by one · Editor tooling, the language server and the TypeScript playground · Type checking versus type stripping in modern build tools
The core of the language. Primitives and the special types, where annotations are needed and where inference is better left alone, unions and intersections, literal types, arrays and tuples, enums and their alternatives, then narrowing — how runtime checks give the compiler information.
Topics: Primitives, arrays, tuples and object types · any, unknown, never and void, and when each is correct · Type inference and when to annotate explicitly · Union and intersection types · Literal types, const assertions and readonly · Enums, union-of-literals and the trade-off between them · Narrowing with typeof, instanceof, in and truthiness · Type predicates and user-defined type guards · Optional properties, null, undefined and strictNullChecks
Typing the structures code is organised into. Parameter and return types, optional and default parameters, overloads, arrow functions and this-typing, then classes with access modifiers, abstract members and implements, and interfaces against type aliases with a clear rule for choosing.
Topics: Function parameter and return types, optional and default parameters · Function overloads and call signatures · Arrow functions, this typing and context · Defining classes, fields, methods and constructors · Access modifiers, readonly, static and abstract members · Implementing interfaces and extending classes · Interfaces versus type aliases, and declaration merging · Structural typing and excess property checking · Index signatures and Record types
How reusable code keeps its types. Generic functions, classes and constraints, then the type-level toolkit — keyof and typeof queries, mapped and conditional types, infer, template literal types and the utility types built from them — with a hard limit on cleverness, since types nobody can read are a liability.
Topics: Generic functions, classes and interfaces · Type parameter constraints and defaults · keyof, typeof and indexed access types · Mapped types and modifiers · Conditional types and infer · Template literal types · Utility types — Partial, Required, Pick, Omit, Record, ReturnType, Awaited · Variance, assignability and common inference failures · When a simpler type is the better engineering decision
TypeScript across more than one file and more than one package. ES modules and resolution, ambient declarations and .d.ts authoring, DefinitelyTyped, describing a library that ships no types, then project references, path mapping and the layout that keeps a monorepo building incrementally.
Topics: ES modules, import and export, and module resolution modes · Ambient declarations and global augmentation · Writing and shipping .d.ts declaration files · DefinitelyTyped and the @types packages · Typing a third-party library that has no types · Declaration output, declarationMap and consuming your own packages · Project references and incremental builds · Path aliases and monorepo layout · Common interop problems with CommonJS packages
The single most misunderstood property of TypeScript: types are erased, so nothing at the edge of the program is guaranteed. Where the boundaries are, how to validate at each of them, schema-based validation with inferred types, typed API clients generated from contracts, and error modelling that survives compilation.
Topics: Why a type assertion is not a runtime check · Identifying boundaries — HTTP, storage, environment variables, configuration, message queues · Schema validation with inferred static types · JSON Schema and OpenAPI as the source of truth · Generating typed clients from an API contract · Parsing environment and configuration safely at startup · Modelling errors — result types, discriminated unions and exhaustiveness · Keeping generated types in sync in CI
How typed code becomes a shipped artefact. tsc against esbuild, swc and Vite, what each does and does not check, declaration emit and source maps, typescript-eslint rules that need type information, and testing typed code — unit tests, mocks that keep their types, and type-level assertions.
Topics: tsc, esbuild, swc and bundler-based builds — checking versus stripping · Emitting declarations, source maps and build artefacts · Build performance — incremental builds, isolatedModules and skipLibCheck · ESLint with typescript-eslint and type-aware rules · Unit testing with Vitest or Jest, and typed mocks · Type-level tests and expect-error assertions · Coverage, and what type safety does not replace · Publishing a typed package to a registry
The real problem for most teams. Assessing a JavaScript codebase, choosing a migration order, allowJs and checkJs, JSDoc-based typing as a first step, the strictness ratchet, handling the any backlog, and a CI gate that stops new untyped code arriving faster than old code is fixed.
Topics: Auditing an existing codebase and choosing a migration order · allowJs, checkJs and JSDoc type annotations without renaming files · File-by-file conversion and the ts-expect-error escape hatch · The strictness ratchet — turning flags on without stopping delivery · Managing the any backlog and measuring type coverage · Typing legacy patterns — dynamic objects, callbacks, event emitters · CI gates that prevent regression, and codeowner review rules · Team conventions, review standards and onboarding
We rebuild the agenda around the tools you actually run.
Request a custom agendaStart from an empty project, enable each strict flag in turn, record the errors it surfaces, and end with a baseline configuration and a written justification per setting.
Model a multi-state domain object with discriminated unions so the compiler forces every case to be handled, then prove a missing case fails the build.
Replace unchecked casts on API responses, environment variables and stored data with schema validation whose inferred types drive the rest of the code.
Write declaration files for a library that ships no types, wire them into the project, and publish them so the rest of the organisation inherits the work.
Split a slow build into an esbuild bundle step and a tsc noEmit check running in parallel in CI, and measure the pipeline time before and after.
Convert a real module set, add a type-coverage threshold and a type-check gate, and produce a staged plan that lets the rest of the codebase follow without a freeze.
Billed yearly at ₹9,996
Max 8 to 10 hours of live instruction
Full program, private instructor
8–30 engineers · custom agenda · onsite or online · PO and GST invoicing
Refunds. If we cancel or postpone a cohort, you get a full refund within 15 days. There is no money-back guarantee otherwise.
Terms. Course material remains licensed to the attendee. Read the terms.
Your data. We don't share it with third parties. Privacy policy.
Certificate of completion
Very detailed explanation and has lots of patience in attending the questionnaire. Thanks again for your wonderful sessions.
Good discussion, helped us to understand different tools in SRE.
Got good lab sessions which kept the new DevOps tool learnings to the point and it helped a lot in my career.
I took Terraform training with the tutor named Mithilesh. I requested to tailor the course curriculum for my needs. He did an excellent job of showing me how to write the Terraform script per the instructions provided.
My experience with the AIOps training was positive. The course covered important topics in a structured way, and Rajesh Kumar explained the concepts patiently. I found the practical aspects particularly helpful because they made the technical content easier to understand.
I was looking to improve my understanding of AIOps, and this training helped me achieve that goal. Rajesh Kumar explained the subject in a structured and practical manner. The sessions on different AIOps concepts were informative.
| What matters | YouTube + blogs | Generic online course | Freelance marketplace | DevOpsSchool |
|---|---|---|---|---|
| Named practitioner | No | Rarely | Varies per booking | Yes — same trainer each time |
| Production experience | Unknown | Unknown | Unverified | 20 years, named employers |
| Custom agenda | No | No | Sometimes | Built from your stack |
| Onsite delivery | No | No | Sometimes | Yes |
| Lab environment | None | Sandbox that expires | Varies | Your own cloud — skill goes with you |
| Assessment | None | Quiz | Rarely | Assignments + capstone per module |
| Per-attendee certificates | No | Sometimes | Rarely | Yes |
| Corporate invoicing | No | Limited | Varies | PO and GST |
| Post-training support | None | Forum, time-limited | None | Lifetime forum access |
Tell us the team, the stack and the timeline. You'll get a straight answer, not a sales sequence.
Talk to an advisorPrefer to call or email?
More ways to reach us on the contact page.