Using Coding Interviews as an Organizational and Evaluative Framework for a Graduate Course in Programming

Objective: In a Statistical Analysis System (SAS) coding interview, job applicants are typically presented with data management and data analysis problems and asked to solve them using the programming language of SAS. Interviewers not only assess technical competence, but also algorithm design and more generally how applicants approach computer programming. In the language of constructivism, the problems are designed to assess the depth and soundness of the applicant’s mental model of SAS programming. We asked whether a SAS course, embedded within a Master of Biostatistics program, could reasonably be structured using a coding interview for the final examination as its organizing framework. Methods: This is a case study, where we describe how our content delivery was structured in order to prepare students for their coding interviews. It additionally relies on the metaphor of learning a second language through immersion. Results: Using a constructivist approach enhanced with active learning exercises, a course could in fact be designed around a coding interview. Course content can be mapped to the metaphor of foreign language immersion. Student response has been positive, and the formative evaluation has been encouraging to date. Conclusions: Coding interviews are a novel and potentially promising way to design a course in SAS programming.


Introduction
At the broadest level, the fundamental question underpinning our program of research is how to most effectively prepare students to practice the discipline of collaborative biostatistics. In the spirit of a cognitive apprenticeship model derived from constructivism, (Bandura, 1997;Johnson, 1992) we began the initial development of a masters' program in biostatistics with a vision-setting exercise whereby we interviewed successful biostatisticians and their collaborators around the question of what constitutes an effective collaborative biostatistician. The answers were consistent across both groups and, indeed, with the modest literature on the topic, and were termed the "ABCs of biostatistics": • Analytical skills include mastery of statistical analysis methods and statistical programming, and also more general skills in problem definition and problem solving.
• Biology skills include a combination of substance matter expertise around biology and medicine with curiosity and learning skills to sufficiently master the substance of the content being studied.
• Communication skills fundamental to team science include taking in information from outside the discipline and effectively sharing statistical information with others.
In attempting to help students learn the ABCs of biostatistics, our program is organized around a required curriculum in year 1 supplemented by electives in year 2 (and also significant experiential learning opportunities in year 2 through internships and a masters' project). The year 1 curriculum is divided into four academic sequences (plus a professional development sequence): (1) theory; (2) data analysis; (3) biology and statistical practice; and (4) programming. Here, we focus on the second-semester course within the programming track pertaining to the The SAS course is preceded by a first-semester course in R, whereby students develop general programming skills which can translate into multiple programming languages, including SAS. At the risk of oversimplification, within biostatistics R is currently the academic standard and SAS is the industry standard. Students who plan to enter industry will eventually need to develop a higher level of proficiency in SAS, and one of the goals of the SAS course is to provide those students with a sufficiently detailed knowledge of the structure of SAS to facilitate their future learning.
The SAS course was included in a recent curriculum review. Student feedback was positive, and a faculty member found the goals and content to be appropriate and the order of its delivery sound. On the other hand, though, we concluded that the course's evaluation methods left something to be desired. We were evaluating students using in-class tests, where we asked them to either write or interpret SAS programs. When the tests were closed-book and closed-technology we worried that we weren't evaluating students in the context that they would actually be using SAS. On the other hand, when the tests were open-book and open-technology we worried that what we were actually evaluating was facility in online searching, not even to mention potential issues around cheating.
Our response was to change the final examination to a simulated "coding interview" -that is, the type of interview often provided to software engineers, statistical programmers, and biostatisticians whose job responsibilities involve a significant amount of programming. In an actual such interview, applicants are typically presented with data management and data analysis problems and asked how they would solve them using SAS. Interviewers not only assess technical competence, but also algorithm design and more generally how applicants approach programming. In the language of constructivism, the problems are designed to assess the depth and soundness of the applicant's mental model of SAS programming. In the language of pragmatism, if nothing else the final examination provides students with practice in an important job-related skill.
We believe coding interviews to be a novel approach for organizing a biostatistics course, and for evaluating student performance. Here, we describe how our content delivery was structured in order to prepare students for their coding interviews. In the process, we utilized a metaphor which, although not strictly necessary, proved quite helpful. The metaphor was teaching a foreign language through immersion. Recognizing that a barrier to coding interviews could be a concern about their potential subjectivity, we also describe how student performance on those interviews was evaluated.

Methods
The didactic presentation begins with a description of our conceptual model (i.e., the metaphor of language immersion). Then, the structure of the class is described. Then, as a case study two illustrative modules (i.e., printing, simulation) are presented. Then, we present the results of an initial and formative evaluation of the redesigned SAS course, subdivided according to the coding interview and other elements of the class. Finally, we discuss our tentative conclusions to date.
Our criteria for success considered, among others, the following: • Can individual classes be designed using the metaphor of language immersion?
• Do students demonstrate good SAS programming skills?
• Can coding interviews be successfully administered as a final examination?
• Do students and instructors evaluate coding interviews positively?
In brief, the answer to all these questions turned out to be "yes".

Conceptual Model for Teaching SAS as a Second Language
Our conceptual model / analytic framework identifies some of the elements of successful instruction in a second language, and then translates them into the context of becoming proficient in SAS. Among these elements are the following: • Beginning from a simple base, gradually expand the complexity of what is spoken • Deliver information about language structure in a just-in-time fashion

• Place examples in context
• Use an online dictionary and similar resources This conceptual model is fundamentally a metaphor which is consistent with the minimalist approach to developing software manuals and similar training materials. (Ben-Ami, 2001) In this context, the fundamental goal is to help the learner develop a sound mental model of how the programming language is organized, and the approach combines immediate immersion to accomplish simple tasks with ongoing explication of the structure of the language. As per constructivism, language structure is initially described in terms which are very simple (albeit sound), with additional detail gradually added over time. At each step, the previous mental model of language structure is used as a building block.
3.1.1 Application to Spanish 3.1.1.1 Practice Speaking the Language, Beginning with the First Lesson For example, a first lesson in Spanish might begin with the Spanish equivalents of good morning, good evening and good night: Buenos dí as, Buenas tardes, Buenas noches, respectively. The example is chosen to have a consistent sentence structure, and helps to develop vocabulary (e.g., Buenos/Buenas is repeated, and becomes one of the first vocabulary words).

Use Repetition
As noted above, repetition aids in developing vocabulary and internalizing grammar.

Beginning from a Simple Base, Gradually Expand the Complexity of What is Spoken
For example, an element of a first lesson in Spanish could extend Buenas noches (good night) to Buenas noches mi amor (good night my love).

Deliver Information about Language Structure in a Just-in-Time Fashion
Without discussing Spanish grammar in detail, the above example illustrates one way that a Spanish sentence can be structured. It also naturally leads to a just-in-time discussion about the distinction between buenos and buenas, which illustrates the rule that gender is attached to nouns. This would encourage students to replace the simple conceptualization of "nouns" with "gender-specific nouns", a first step in developing increasingly sophisticated mental models about the structure of Spanish.

Place Examples in Context
An early Spanish lesson might focus on an important task, such as introducing one's family. For example, Esta es mi familia, Esta es mi madre, and Esta es mi padre, are this is my family, mother and father, respectively. As above, repetition aids in developing vocabulary and internalizing grammar.
3.1.1.6 Use an Online Dictionary and Similar Resources Nowadays, learning a foreign language is made significantly simpler by online resources such as dictionaries. For example, not only can individual vocabulary words be searched, but it is straightforward to ask questions such as "how do I say this is my family in Spanish?" The answers to such questions comprise, either directly or indirectly, a significant component of a mental model of the Spanish language.

Class Sessions
Class sessions are divided between demonstration and practice. Class sessions include: • Interactive demonstrations of SAS code • Whiteboarding exercises (e.g., to diagram SAS code, to describe and critique the algorithms underpinning the SAS code).
Demonstrations were substantially based on a previous iteration of the class, and the slide decks from that iteration were included as supplemental resources. Here, the whiteboarding exercises are also intended to illustrate one component of the coding interview. The programming assignments are group-based, and class time is reserved to begin these assignments with the instructor's assistance. Completing these assignments earns a grade of B for the course, which can be increased to a maximum of an A+ based on the coding interview.

Coding Interview
Students are provided with a grading rubric, an opportunity to practice the coding interview ahead of time, and whiteboarding and similar in-class experiences which also serve to demonstrate and then help students practice designing and explaining SAS programs. The grading rubric was derived from rubrics used for interviews of software designers, (e.g., Haoyi, 2017) and includes questions such as: • Was the algorithm clearly described?
• Was the algorithm sound?
• Was a development and testing strategy described?
• Was the SAS code documented using comments?
• Was the SAS program user-friendly?
• Was the SAS syntax (for the critical portions of the program) accurate?
• Was the structure of the SAS language (e.g., similarities and differences compared to R) clearly described?

Description
Here, we illustrate two modules: (1) printing (Appendix 1); and (2) simulation (Appendix 2). Class materials include illustrative SAS code, SAS output, and a narrative summary. Much of the description of the SAS code is contained in the comment boxes (which begin with an asterisk and proceed until a semicolon is encountered). The illustrative code includes references to various in-class exercises.

Practice Speaking the Language, Beginning with the First Lesson
Printing is the first module in the course. Rather than beginning the course more traditionally -for example, with an introduction to SAS syntax -we start with the simple task of printing an existing dataset. (The dataset must first be created, but the mechanics around dataset creation are deemphasized.) Accomplishing a simple task such as printing is the functional equivalent of speaking the language, and thus the first module begins with "speaking SAS".

Use Repetition
PROC PRINT is repeated in all 11 of the demonstrations in this module, as is the TITLE statement.

Beginning from a Simple Base, Gradually Expand the Complexity of What is Spoken
From the most basic PROC PRINT, more complex elements are gradually added -for example, selecting variables to print and selecting observations to print.

Deliver Information about Language Structure in a Just-in-Time Fashion
Various elements of the structure of SAS are illustrated within the printing module. For example, a fundamental element is that SAS datasets are either being created or acted upon. Printing is one such action. An element of SAS grammar is that all statements end with a semicolon. Another element of structure is that the user can limit the variables (i.e., columns of the data array) to be acted upon, either through a SAS statement or when referring to a SAS dataset within a SAS procedure.

Place Examples in Context
Even though printing is an extraordinarily simple task, it is used to introduce more general programming concepts such as reproducible programming and modular coding, both of which are topics that interviewers might address during a coding interview. Reproducible programming is introduced through the notion of referring to the source program within the printed output. Modular programming (and also an additional element of the SAS language) is introduced through translating a PRINT statement into a macro. An additional general concept is that of reader-friendly code, which is accomplished through liberal use of commenting, white space, indenting, etc.

Use an Online Dictionary and Similar Resources
Although the students will have encountered the functional equivalent of a macro in their previous R course, this component of the lesson is notably more sophisticated than others. For macros, the instructor explicitly models the process of learning by first performing a web search on "What does a SAS macro do?", and then using SAS's help function which, quite fortunately, not only includes a structured description of macro syntax but example macros as well. Indeed, once the student has an adequate understanding of the structure of SAS and what a macro does, it is usually sufficient for them to find an example and then modify it to meet their needs. In other words, the student is encouraged to dive in and "speak macro". The most fundamental idea behind a typical simulation is to create a DO LOOP, where each execution of the loop uses a random number generator to create a simulated data value. The module begins with practice creating such a loop (i.e., "speaking" DO LOOP).

Use Repetition
The fundamental DO LOOP is repeated for each simulation.

Beginning from a Simple Base, Gradually Expand the Complexity of What is Spoken
This module illustrates one of the ways that code can be developed in an iterative fashion which, indeed, is one of the qualities that interviewers are seeking in a typical coding interview. For example, the basic logic of the random number generation is developed and tested on a single iteration of the simulation, and only then expanded to add an outer DO LOOP which repeats that logic on multiple iterations.

Deliver Information about Language Structure in a Just-in-Time Fashion
This module illustrates explicit attention to "algorithm structure" -that is, it is organized around the three basic ways to perform a simulation typically encountered within biostatistics. To assist in highlighting the steps, intermediate files are printed (which, indeed, is an excellent programming technique in general). In class, printing intermediate steps is supplemented with a whiteboarding exercise, where the logic of the simulation is first mocked up as a flow chart or pseudocode, and then the actual SAS code is diagrammed.

Place Examples in Context
For this module, the context is a task which is critical to the practice of biostatistics: namely, simulation. Indeed, the information pertaining to SAS is supplemented with content about various statistical principles pertinent to designing sound simulations.

Use an Online Dictionary and Similar Resources
For this module, students are encouraged to explore web material such as guides to designing simulations, and also SAS's help to obtain information about the different types of random variables that SAS is able to directly simulate. (Essentially any random variable can be indirectly simulated by first defining its cumulative distribution function, and then randomly selecting a value from that function through a uniform random variable in the interval from 0 to 1.).

Course Evaluation
Best laid plans being what they are, in mid-semester the covid-19 crisis arrived, and in less than a fortnight our course delivery was unexpectedly transformed from in-person to synchronous online. The grading scale was changed to satisfactory / unsatisfactory, and since everyone was up to date with their homework (and thus due at least a B) the final exam became unnecessary for the purpose of assigning grades, although students retained the option to receive letter grades, and those students who preferred to do so participated in simulated coding interviews remotely. In addition, some students who received a satisfactory grade opted to undergo a coding interview for practice, which we interpreted as a vote of confidence regarding its value.
Students also participated in an "exit interview" where they were queried about their level of confidence in their SAS programming skills, discussed self-identified gaps in their SAS knowledge with suggestions for self-study, and also discussed their experiences with the course in general. These interviews provided a significant amount of qualitative information, which, because of the unexpected transition to online instruction, we considered to be part of a formative rather than a summative evaluation.
For the element of the course pertaining to the coding interviews, the main insights from this formative evaluation included: • The notion of designing a programming course around a coding interview was well received, especially given the importance which many students attach to demonstrable job skills, including interviewing skills.
• Those students who participated in the coding interview found it to be a fair assessment of their programming skills.
• Those students who participated in the coding interview found that the instructor's real-time comments on interview technique (e.g., "when the interviewer asked this question they were attempting to assess x, and so a more effective way to frame your response might have been y) was helpful, and increased confidence in their ability to successfully navigate an actual interview.
• Particularly effective programming interviews should be recorded and used as study guides going forward.
For the other elements of the course, the main insights from this formative evaluation included: • Active practice is critical for mastering programming -even if the techniques in question are straightforward simply seeing them isn't enough.
• An ideal assignment first allows students to practice programming techniques covered during the class as a check on understanding, then requires a modest extension of those techniques, and also embeds some type of practice in explaining the algorithms in question.
• The collaborative component of the homework exercises is enjoyable and helpful -if the course is delivered online, techniques such as instructor-moderated chat rooms should be used to better approximate the experience of working together in real time.
• A substantial project, whereby students perform data management and then data analysis on a dataset which is larger than those used for "toy" examples, would help to assess SAS programming skills within a realistic context.
• A diversity of background materials is beneficial. Some students found the PowerPoint slides from the previous iteration of the class to be useful, and suggested that this be used as a supplemental mode of instruction during class time. Others found the narrative summaries to be helpful. Finding model code (whether from SAS's documentation or the internet) and then modifying it is common practice, and exercises which allow students to systematically practice this skill should be considered.

Discussion
We have described a SAS programming class with a novel approach to evaluating the performance of its students: namely, a coding interview. The formative evaluation of this approach has been encouraging to date.
When discussing this approach with colleagues, three quite reasonable questions have been raised about using an interview for a final examination: (1) is it fair; (2) will students object; and (3) is it too time consuming for the instructor? In our experience using interviews (albeit not coding interviews) in other courses, the first two questions are related, as in: will students believe that an interview is subjective, potentially unfair, and thus object?
Our previous experience with interviews has shown that, although a minority of students find the experience to be frightening to contemplate ahead of time, no one has ever objected to their final grade. Most likely this is because, with the opportunity to ask follow-up questions and otherwise probe, the limits of a student's understanding are apparent not only to the instructor, but to the student as well.
We also attempt to be as transparent as possible about the coding interview. For example, we circulate a grading rubric, sample questions, and differentiate between which elements of SAS are core knowledge, and thus should be recalled during an interview, and which are not. Using the simulation module for example, the notion of a DO LOOP with an OUTPUT statement to write the value of the simulated random variable can be considered to be core knowledge, whereas the name of the RANNOR function (which generates values of a normal random variable) and its syntax is not. Thus, a perfectly acceptable response within a coding interview would be to use actual SAS code to set up the DO LOOP, and pseudocode to call the function (e.g., as in "apply SAS's function which generates normal random variables -I don't recall its syntax but can look it up if you like -and write the results to a variable named Y"). After all, on the job the students can always run a web search such as "SAS functions, normal random variable". logistics aren't so bad. The practice interviews don't have to wait until reading week, and instead can often be scheduled any time during the last quarter of the semester. The students who ace the practice interviews (who tend to be the ones who sign up early) can use those interviews in lieu of the final, and so the volume of interviews during the final examination period probably won't be all that burdensome. Not even to mention that time passes quickly as the students are lots of fun to talk with." One point of emphasis within our overall curriculum is training students to "think like biostatisticians" which, in the constructivist/ cognitive apprenticeship paradigm, is functionally equivalent to "develop a mental model of the discipline that is sound, and roughly approximates the mental models used by experienced biostatisticians". Achieving this goal in general is not a trivial matter, nor is determining how this construct can be best evaluated.
We would argue that a programming course is an especially felicitous use case for a constructivist approach, as it "involves the production of an artifact that can be shown and shared" (Monga et al, 2018). A SAS program either works as intended or it doesn't, and thus provides immediate feedback to the student about the soundness of their thinking. Moreover, the underlying logic of a SAS program that a student has written can be translated into an algorithm which can be depicted on a whiteboard, and that translation is only one step removed from the student's mental model of the SAS language. Indeed, it is a direct application of that mental model, and is sufficiently concrete as to provide actionable information about the depth and soundness of that mental model.
The didactic elements of the course are intended to be a methodical "show and tell" illustrating how to design and code SAS programs. In creating those elements, we found the metaphor of language immersion to be both novel and helpful, although not necessarily crucial, and in the final analysis this metaphor is only helpful to the extent that it assists in creating sound course materials. We found it beneficial to build short exercises into the didactic presentation, as these encourage active engagement, and also help students to assess when their understanding of a construct is as desired. The collaborative homework assignments are intended as another application of the principles of active learning.
As previously noted, this course unexpectedly received a stress test, in the form of being ported to synchronous online instruction on very short notice. Assessing the results of this stress test, the didactic elements translated quite well. Indeed, the only major change was that more extensive narrative summaries were created and circulated ahead of time, and directly linked to the SAS program via numbered "demonstrations". Even if the course format returns to an in-person one, we will retain detailed narrative summaries. The hands-on exercises didn't port as well, as it was difficult to recreate the experience of small groups of students working on a SAS program assigned as homework with the instructor circulating to offer guidance. In retrospect, this is a problem that can mostly be addressed using available technology, and our struggles are attributable to a learning curve in the presence of multiple distractions. The coding interview translated fairly well, the main challenge being the lack of a functional equivalent of a whiteboard. This is also a problem which can be addressed using available technology, and ensuring that all our students have the ability to write on their computer screens and share the results with others would be a top priority if the SAS course is moved online in the future.
In summary, we find this approach to software instruction to be novel and encouraging, and look forward to making improvements and then performing a more formal evaluation in the future.

Conclusion
It can be asked what have we learned, and why does it matter? Briefly, what we learned is that designing a SAS course around a coding interview "works", at least for this particular audience. However, given the proliferation of materials for learning SAS (e.g., online courses, in-person short courses, certification materials designed by SAS personnel), it can certainly be asked why this course might be "better" than other options, or whether an additional approach to teaching SAS, even if novel, is needed at all. Indeed, in the extreme one might even ask whether separate courses in programming are necessary within a biostatistics curriculum -perhaps the time might be better spent teaching statistical techniques with programming encountered as needed?
We would argue that our approach is only "better" to the extent that it is intentionally targeted toward its specific audience. Our students aren't training to become professional programmers, nor will they use all of SAS's functionality. Instead, they are training to become biostatisticians operating within an environment of team science. This requires "tourist-level" familiarity with SAS to allow them to perform standard data management and data analysis tasks in a clear, reproducible, and human-friendly fashion (e.g., since others will encounter their SAS code). They also need to be able to accomplish various tasks which are high on the level of statistical sophistication and moderate on the level of programming sophistication -for example, performing non-standard sample size calculations, comparing the statistical implications of various study designs, comparing various statistical techniques, etc.
One element of this targeting is to deliver content in a fashion which treats our students as biostatisticians rather than professional SAS programmers. Another element is to focus on different topics that a typical SAS course outside biostatistics covers, the simulation module providing an example. Thus, we can promise our students that "these are the elements of SAS which you are most likely to use in practice, and this is the context within which you are likely to use them". Actual interviewers are trying to assess much the same construct -namely, whether student's mental model of SAS is sound and sufficient for the task at hand. "What the student needs to be able to do" equates to "what the interviewer will ask", and this allows the instructor to get the emphasis right and similarly helps motivate students to learn. Interestingly, the interviewer becomes a personification of the teaching goals.
To appreciate why this "matters", it can be helpful to consider the value proposition for biostatisticians. Similar to so many knowledge-based professions, the value proposition for biostatisticians is that they "think like biostatisticians". Factual knowledge, such as how to perform a particular mathematical derivation, is now ubiquitous (or at least potentially so) through the internet, and biostatisticians only add value via their ability to more insightfully process information which is also known to others. Given this value proposition, it seemed only natural to design our curriculum to address the construct of a sound mental model of biostatistics as directly as possible, and also to apply this philosophy to redesigning the SAS course.
When performing due diligence around the question of "how do I teach someone to think like a biostatistician", a constructivist notion which is also consistent with the above value proposition, we discovered that the literature on this question was sparse to the point of being non-existent. Certainly, the literature on constructivism is voluminous, and includes insights about how to teach statistics and how to teach computer programming (although not necessarily for our particular audience). (e.g., Ben-Ami, 2001;Wulf, 2005) Within the statistical literature, there is a modestly sized literature on how to assist students to develop skills in consultation and team science -although this isn't quite "how to think like a biostatistician" it touches on closely related constructs and is quite helpful (e.g., Samsa, 2018 provides a reference list). There is a massive literature on how to teach computer programming, although not necessarily for our specific audience. (Monga et al, 2018) provides a helpful reference list oriented toward introductory programming classes, although it must be acknowledged that our pedagogic task is somewhat different in that we are trying to simultaneously trying to teach statistics and programming.
Thus, we would argue that the fundamental question underpinning our program of research about how to most effectively prepare students to practice the discipline of collaborative biostatistics is both important and understudied. We would also argue that operationalizing this question as how to most effectively prepare students to think like biostatisticians represents progress. We would further argue that a course in SAS programming offers an excellent test case, because the student's mental model (or, more accurately, something only one step removed from that mental model) is directly observable (e.g., as an algorithm, as a SAS program). The general pedagogic insight which we would offer to others is that, where possible, a coding interview or its functional equivalent can be effective for purposes of both curriculum design and student evaluation, and should be considered. Certainly, such interviews are consistent with the notion that it is more important to test the ability for students to use information than to recall facts. We would argue that this illustrates the general principle that it is beneficial to synchronize curriculum design and student evaluation as much as is realistically feasible. Finally, we would offer encouragement to other instructors that coding interviews and their functional equivalents are realistic and, indeed, can be enjoyable.

Printout of temp1
This was generated by the program "module 1 printing", located in directory <named> Demonstration 1 illustrates two fundamental elements of a simulation. The first is the use of a SAS function to create a random variable (here, with a normal distribution). The second is the use of a DO LOOP and an OUTPUT statement to write the desired number of copies of the random variable to a new dataset.
Demonstration 2 illustrates using PROC MEANS to not only calculate a maximum value, but to capture it for subsequent use through an OUTPUT statement. Of course, forgetting the output statement causes the DO LOOP to run but not write the records as desired (except the last one).
Demonstration 3 illustrates the most direct way to perform the simulation. An outer DO LOOP has been added, which allows the programmer to program the number of iterations of the simulation. The PROC PRINT only prints enough records to verify that the DO LOOPs are working as desired. A BY statement has been added to the PROC MEANS, in order to calculate a maximum value for each iteration. Remember to check the SAS log to verify that the datasets have the intended number of records. The NOPRINT option on PROC MEANS suppresses the printing, which is helpful if the number of iterations is large and thus that element of the printed output extensive. An advantage of this approach is that it is straightforward. A disadvantage of this approach is that the number of records can proliferate.
Demonstration 4 illustrates the most direct implementation of another approach, one with one record per iteration. Each simulated variable is given a different name, which is facilitated using an ARRAY statement. An advantage of this approach is that a SAS function (here, MAX) can be efficiently used to make the calculations within each iteration. A disadvantage of this approach is that the number of variables can proliferate.
Demonstration 5 illustrates an approach that works for large number of iterations and large number of variables. Calculations are made on the fly, and the method is only appropriate when the quantity to be estimated can be calculated from the current record and a summary of previous records (for example, the current record and the maximum of the previous records). This code also illustrates a more general programming technique, whereby bins are created, initialized to zero, and incremented whenever a condition holds true (i.e., "counting bins") Demonstration 6 illustrates how to create a user-defined function. These can be helpful for modularizing code.