- What You Are Actually Preparing For
- Reading the 40-Point Rubric Before You Read Anything Else
- The Ten Exam Topics, Grouped by How They Show Up in Your Score
- Architecture Selection: The Decision You Make in the First Ten Minutes
- Original Practice Builds That Mirror the Real Task
- A Domain-Ordered Study Schedule
- Registration, Rules and Exam-Day Logistics
- Validity, Recertification and Where the Credential Pays Off
- Frequently Asked Questions
- The Certified LabVIEW Developer exam is a four-hour practical build from a specification, not a multiple-choice test.
- Scoring is a 40-point rubric: Programming style 15, Functionality 15, Documentation 10; 28/40 (70%) passes.
- Documentation is 25% of the rubric, so unfinished-but-documented work can outscore finished-but-undocumented work.
- Built-in LabVIEW Help, examples and templates are allowed; externally developed VIs and resources are prohibited.
What You Are Actually Preparing For
Most certification study advice assumes a bank of questions and a score report. The Certified LabVIEW Developer (CLD) from National Instruments works differently. It is a practical application-development examination: you receive a specification and have four hours to build a working LabVIEW application from it. The scope is software development only, with no hardware involved. Nobody is checking whether you can recall a function palette location; a grader is checking whether the application you built behaves as specified and whether another engineer could maintain it.
That changes how you should prepare. Reading about LabVIEW is useful for filling knowledge gaps, but the skill being assessed is the ability to design, build, test and document under a clock. If you are new to the credential itself, our overview pages on what CLD certification is and what CLD stands for cover the basics; this guide assumes you already know you want the Certified LabVIEW Developer credential and need a plan to pass it.
Reading the 40-Point Rubric Before You Read Anything Else
NI's preparation guide (100900A-01, copyright 2012) includes a separate 40-point evaluation rubric. Understanding it is the highest-leverage study activity available to you, because it tells you where points actually come from.
| Rubric Category | Points | Share of 40 | What Graders Look For |
|---|---|---|---|
| Programming style | 15 | 37.5% | Block diagram readability, data flow, subVI design, UI quality, error handling |
| Functionality | 15 | 37.5% | Does the application meet the specification and run without errors |
| Documentation | 10 | 25% | Front panel, block diagram and VI property documentation |
| Passing criterion | 28 of 40 points (70%) | ||
Two things stand out. First, the shares above are calculated rubric percentages for grading, not weights for the ten exam topics; NI does not publish percentage weights for the topics. Second, Documentation carries a quarter of the available points. Candidates who treat documentation as something to do "if time remains" are voluntarily capping themselves. With 28 required out of 40, losing most of the 10 documentation points leaves almost no margin for style or functional mistakes. For more on how the threshold works, see our breakdown of the CLD passing score.
The Ten Exam Topics, Grouped by How They Show Up in Your Score
NI's guide lists ten exam topics. Because the exam is graded by rubric, it helps to think about which topics feed which scoring category. The mapping below is a study aid, not an official weighting. For a deeper walkthrough of each area, read our complete guide to all 10 CLD content areas.
Topics that mostly drive Programming Style
Domain 1: Design Concepts
The vocabulary of good design: modularity, scalability, readability, maintainability, cohesion, coupling, and hierarchical and file design.
- Be able to explain why a subVI has one clear job (cohesion) and depends on as little as possible (coupling).
- Plan your VI hierarchy and file organization before dropping the first structure on the diagram.
Domain 2: User Interface Design
Front-panel color and grouping, control and indicator properties, custom objects, and the static or dynamic state of the interface at initialization and stop.
- Decide what the user sees when the VI loads and what happens to controls when the application stops.
- Consistent grouping and sensible labels cost minutes and protect style points.
Domain 3: Block Diagram Layout and Style
Data flow and diagram readability. The diagram should read left to right, wires should not hide behind objects, and nothing should require a graders' guesswork.
Domain 4: Programming Practices
Choosing appropriate data elements, functions and subVIs, structures, references and property nodes.
- Know when a property node is justified and when a simple wire would do.
- Avoid overuse of references where data flow is cleaner.
Domain 5: SubVI Design Practices
Modular subVI design, including a sensible front panel, a tidy connector pane and a meaningful icon. Graders open your subVIs; each one is a small piece of evidence about your habits.
Topics that mostly drive Functionality
Domain 6: Architecture Selection
Choosing a scalable, maintainable, responsive and nonblocking structure. The patterns NI names are the simple state machine, UI event handler, queued message handler, data or event producer-consumer, and functional global variable.
Domain 7: Timing
Timing functions, event and synchronization timeouts, timed structures and timing Express VIs. A UI that freezes or a loop that spins without waiting is a functional and stylistic defect at once.
Domain 8: Error Handling
Detecting, propagating and reporting errors. Wire error clusters through your subVIs and decide what the user should see when something fails.
Topics that mostly drive Documentation and Self-Review
Domain 9: Documentation
Front-panel documentation, block-diagram documentation and VI properties. Each of these is a distinct place a grader looks.
Domain 10: Testing
Code and documentation review, verifying functionality, and catching errors in testing. This is your reserved final pass, not an afterthought.
Architecture Selection: The Decision You Make in the First Ten Minutes
The architecture you choose shapes everything after it, so it deserves deliberate practice. NI's guide names five patterns relevant to this credential. The table below is a drill sheet: for each pattern, practice recognizing the specification features that point toward it.
| Pattern | Typically Suits | Watch Out For |
|---|---|---|
| Simple state machine | Sequential processes with clearly defined steps and transitions | Responsiveness if the UI must stay live during long steps |
| UI event handler | Applications driven mainly by user actions on the front panel | Putting long-running work inside event cases |
| Queued message handler | Applications needing ordered, command-style processing | Message definitions that grow messy without discipline |
| Data or event producer-consumer | Parallel work where acquisition or generation must not block processing | Unbounded buffering and shutdown coordination |
| Functional global variable | Shared state needing controlled, serialized access | Overusing it as a substitute for proper data flow |
Real specifications often combine patterns, such as a UI event handler loop paired with a consumer loop fed by a queue. Practice reading a spec and writing a three-line architecture plan before touching the diagram. If you can name the loops, how they communicate, and how they stop cleanly, you have already earned much of the Functionality and Style credit.
Original Practice Builds That Mirror the Real Task
Because you cannot memorize your way through a build exam, your preparation should be a series of timed builds followed by honest grading against the rubric. Create your own specifications, or have a colleague write them, so you are not rehearsing against a leaked or recycled task.
- Write a specification yourself. Keep it realistic: a handful of user-facing requirements, a data-processing requirement, and at least one requirement that forces a design decision (for example, continuous operation that must remain responsive).
- Set a four-hour timer. Use only built-in LabVIEW Help, shipped examples and templates, which matches what the guide permits. Do not import VIs written outside LabVIEW's own resources.
- Build in layers. Get a minimal working core first, then add features, then polish.
- Document as you go. Describe each subVI and control while it is fresh, rather than saving everything for the end.
- Score yourself on the 40-point rubric. Be harsh. Mark Programming style out of 15, Functionality out of 15, Documentation out of 10, and note exactly which points you lost and why.
- Repeat with a different architecture. A second build that forces a different pattern teaches more than polishing the first.
Key Takeaway
Track your self-scores across builds. If Documentation keeps landing under 7 of 10, that is the cheapest gap to close. If Functionality is the weak category, the issue is usually architecture choice or an unhandled requirement, not typing speed.
If you want to check your conceptual knowledge between builds, the practice material on our main practice test site can help with topic-level review, but remember it supplements building and does not replace it.
A Domain-Ordered Study Schedule
You can adapt the length of this plan to your experience. NI recommends 12-18 months of LabVIEW development experience before attempting the credential, so this schedule is meant for someone who already builds LabVIEW applications and needs to sharpen exam-specific habits. The ordering follows the rubric: lock in style and architecture first, because they affect every later build.
Design Concepts, Block Diagram Layout, SubVI Design
- Audit one of your own existing projects against cohesion, coupling and readability.
- Rebuild one messy subVI with a clean connector pane and icon.
User Interface Design and Programming Practices
- Design front panels with deliberate startup and stop states.
- Practice deciding where references and property nodes belong, and where they do not.
Architecture Selection, Timing, Error Handling
- Build one small application in each of the five named patterns.
- Add timeouts, wait functions and error propagation to every loop.
Documentation and Testing
- Document an existing project fully: front panel, block diagram and VI properties.
- Practice a final review pass using a written checklist.
Full timed builds
- Complete at least two full four-hour builds with original specifications.
- Score each against the 40-point rubric and fix recurring losses.
Reserve your weakest topic for a second pass rather than leaving it until the end; one repeated exposure beats a single long session.
Registration, Rules and Exam-Day Logistics
NI's current scheduling partner is Pearson VUE, and NI also offers an OnVUE online-testing route. Current NI delivery uses a secured virtual machine for performance-based exams. Older instructions in the 2012 preparation guide about USB drives, software versions and local proctors are historical, so confirm the assigned software image and candidate rules through the current booking instructions rather than relying on the guide's delivery section. For exact costs and fee mechanics, see our CLD certification cost breakdown, and for scheduling, our page on CLD exam dates and windows.
Practice with the rules you will face: only built-in LabVIEW Help, examples and templates, and nothing developed outside LabVIEW's own resources. Spend one practice session getting comfortable finding shipped examples and templates quickly, since fast navigation of those resources saves real minutes. Also test your setup well before your slot if you choose the online route.
How difficult candidates find all of this varies with experience, and we discuss that candidly in how hard the CLD exam is. NI does not publish a pass rate that we can cite, which is why our CLD pass rate analysis focuses on what can and cannot be known.
Validity, Recertification and Where the Credential Pays Off
Certification validity is three years. NI's recertification policy, updated April 30, 2026, allows renewal by examination and also offers Recertification by Points to developer-level and architect-level professionals. The CLD-R is a distinct recertification examination, so it should not be used to infer anything about the format of the initial CLD.
The credential tends to matter most in organizations that build test, measurement and automation software in LabVIEW, where hiring managers want evidence that a candidate can produce maintainable code and not just working code. Because the exam rewards style and documentation, the credential signals habits that teams value. To judge whether it fits your career, read our ROI analysis, browse what employers look for in CLD jobs, and review the CLD salary guide. For a quick refresher on terms, the CLD cheat sheet condenses the key facts.
Frequently Asked Questions
No. The initial Certified LabVIEW Developer exam is a four-hour practical in which you build a working LabVIEW application from a specification. Conceptual questions can help you review the ten exam topics, but they do not replace building.
NI's preparation guide gives a passing criterion of 28 out of 40 points, which is 70%. The rubric splits those points into Programming style (15), Functionality (15) and Documentation (10).
No. Built-in LabVIEW Help, examples and templates are permitted, but externally developed VIs and resources are prohibited. Practice using only the former.
NI lists no mandatory prerequisite on the current credential page. It recommends 12-18 months of LabVIEW development experience, and Core 1, Core 2 and Core 3 may substitute for three months of that.
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.