Underlying concern about advanced access to the tasks and base code is the question, "Are we measuring the ability to program or the ability to memorize?" The answer is simple: the ability to program.
First of all, we don’t supply solutions. In fact, there are many possible solutions for every task. There is no single ‘correct’ solution.
More importantly, there is simply too much to memorize. The Software Developer Examination can take up to six hours to complete. One comma, one semicolon, one parenthesis out of place and the memorization effort fails. Code stops compiling. Output is unpredictable. It is easier to learn how to program than to memorize solutions for any possible task, since tasks are selected at random for each individual’s examination. Proxor is also continuously reviewing, amending and adding to the inventory of tasks to ensure that there are no short-cuts to a good score.
Experience shows that those who do well on a Proxor exam are not simply successful at taking exams, they are successful programmers at the level of expertise for which the exam is designed.
The hallmark of a properly designed Authentic Examination™ is ‘No false positives’. If a jury of musical experts awards a superior rating to a pianist that performs a Rachmaninoff concerto in front of them, there is virtually no possibility that the performer is a poor pianist. If the Proxor grading software awards a superior rating to an examinee who took the SDE in a proctored setting, it is highly unlikely that he or she cannot develop software.
That would be unlikely as well. The Software Developer Examination employs a range of tasks and runs many tests on exam taker submissions. There are, in fact, as many as 180 distinct tests run on a single task solution! There is ample opportunity for competent, somewhat competent, and even a little bit competent programmers to demonstrate their skills. People who do poorly in Authentic Examination™ simply have not yet acquired the skills needed to develop software.
The best preparation for the Software Developer Examination (SDE) is a good set of courses in object-oriented design and programming followed by some serious practice of what was taught. The base code and tasks of the SDE are available on the Proxor website. They should be looked at but will generally provide only the finishing touches to serious work already undertaken in school and honed with practice.
The best way to tackle the exam itself is to look at the base code and tasks, understand the architecture of the program, understand how task solutions fit into that architecture, design solutions to the tasks, and implement the solutions and then test. This is good behavior for anyone developing software. In preparing for the SDE, participants are best served by putting into practice those development habits that are needed to be solid professionals.
The Software Developer Examination is designed for use as a global benchmark and therefore is calibrated according to a defined set of tasks. These tasks were developed in conjunction with the software industry, so should reflect the sorts of skills most employers are interested in. Whether the SDE is used to rank-order examinees or to compare aspiring new hires to professional developers, comparability between exam batches is a must. The only way to achieve comparability is to have large numbers of people taking materially the same exam under the same conditions.
Therefore, although Proxor is capable of customizing the SDE, that would be inconsistent with the objective of providing a standard measure of programming competence.
Employers may, however, ask to be included in Proxor’s regular review of entry-level programmer tasks (called a ‘role delineation review’), and may in that way influence the evolution of the examination over time.
The Software Developer Examination is designed as a proxy for the broad family of object oriented programming languages. If a person is competent in any of them (C++, Objective C, C#, Python, and many more) preparing for the SDE is not a daunting task. Once a programmer can develop software in one object oriented language picking up similar languages is easy. Good programmers can probably learn enough Java to do well on the exam with a few weeks of practice. Exposure of base code and tasks on Proxor’s website also ameliorates this issue to a great extent.
A programmer who can develop systems in Python, for example, but who cannot learn to write solutions to the tasks of the SDE in Java most likely can’t do much in Python either.
Yes. One of the objectives of the Software Developer Examination is to identify industry-ready software developers regardless of country of origin, educational institutions, degrees, gender and religion. Proxor scores and Proxor Ratings mean the exact same thing everywhere in the world.
Even those who earn a Proxor 3 rating have solved one or more tasks. This means that they have been successful in using data structures, the algorithms acting on those data structures, and a number of the other things that characterize professional developers. It is very possible that a Proxor 3 will mature into a competent professional developer.
A person who earns a rating of Proxor 4, while failing to draw on all the competencies of a professional developer and therefore failing to completely solve any of the assigned tasks, may be in the process of learning to do so.
If the Software Developer Examination were a measure of the aptitude that a person has for software development then employers might be well advised to steer clear of the Proxor 4 and maybe even the Proxor 3. However, the SDE reveals achievement not aptitude by measuring the degree to which an individual has achieved the ability to write software. The Proxor 1s and 2s have achieved quite a lot, Proxor 3s less so and Proxor 4s less than that. Even the exam taker who is Unrated by Proxor may turn out to be a fine software developer once the decision is made to pay attention to studies.
A score on the Software Developer Examination is our best estimate of how well that individual programs. That estimate may change somewhat as we gather more information in the period after the exam was taken.
Notice that there are many more tasks in the task inventory than a person is assigned. This is because we both want to expose the possible tasks to the examinees prior to the exam and we want to measure the ability to program not the ability to memorize solutions. Therefore the number of tasks must be large enough to go beyond the memorization threshold.
Different people are assigned different tasks. Suppose Person A got low scores and Person B got high scores. If all tasks were equally difficult those scores would be good estimators of the relative skill levels. However, all tasks are not equal: they have been designed to cover a full range of difficulty to improve the exam’s ability to discriminate among examinees. Thus it is possible that Person A was asked to solve the hardest tasks and Person B was assigned only easy ones, or the other way round. To create valid estimates of ability, we use a statistical technique known as matrix completion to estimate the relative task difficulties. As more people take the SDE we get more data and the task difficulty weightings will reflect this additional data. This leads to minor changes in historical scores.
Most exam takers will have a good sense of what their score is before they leave the exam room. Actual scores almost always confirm what the examinee already knows. However a person may believe that his or her solution to one or more tasks was incorrectly graded. In that case the exam taker should contact Proxor. Accurate scoring is critical to Proxor’s mission and we want to hear of any scores that were totally unexpected. We manually audit a sample of our automated scores and out-of-pattern results can help focus our audits. It is possible, although unlikely, that an examinee may have discovered a novel solution that our grading software did not contemplate.
However, our policy is to not release exact grading criteria or solutions, and it is impractical to hand-examine each question about grading.
Thinking of Proxor tests as examining specific programming languages misses the main point of this type of tool. Proxor exams evaluate a person’s ability to develop software within some industry paradigm. The Software Developer Examination addresses mainstream object oriented software development. Examples of different programming paradigms might be writing embedded software, the software that controls airplanes, ships and automobiles; or writing software that conforms to standards for safety and security; or developing web or mobile applications using a technology stack as opposed to a single language. Proxor is building a portfolio of Authentic Examination™ products to assess skills in these industry paradigms in concert with the global software industry and with the advice of the academy.
Not at present, but Proxor is currently working on a "C" exam; due out in early 2015. Work will begin on additional examinations soon.
The Software Developer Examination may be repeated as soon and as often as the exam taker wishes. Because the SDE measures achievement rather than aptitude, it will quickly reveal how far exam takers have progressed as a developer. If the Proxor Rating earned is lower than desired there are probably educational gaps to be addressed. In general, if a person has an aptitude for programming, skill levels can be improved by simple hard work, and this will be reflected in improving scores and ratings.
If your exam has been offered by a company, it is up to the company to decide whether or when to sponsor another examination for each individual.
You will be allotted six hours for the exam. A capable programmer should be able to complete the exam in about three hours but you will have the full six hours available should you need it. Restroom breaks will be allowed during the exam.
What refreshments you are allowed to have in the exam room will be at the discretion of the testing facility. You are required to present some form of photo identification prior to taking the exam. You will not be allowed to bring any papers, USB drives or other materials into the exam room. Cell phones are not permitted in the exam room.
You will be required to provide photo identification prior to taking the exam. You will need to present an official photo ID. This might include, but not limited to, a valid Passport, National ID Card, Driver’s License, or University ID.
Everyone needs to know that we encourage collaboration between exam takers in preparing for the exam. We released the exam base code and tasks precisely because we want no one to be surprised on exam day. Preparation is key.
For assistance with technical issues related to your preparations for the exam, you can simply click the “Contact Us” button at the bottom of web page.
Your individual examination results will be avaliable on the website withn 48 hours of your examination.
Because this is an authentic examination it was necessary to select a specific language and platform. We selected Java based on extensive interviews with developers and software development managers. Java was far and away the most commonly used language. Furthermore, although we use Java, we use it to test general programming, not specific features of Java. We chose Linux because of licensing issues and there is nothing on the exam that is Linux specific. In the future, we expect that certification examinations will be developed for other languages and platforms.