- How the Ten Domains Relate to the Practical Exam
- Domains 1-3: Design Concepts, User Interface, and Block Diagram Style
- Domains 4-6: Programming Practices, SubVIs, and Architecture Selection
- Domains 7-10: Timing, Error Handling, Documentation, and Testing
- Mapping Domains to the 40-Point Rubric
- Domain Quick-Reference Table
- Sequencing Your Preparation by Domain
- Exam Logistics That Affect Domain Preparation
- Frequently Asked Questions
- The CLD is a four-hour practical: you build a working LabVIEW application from a specification, not answer multiple-choice questions.
- NI's guide lists ten Exam Topics but publishes no percentage weights for them.
- The 40-point rubric splits Programming style 15, Functionality 15, and Documentation 10; passing is 28/40.
- Built-in LabVIEW Help, examples, and templates are allowed; externally developed VIs and resources are prohibited.
How the Ten Domains Relate to the Practical Exam
The first thing to understand about the Certified LabVIEW Developer exam is that its ten content areas are not ten sections of a test. National Instruments (NI) lists them as the Exam Topics in its CLD preparation guide (100900A-01), and they describe the knowledge a developer needs. The exam itself is a practical application-development examination: you receive a specification and have four hours to build a working LabVIEW application. It is software development only, with no hardware involved.
That distinction shapes how you should read the domain list. NI publishes no percentage weights for the ten topics, so any claim that "Architecture Selection is 20% of the exam" is an editorial invention. What NI does publish is a separate 40-point evaluation rubric used to score your finished work. The domains feed into that rubric indirectly: good design, clean diagrams, sound architecture, and solid documentation all show up as points in Programming style, Functionality, and Documentation.
If you are still orienting yourself to the credential, our overview pages on what CLD certification is and CLD requirements and eligibility cover the basics. This article goes domain by domain through what each topic means in practice.
Domains 1-3: Design Concepts, User Interface, and Block Diagram Style
The first three domains are about structure and presentation. They are also the domains where many otherwise capable programmers lose style points, because the work is easy to skip when a deadline is tight.
Domain 1: Design Concepts
Design Concepts
NI's topic overview ties this domain to the qualities of a well-built application and the way it is organized on disk and in memory.
- Modularity: break the application into discrete, independently understandable pieces.
- Scalability: a design that accepts new requirements without a rewrite.
- Readability and maintainability: another developer can follow and modify the code.
- Cohesion and coupling: each module does one job (high cohesion) and depends minimally on others (low coupling).
- Hierarchical and file design: a sensible VI hierarchy and file organization.
In a four-hour build, Design Concepts is what you do in the first fifteen or twenty minutes. Reading the specification, identifying the distinct responsibilities (acquisition, processing, logging, user interface), and sketching a hierarchy before placing a single node pays off throughout the rest of the session. Candidates who start wiring immediately often discover midway that their design cannot accommodate a requirement they skimmed.
Domain 2: User Interface Design
User Interface Design
The front panel is part of what is evaluated, not just a means of running the code.
- Front-panel color, grouping, and properties that make the interface clear.
- Custom objects where they genuinely improve the interface.
- Static and dynamic state at initialization and at stop: controls and indicators should start and finish in sensible conditions.
- Meaningful icons for the VIs you create.
A frequently overlooked item is the initialization and stop state. A panel that launches with stale values, or a program that leaves indicators in an inconsistent state after stopping, signals carelessness. Build the habit of deciding, for every control and indicator, what it should show when the program starts and when it ends.
Domain 3: Block Diagram Layout and Style
Block Diagram Layout and Style
This domain covers how legible your diagram is as a picture of data flow.
- Data flow that reads clearly in a consistent direction.
- Diagram readability: wires that are straight and uncluttered, nodes that are aligned, and structures that are sized sensibly.
- Avoiding diagram sprawl by pushing logic into subVIs rather than letting one diagram grow unwieldy.
Because Programming style carries 15 of the 40 rubric points, diagram tidiness is worth deliberate practice. Reserve a few minutes near the end of your session to clean up wiring and alignment. It is cheap insurance.
Domains 4-6: Programming Practices, SubVIs, and Architecture Selection
These three domains are the technical core. They determine whether your application actually works and whether it is built in a way a reviewer would call professional.
Domain 4: Programming Practices
Programming Practices
Choosing the right building blocks and using them correctly.
- Appropriate data elements and data types for the job.
- Functions versus subVIs: knowing when to wrap logic in its own VI.
- Structures: loops, case structures, and event structures used appropriately.
- References and property nodes, including when they are warranted and when plain data flow is better.
A common trap is overusing references and property nodes to read and write front-panel values when data flow would be cleaner and faster. Part of this domain is restraint: prefer wires over references wherever the design permits.
Domain 5: SubVI Design Practices
SubVI Design Practices
A subVI is a unit of reuse, and graders look at how well each one is packaged.
- Modular subVIs with a single, clear purpose.
- A deliberate front panel and connector pane: sensible terminal placement, required versus recommended inputs, and consistent patterns.
- A recognizable icon that conveys what the subVI does.
Connector pane discipline is worth drilling. Using a consistent layout, with inputs on the left, outputs on the right, and error clusters in the standard bottom corners, makes your subVIs predictable and speeds up your own wiring. It also supports the Documentation portion of the rubric, since a well-labeled subVI explains itself.
Domain 6: Architecture Selection
This is the domain most people think of when they imagine the CLD, and it is where the specification most directly influences your choices. NI's topic overview describes the goal as a design that is scalable, maintainable, and responsive, using nonblocking approaches. The patterns it names are:
- Simple state machine
- UI event handler
- Queued message handler
- Data or event producer-consumer
- Functional global variable
Responsiveness is the key word. A user interface that freezes while a long operation runs fails the "nonblocking" expectation. Practice recognizing the specification phrases that signal a need to decouple the UI from processing, and rehearse building each named pattern from a blank diagram until the skeleton takes minutes, not half an hour. For a broader view of how difficult candidates find this stage, see how hard the CLD exam is.
Domains 7-10: Timing, Error Handling, Documentation, and Testing
Domain 7: Timing
Timing
Control over when and how fast things happen in your application.
- Timing functions for controlling loop rates and delays.
- Timeouts on events and synchronization primitives such as queues, so that code does not wait forever.
- Timed structures and timing Express VIs where they suit the task.
The practical lesson is to avoid unbounded loops that consume the processor and unbounded waits that can hang the program. Every loop should have a deliberate timing mechanism, and every blocking wait should have a sensible timeout.
Domain 8: Error Handling
Error Handling
A robust application detects, reports, and responds to errors rather than ignoring them.
- Wiring error clusters through your subVIs consistently.
- Error reporting that surfaces problems to the user in a useful way.
- Ensuring that an error terminates or redirects execution appropriately rather than being silently dropped.
Error handling is easy to defer and then forget. A reliable habit is to add the error terminals and wire the error chain as you create each subVI, instead of retrofitting them at the end. The retrofit is tedious and frequently incomplete.
Domain 9: Documentation
Documentation
Documentation has its own 10 points in the rubric, a full 25% of the score, so it is not an afterthought.
- Front-panel documentation: labels and descriptions that help a user.
- Block-diagram documentation: comments that explain intent, not just restate the code.
- VI properties documentation: descriptions that explain what each VI does.
Many strong programmers underinvest here and surrender points that are among the easiest to earn. Fill in the VI description for every VI, label your subdiagrams and structures, and add concise diagram comments where the reasoning is not obvious.
Domain 10: Testing
Testing
Verifying your own work before you submit it.
- Code and documentation review: reading your own submission critically.
- Confirming functionality against each requirement in the specification.
- Finding and fixing errors through deliberate testing.
Testing is what protects your Functionality points. Reserve time at the end to run through the specification line by line and exercise each requirement. A feature you believe works but never ran is a feature that may not.
Key Takeaway
Budget your four hours so that design happens first and review happens last. Skipping either end is the most common way capable developers lose points on a build they otherwise executed well.
Mapping Domains to the 40-Point Rubric
NI's preparation guide supplies a separate evaluation rubric worth 40 points. It is important not to confuse these rubric categories with the ten domain headings: the rubric is how your finished application is graded, while the domains describe the underlying knowledge. A passing result requires 28 of 40 points, or 70%. For more on how the threshold works, see our CLD passing score breakdown.
| Rubric Category | Points | Share of 40 | Domains That Feed It Most Directly |
|---|---|---|---|
| Programming style | 15 | 37.5% | User Interface Design, Block Diagram Layout and Style, Programming Practices, SubVI Design Practices |
| Functionality | 15 | 37.5% | Architecture Selection, Timing, Error Handling, Testing |
| Documentation | 10 | 25% | Documentation, SubVI Design Practices |
Note that the domain-to-rubric mapping above is our editorial interpretation of how the skills tend to surface in grading; NI does not publish a formal crosswalk. Design Concepts underlies all three categories, since a well-organized application tends to score well across the board.
Domain Quick-Reference Table
| # | Domain | What a Grader Can See |
|---|---|---|
| 1 | Design Concepts | Modular hierarchy, low coupling, sensible file organization |
| 2 | User Interface Design | Grouped, clearly labeled panel; correct initial and stop states; icons |
| 3 | Block Diagram Layout and Style | Clean left-to-right data flow, tidy wiring |
| 4 | Programming Practices | Appropriate data types, structures, and restrained use of references |
| 5 | SubVI Design Practices | Consistent connector panes, clear icons, single-purpose subVIs |
| 6 | Architecture Selection | A pattern that fits the spec and keeps the UI responsive |
| 7 | Timing | Controlled loop rates, timeouts, no runaway or hanging loops |
| 8 | Error Handling | Error clusters wired throughout and reported to the user |
| 9 | Documentation | VI descriptions, labels, and meaningful diagram comments |
| 10 | Testing | Requirements verified, errors found and corrected |
Sequencing Your Preparation by Domain
Because the exam rewards integrated, fast construction, the most effective plan builds individual skills first and then combines them under time pressure. The sequence below is one reasonable ordering; adjust it to your experience level. Our CLD study guide covers the broader preparation picture in more depth.
Foundations: Domains 1-3
- Practice reading a spec and sketching a VI hierarchy before coding.
- Build panels with deliberate initial and stop states.
- Rework old diagrams until the data flow reads cleanly.
Building Blocks: Domains 4-5
- Drill connector pane layouts and icon creation until they are automatic.
- Replace unnecessary property nodes with plain data flow.
Architecture: Domain 6
- Build each named pattern from a blank diagram: state machine, UI event handler, queued message handler, producer-consumer, and functional global variable.
- Practice matching spec phrases to the right pattern.
Robustness: Domains 7-8
- Add timeouts and loop timing to every exercise.
- Wire error handling as you build, never after.
Integration: Domains 9-10 plus full builds
- Complete full four-hour builds against original specifications.
- Self-score each attempt against the 40-point rubric.
- Reserve the final stretch of each build for documentation and testing.
The reason architecture sits in the middle of the sequence is that patterns are much easier to learn once you can already wire subVIs and handle errors fluently. The reason full builds come last is that the real exam tests integration: knowing each domain in isolation is necessary but not sufficient.
Practice with original exercises, not a question bank
Because the initial CLD is a practical examination, conceptual questions are only supplementary. The most valuable preparation is writing your own specifications, building the applications, and scoring them against the rubric. Our CLD practice resources are designed to support knowledge review alongside that coding work, not to replace it, and nothing there should be mistaken for the actual exam format.
Exam Logistics That Affect Domain Preparation
A few practical facts shape how you should rehearse:
- Resources allowed: NI's guide permits built-in LabVIEW Help, examples, and templates. Externally developed VIs and outside resources are prohibited, so you cannot bring a personal library of reusable code. Practice with only what ships with LabVIEW.
- Delivery: NI's current scheduling partner is Pearson VUE, with an NI OnVUE online-testing route. Confirm the assigned software image and candidate rules through the current booking instructions rather than relying on the older guide's delivery instructions, which are historical.
- Experience: NI lists no mandatory prerequisite and recommends 12 to 18 months of LabVIEW development experience. Completing Core 1, Core 2, and Core 3 can substitute for three months of that experience. See CLD requirements for details.
- Validity: the certification 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.
For scheduling specifics, check our guide to CLD exam dates and scheduling, and for budgeting, the CLD certification cost breakdown. If you are weighing whether the effort is justified, our ROI analysis takes that question on directly.
Frequently Asked Questions
No. NI's preparation guide lists ten Exam Topics but publishes no percentage weights for them. The only published scoring structure is the 40-point rubric: Programming style 15, Functionality 15, and Documentation 10. Passing is 28 of 40 points.
No. The initial CLD is a four-hour practical application-development examination in which you build a working LabVIEW application from a specification. It is software development only, without hardware. Conceptual review can supplement your preparation but cannot substitute for building applications.
Architecture Selection is usually the highest-leverage area because a poor pattern choice undermines Functionality and style at once. That said, do not neglect Documentation: it is worth 10 of 40 points and is among the easiest points to earn with a little discipline.
No. NI's guide permits built-in LabVIEW Help, examples, and templates, but prohibits externally developed VIs and resources. Prepare using only what ships with LabVIEW so your practice matches exam conditions.
The domains describe the skills; the rubric converts them into points. A passing score is 28 of 40, or 70%. Because style, functionality, and documentation are all scored, a strong build in one area cannot fully compensate for neglect elsewhere. See our passing score guide and pass rate discussion for more context.