Certification
Sample Exam Solutions for Review
We hear. And -- what are your opinions about replacing the 1-hour exam with Recertification by points?
How about rolling the 4-hr and multiple-choice tests into the points program by assigning each a number of points? Maybe the MC could be whittled down to mostly what's new, being weighted towards the newer versions, therefore being smaller and worth x amount f points?
From a purely added value point of view, I think that would work, but one of the goals was to cut down on overhead, and this would definitely be ADDING overhead.
Rolling out the points method would be a prickly subject. How would you handle the person whose certification came up just as the transition occured? Maybe that person has no points. I guess the fairest way is for everyone with pending re-certs at the time of the change gets re-certified the old way, but the next one is the new way? Or maybe those with less than a year to re-certification get a one-year grace period to give them at least a reasonable shot at accumulating points? It's not just a change in the type of test, like the last time the criteria was changed, it's a completely new direction. I think a lot of developers could lose their cert for no good reason otherwise.
You asked for my opinion- OK you'll get it.
I would strongly encourage NI to maintain a CLD-R multiple choice exam but, yes, the current ones need work! There are poorly worded questions. There are ambiguous distractors. There are incorrect answers. There are questions with obsolete answers (The IPE structure may actually slow down code execution if the "magic pattern" exists on a LabVIEW version with compiler optimizations and the optimization threshold does not limit that optimization.) With proper test maintenance all of these should have been avoided.
OH NO! did I say "Test Maintenance?" Yes! You really need to do test maintenance! Sort through the most commonly correctly answered items and consider why they fail to uncover defects in the understanding of the skill under review AND find the most commonly incorrectly answered items review the distractors chosen incorrectly and identify where the failure in testing occured. Poor training/help, bad question, and "concept out of scope" are common reasons for these outliers. To my knowledge this data-mining has not been done and, if it has, the release cycle is unresponsive to that analisys.
Why do I feel the written exam offers value:
- Its cheap! A single hour plus nearby travel (to Pearson Vue where available) carved out of 1 persons schedule vice the four hours for the examinee + proctor + grader resources + Test Enviornment logistics is costly to everyone
- It requires demonstration of "Why" not just practical implementation of How. "Well, I used a Statemachine because the person I learned from said 'Always use a Statemachine'" does not demonstrate an understanding of programming principles. The practical exam cannot test that understanding, the points system has some elements that could but, none that are required.
- Peer interaction (UGM's, Dev Days, NI Days, NI Week) is often problematic for logistical reasons. Points may be hard to come by for some! Again the written exam fills the need for recertification in those cases.
If I am not mistaken, those first two points were the original justification for the CLD-R being a written exam. I think they are both still valid.
All that being said, NI needs to do a better job at test maintenance and leverage the tools and techniques for all exams (Certification, instructor led training and on-line training.)
Just 1 opinion
I don't think any of us can say for certain if a solution is good enough to pass. But looking at your code I'd guess it is good enough to pass. Your code looks pretty clean, functionally I think it is complete (but I didn't try to exercise all features), level of comments is good, icons are good. Maybe the control names could be improved a bit. What is "I_Mode Settings" or "O_Max Time"? I realize you could have control descriptions or VI documentation explaining it, but the control names could be more human readable and easier to understand. Maybe just remove the "I_" and "O_" if it doesn't add anything. That being said I'm not sure you'll get points taken away for this.
Actually I'd suggest removing any prefix from the control or indicator name all together. You know it's an input because you can sink data to it, and the context help shows you. You know its an output because you source data from it, and the context help shows you. These practices might be common in text based languages, and apparently TestStand, but I've never seen LabVIEW VIs set with prefixes defining if they are inputs or outputs, just my 2 cents.
Jeff·Þ·Bohrer wrote:Yeah, in LabVIEW we postpend that info
Those are good examples and I have done some of those, but in those cases I have an In and and Out that are usually modified some how. Like I have a "Cool Class In" and "Cool Class Out", but if I just had "Settings" I wouldn't label it "Settings In" unless there were a "Settings Out" that were somehow manipulated in my VI. Not sure if this is how it is always done but it is better than the alternative of having two controls with the same name "Cool Class".
