- What This Cheat Sheet Covers (and What the CLD Actually Is)
- Format, Rubric and Logistics at a Glance
- The 40-Point Rubric Math
- The Ten Exam Topics in Compressed Form
- Architecture Patterns You Must Be Able to Write From Memory
- Timing and Error Handling Quick Reference
- Documentation and Testing: The Points People Forget
- Allowed Resources, Prohibited Resources and Booking Notes
- A Domain-Ordered Prep Sequence
- Frequently Asked Questions
- The CLD is a four-hour practical: you build a working LabVIEW application from a specification, software only, no hardware.
- Grading uses a 40-point rubric: Programming style 15, Functionality 15, Documentation 10. The passing criterion is 28/40 (70%).
- Documentation is only 10 points but represents 25% of the rubric, a cheap margin many candidates leave on the table.
- Built-in LabVIEW Help, examples and templates are permitted; externally developed VIs or resources are prohibited.
What This Cheat Sheet Covers (and What the CLD Actually Is)
This page is a one-screen review of the facts that matter most for the Certified LabVIEW Developer credential issued by National Instruments (NI). Here, "CLD" means exactly that: the developer-level LabVIEW certification, nothing else. If you are brand new to the credential, start with What Is CLD Certification? and come back once the basics are settled.
The single most important fact on this sheet is the format. The initial CLD is an application-development practical examination, not a multiple-choice test. You are handed a specification and you build a working LabVIEW application within four hours. That changes how you should study: reading about patterns helps, but only building complete applications under a clock builds the skill the rubric actually grades.
Format, Rubric and Logistics at a Glance
| Item | Fact | |
|---|---|---|
| Issuer | National Instruments Corporation (NI) | |
| Exam type | Practical application-development examination | |
| Duration | Four hours | |
| Scope | Software development only, without hardware | |
| Scoring | 40-point rubric: Programming style 15, Functionality 15, Documentation 10 | |
| Passing criterion | 28/40 points (70%) | |
| Scheduling | Pearson VUE, with an NI OnVUE online-testing route | |
| Prerequisite | None mandatory; 12-18 months of LabVIEW development experience recommended | |
| Validity | Three years |
On experience: NI recommends 12-18 months of LabVIEW development experience, and completing Core 1, Core 2 and Core 3 may substitute for three months of that experience. The older preparation guide listed a mandatory CLAD prerequisite, but the current credential page lists no prerequisite certification. For the full eligibility picture, see CLD Requirements: Eligibility, Prerequisites and How to Qualify.
For fee details and current scheduling windows, rely on the live booking pages rather than anything memorized from older material. Our breakdowns in CLD Certification Cost and CLD Exam Dates explain how to confirm both.
The 40-Point Rubric Math
The rubric is the scoreboard, so understand its arithmetic before you build anything. The official preparation guide (100900A-01) separates the grading into three categories:
- Programming style: 15 points (37.5% of the rubric)
- Functionality: 15 points (37.5% of the rubric)
- Documentation: 10 points (25% of the rubric)
The passing criterion is 28 of 40 points, or 70%. That means you can miss up to 12 points and still pass. Three working conclusions follow.
- A flawless but undocumented app can still fail. Dropping all 10 documentation points leaves a ceiling of 30, so any further slip in style or function becomes dangerous.
- A beautiful but incomplete app can also fail. Style alone cannot reach 28 because style and documentation together cap at 25 points.
- Documentation is the cheapest margin. It rewards habits you control completely, with no dependency on solving a hard algorithmic problem.
The Ten Exam Topics in Compressed Form
The ten topics below come from NI's preparation guide and map onto the skills the practical grading rewards. For a fuller treatment of each, see CLD Exam Domains: Complete Guide to All 10 Content Areas.
Domain 1: Design Concepts
The vocabulary of good architecture, applied to your own code.
- Modularity, scalability, readability and maintainability
- Cohesion (each module does one job) and coupling (modules depend on each other as little as possible)
- Hierarchical and file-based organization of your project
Domain 2: User Interface Design
A front panel that is clear, grouped and well-behaved.
- Color, grouping, control and indicator properties, and custom objects
- Static and dynamic state at initialization and at stop
- Meaningful icons and a panel a first-time user can operate
Domain 3: Block Diagram Layout and Style
Readable data flow is a graded behavior.
- Left-to-right data flow, no overlapping wires or hidden objects
- Diagrams that fit on one screen where practical
- Consistent, tidy wiring so a reviewer can follow it without effort
Domain 4: Programming Practices
Choosing the right building blocks.
- Data elements, functions versus subVIs, and structures
- References and property nodes, used deliberately rather than by habit
Domain 5: SubVI Design Practices
Reusable, self-explanatory modules.
- Clean front panels and connector panes for each subVI
- Meaningful icons and consistent terminal placement
Domain 6: Architecture Selection
Matching the pattern to the specification (details in the next section).
Domain 7: Timing
Controlling when and how fast things run (details below).
Domain 8: Error Handling
Detecting, propagating and reporting errors (details below).
Domain 9: Documentation
Front-panel, block-diagram and VI-property documentation.
Domain 10: Testing
Reviewing your own code and documentation, and confirming functionality and error behavior.
Architecture Patterns You Must Be Able to Write From Memory
Architecture Selection is where the practical is usually won or lost, because the pattern you pick determines whether your application is scalable, maintainable and responsive. NI's guide emphasizes nonblocking, responsive designs, so the UI must never freeze while background work happens. The patterns named in the official topic overview are:
| Pattern | Use it when |
|---|---|
| Simple state machine | The application moves through a defined sequence of states (initialize, run, shut down) |
| UI event handler | The program should react to front-panel interaction without polling |
| Queued message handler | Commands must be processed in order, often from several sources |
| Data/event producer-consumer | Acquiring or generating data must not be slowed by processing or UI work |
| Functional global variable | Shared data needs controlled access from multiple places |
Practice writing each skeleton until you can lay it down in minutes, because every minute spent reinventing structure is a minute not spent on functionality and documentation. A common practical combines an event structure for the user interface with a queued message handler for processing, which is why the producer-consumer arrangement deserves your most repetition.
Key Takeaway
Do not choose the fanciest architecture; choose the simplest one that satisfies the specification and stays responsive. Reviewers reward clarity and a design that matches the requirements, not cleverness.
Timing and Error Handling Quick Reference
Timing
The official topic overview lists the timing tools you should know and know how to choose between:
- Timing functions for controlling loop rate and measuring elapsed time
- Event and synchronization timeouts so waits never block forever
- Timed structures where deterministic timing behavior is needed
- Timing Express VIs for quick, configurable timing needs
The practical question is always: what could make this loop hog the processor or hang? Every loop should either wait on an event, a timeout or a timing function.
Error Handling
Error handling is graded as part of both style and functionality, so treat it as a first-class feature:
- Wire the error cluster through every subVI and keep error flow visibly connected
- Stop loops on error where that is the correct behavior
- Report errors to the user in a clear way rather than silently swallowing them
- Make sure the application still shuts down cleanly after an error
Documentation and Testing: The Points People Forget
Documentation carries 10 of the 40 points, and the official topic overview names three places to document your work: the front panel, the block diagram and the VI properties. Make a short habit-checklist and run it on every VI you save:
- Fill in the VI description in VI properties
- Add descriptions or tip strips to controls and indicators where they help
- Label wires, structures and non-obvious sections of the block diagram
- Give every subVI a meaningful name and icon
The Testing topic covers reviewing your code and documentation and checking functionality and errors. In a four-hour practical, reserve the final stretch for a review pass: run the application against each requirement in the specification, force an error condition, confirm a clean stop, and re-read your documentation. Candidates who skip this pass often lose points they had already earned in the build.
Allowed Resources, Prohibited Resources and Booking Notes
Per NI's guide, the built-in LabVIEW Help, examples and templates are permitted during the exam, while externally developed VIs or resources are prohibited. Practice with exactly that toolset, so you know where the useful examples and templates live and do not waste time hunting.
On logistics, the older guide describes USB-based delivery, software versions and local proctoring. Those details are historical. Current NI delivery runs through Pearson VUE with a secured virtual machine for performance-based exams, and an NI OnVUE online-testing route is available. Confirm the assigned software image and candidate rules through the current booking instructions, not the guide's older delivery section, and review NI's online exam preparation page before test day.
| Topic | Use current sources for | Treat as historical |
|---|---|---|
| Delivery | Pearson VUE scheduling and OnVUE route | USB and local-proctor logistics in the 2012 guide |
| Prerequisites | Current NI credential page (none mandatory) | Mandatory CLAD requirement in the old guide |
| Software image | Current booking instructions | Version details in the old guide |
After You Pass: Validity and Recertification
The credential is valid for three years. NI's recertification policy, updated April 30, 2026, allows renewal by examination and offers Recertification by Points to developer-level and architect-level professionals. CLD-R is a distinct recertification examination and should not be used to infer the format or question count of the initial CLD. If you are weighing the long-term payoff, see Is the CLD Certification Worth It? and CLD Salary Guide; for hiring context, browse CLD Jobs.
A Domain-Ordered Prep Sequence
Because the exam is a build, prepare by building. The sequence below orders the ten topics so that each week's practice feeds the next. Adjust the pacing to your experience level and available hours.
Foundations: Design Concepts, UI, Diagram Style
- Rebuild a small application focusing purely on cohesion, coupling and readable wiring
- Apply consistent front-panel grouping and icon conventions
Building Blocks: Programming Practices and SubVI Design
- Practice deciding what becomes a subVI and designing clean connector panes
- Use references and property nodes only where they earn their place
Architecture Selection, Timing and Error Handling
- Write each pattern skeleton from a blank VI until it is automatic
- Add timeouts and error flow to every loop you create
Documentation, Testing and Timed Full Builds
- Build full applications from original specifications in four-hour sessions
- Score yourself against the 40-point rubric, then fix the weakest category
Self-assessment is the key feedback loop: grade each practice build honestly against Programming style (15), Functionality (15) and Documentation (10), and track which category keeps costing you points. When you want structured practice beyond your own exercises, the CLD Exam Prep practice site offers rubric-oriented review material designed to supplement, not replace, hands-on building. You can also explore CLD Training options for guided instruction, and return to the main practice test hub as your weekly checkpoint.
Key Takeaway
The best predictor of a pass is how many complete, timed, self-graded builds you have finished, not how many pages you have read. Build from original specifications and score every attempt against the rubric.
Frequently Asked Questions
No. The initial CLD is a four-hour practical in which you build a working LabVIEW application from a specification, software only and without hardware. There is no published multiple-choice question count for it.
The passing criterion in NI's preparation guide is 28 of 40 points (70%). The 40 points divide into Programming style (15), Functionality (15) and Documentation (10).
No. The guide permits the built-in LabVIEW Help, examples and templates but prohibits externally developed VIs or resources. Practice using only the built-in material.
The current NI credential page lists no prerequisite certification, although the older guide mentioned CLAD. NI recommends 12-18 months of LabVIEW development experience, and Core 1, Core 2 and Core 3 may substitute for three months of it.
It is valid for three years. NI's recertification policy, updated April 30, 2026, allows renewal by examination and offers Recertification by Points to developer-level and architect-level professionals.