In 2021, the Computer Science and Engineering department at UC Riverside added a second pathway to the major with a new CS1 and CS2 course sequence. Our goal was to address disparities in course outcomes between different populations, particularly between those with and without prior coding experience and majors versus non-majors. The hope was that students new to computing would have a viable path to discover whether they had interest and aptitude in computing without the added stress of being in a classroom with students who have prior coding experience. In this paper, we report the data analysis that led to our decision to add a second pathway, design choices, and challenges (particularly in university politics) in launching and adding a second pathway. We present the results over the last three years, which illustrate that the new series has leveled the playing field. Most importantly, the course outcome data and changes to computing major enrollment illustrate that we achieved our goal of attracting students new to computing and thus are broadening participation in computing.

With the rapid surge of generative AI, many tools have been introduced, such as Google's Gemini and OpenAI's GPT-4, with the well-intentioned goal of supporting programmers [5,8]. These tools can be used by professional programmers to help write code efficiently as well as support debugging and testing; however, we recently began to notice an increase in the number of novice programmers who have become highly dependent on Large Language Models (LLMs) to code for them rather than using LLMs as a learning tool [2,10]. In our CS1 course, approximately 10-15% of the students (out of ~350) were cited for academic misconduct due to direct plagiarism from LLMs, many of which performed poorly due to an over-reliance on generative AI.

Motivating students to engage with a course, encouraging positive behavior, and inspiring them to take an active role in their educational process - particularly at the beginning of the course - are universal challenges in education. In this article, we share our experience implementing an early submission incentive policy in a Machine Organization and Assembly Language Programming course. This policy encourages students to complete and submit their weekly lab work early in exchange for bonus points. We examine the impact of this positive behavior reinforcement on overall student performance (final grade) and performance in specific components such as exams and programming assignments. Our results, based on data collected over four years and involving more than 1,400 students, indicate that students who participate in early submissions achieve a higher final grade and perform better on other assessments, such as programming assignments.

The ubiquitous use of online tools, contractors and homework sites, has made plagiarism a concerning topic in computer science education. With the introduction of ChatGPT, it poses a threat now more than ever. Many cheating detection tools, such as similarity checkers and style anomaly checkers, help instructors decide whether a student has plagiarized. However, these are not scalable to large classes. Similarity tools can produce high rates of suspected cheating and thus ineffectively use an instructor's time in weeding out the actual cheating cases, especially in the early weeks of CS courses where programs can be small and student solutions can be very similar. We developed a new approach using outlier detection to filter inconsistent performers based on their lab scores throughout the course and their midterm exam scores. Instructors can then manually analyze a manageable amount of students even with large class sizes. We performed our experiment on two large course offerings of CS1 (a total of 177 students) using our algorithm and compared it to a manual analysis performed by an experienced CS1 instructor. The detection approach identified 11 students in the first offering (Winter 2019) and 12 students in the second offering (Spring 2023). With an average precision of 83%, our tool produces a list of concerning students with high precision. This significantly helps teachers efficiently allocate their time and pursue cheating early in the term in order to address and prevent further issues.

Student cheating on at-home programming assignments is a well- known problem. A key contributor is externally-obtained solutions from websites, contractors, and recently generative AI. In our experience, such externally-obtained solutions often use coding styles that depart from a class' style, which we call "style anomalies," such as using untaught or advanced constructs like pointers or ternary operators, or having different indenting or brace usage from the class style. We developed a tool to auto-count style anomalies. For six labs across four terms in 2021-2022, and 50 sampled students per lab, we found 18% of submissions on average had unusually-high style anomaly counts. Importantly, 8% of submissions on average had a high style anomaly count but were not flagged by a similarity checker, meaning 8% of submissions are suspicious but might have been missed if using similarity checking alone. We repeated a similar analysis for Spring 2023 when generative AI (ChatGPT) was gaining popularity, and the numbers rose to 26% and 18%, respectively. Detailed investigations by instructors led to a majority (but not all) high style anomaly submissions being deemed cheating. Even for high-similarity submissions, counting style anomalies can help instructors focus investigations on the most-likely cheating cases, and can strengthen cases sent to student conduct offices. With the rise of externally-obtained solutions from websites, contractors, and generative AI, counting style anomalies may become an increasingly important complement to similarity checking; in fact, it is now the primary cheat-detection tool in our CS1 at a large state university, with similarity secondary.

We experimented with ChatGPT's ability to write programs in a CS1 class, and the ability of a popular tool to auto-detect ChatGPT-written programs. We found ChatGPT was proficient at generating correct programs from a mere copy-paste of the English programming assignment specifications. However, running ChatGPT for 10 programming assignments and acting as 20 different students, and using zyBook's APEX beta tool for academic integrity, we found: (1) ChatGPT-generated programs tend to use a programming style departing from the style taught in the textbook or by the instructor, and these "style anomalies" were automatically detected. (2) Although ChatGPT may for the same assignment generate a few different program solutions for different students, ChatGPT often generates highly-similar programs for different students, so if enough students in a class (e.g., 5 or more) use ChatGPT, their programs will likely be flagged by a similarity checker. (3) If students are required to do all programming in the autograder's IDE, then a student using ChatGPT ends up showing very little time relative to classmates, which is automatically flagged. (4) Manually, we observed that if a student consistently uses ChatGPT to submit programs, the programming style may vary across programs, something normal students don't do; automation of style inconsistency detection was recently added to APEX. In short, while there will no doubt be an arms race between AI-generated programs and automatic detection of AI-generated programs, currently students using ChatGPT for multiple CS1 programs can be detected by automated tools such as zyBooks' APEX.

College cheating is common, including in computer science (CS) classes like introductory programming (CS1). Much research surveys college students about cheating, but few survey students actually caught cheating, or analyze their performance. We analyzed performance of 24 students sanctioned for cheating on programs in our CS1 over three terms, out of 300+ students, mostly non-CS science and engineering majors. Sanctioned students participated less in lectures (scoring 77% vs. 91%, p = 0.00002), and were less earnest in their completion of the online book's readings (51% vs. 80%, p = 0.0000001) during weeks 1-5. Those findings suggest early disengagement which would correlate with a tendency to cheat, and might also suggest a lack of learning which might help cause cheating. Sanctioned students scored dramatically lower on the earlier midterm exam (61% vs. 83%, p = 0.0001). After being sanctioned with Fs in the course (typically post-midterm), most agreed to an optional later interview to help the professor learn how to prevent cheating, at which point most were quite forthright. Key themes included an inability or unwillingness to devote the time needed to learn programming, a belief that the required CS1 course was not important for non-CS majors, and a disbelief that cheating students would be caught or punished despite warnings. More studies of such experiences may help instructors reduce cheating; in our case, the findings suggest instructors should emphasize relevance, make detection/punishment efforts clear, and detect early disengagement and potentially intervene.

Student cheating on at-home programming assignments is a well-known problem. A key contributor is externally obtained solutions from websites, contractors, and recently generative AI. In our experience, such externally obtained solutions often use coding styles that depart from a class's style, which we call "style anomalies". Examples of style anomalies include using untaught or advanced constructs like pointers or ternary operators or having different indenting or brace usage from the class style. We developed a tool to automatically count style anomalies in student code submissions. We used this tool to find suspected cheating in student submissions for lab assignments across five terms of CS1. This poster presents our findings: Some student submissions were suspected of cheating due to high style anomaly counts and were not flagged as suspicious by a code similarity checker. With the rise of externally obtained solutions from websites, contractors, and generative AI, style anomalies may become an important complement to similarity checking for detecting cheating.

We describe our experience organizing and teaching a CS1 "common course" pilot across 7 institutions during the 2023 spring term. A common course is a comprehensive centrally-designed course taught nearly identically across multiple institutions. It goes beyond common inter-institution sharing of ideas and resources, and instead is essentially the same course taught by different instructors, akin to multiple coordinated sections of a course at one institution. We describe the experience of 7 instructors who voluntarily joined the pilot, which included instructors at 5 state universities and 2 community colleges. The common course's comprehensive design included a 15-week configured CS1 C++ online zyBook having weekly interactive readings, coding homeworks, programming assignments, and quizzes (all auto-graded); a midterm and final exam; a syllabus with schedule, grade weights, policies (late policies, cheating policies, etc.); support for teaching active lectures including detailed lecture notes and coding examples; and bi-weekly meetings among the 7 instructors plus an informal shared TA. Overall, the courses went smoothly for students, and the instructors all strongly indicated they benefited from the experience, and would do it again and recommend it to others. They listed key benefits to include time savings (which freed them to perform higher-value, more enjoyable tasks), state-of-the-art tools and pedagogy (like auto-grading and active lectures), the coding examples in the lecture notes, the ability to compare their students' performance to others, and the camaraderie and idea exchanges at the bi-weekly meetings.

Automated assistance for detecting cheating on programs has long been investigated by CS educators, especially with the rise of "homework help" websites over the past decade, and recently with AI tools like ChatGPT. The main detection approach has long been flagging similar submission pairs. Modern cheating, like hiring contractors or using ChatGPT, may not yield such similarity. And, cases based on similarity alone may be weak. Thus, over the past several years, building on logs from an online program auto-grader (zyBooks), we developed additional "cheating concern metrics": points rate, style anomalies, style inconsistencies, IP address anomalies, code replacements, and initial copying. Most are defined not only for one programming assignment but also across a set of assignments. The metrics can help catch more kinds of cheating, provide more compelling evidence of cheating, reduce false cheating accusations based on similarity alone, and help instructors focus their limited cheat-detection time on the most egregious cases. We describe the techniques, and our experiences (via our own Python scripts and a commercial tool) for several terms, showing benefits of having more metrics than just similarity. Of 30 cheating cases over 3 terms and 300 students, most were based on metrics beyond similarity, all students admitted, none later contested, and time per student was only 1-2 hours (far less than previously). Our goal is to prevent cheating in the first place, by reducing opportunity via strong detection tools, as part of a multi-faceted approach to having students truly learn and stay out of trouble.

Similarity checking is a common approach for detecting cheating in programming courses. A known limitation is high rates of similar pairs for programs lacking variability in possible solutions, especially for small programs. We experienced this issue in our CS1 course, where similarity checking in early weeks yielded many highly-similar pairs, many of which were not likely due to copying. Yet, we wish to catch copying students early, so that we can intervene and help those students avoid developing copying habits that may cause them trouble later. Our approach is to modify the program specifications to include variability-inducing requirements, namely places in the specifications where students make choices in their solutions, where different choices reduce the similarity scores. Those variability-inducing requirements are intentionally designed to avoid making the problem much harder for students. Examples of variability-inducing requirements include adding requirements to check for invalid input, or counting items. Such requirements have many different possible ways of implementing each. Essentially, variability-inducing requirements decrease the odds that two students would submit programs scored as highly-similar by a similarity checker, even for small programs. For 5 programs in our CS1 course, we added some variability-inducing requirements. Compared to an earlier term, the similarity checker's highly-similar-pairs rate dropped from 52% to 20% on average. Students' scores stayed the same from 98% to 96%, though time did increase from 18 min to 31 min on average. Adding such requirements helps instructors to do similarity detection and perform early interventions if desired.

CS educators have increasing interest in equitable grading, to support differing student backgrounds, perspectives, and current life situations. Our course is heavily scaffolded (one aspect of equitable grading), with points for readings, homeworks, and lab assignments, every week. All those items are auto graded with instant feedback, partial credit, and resubmissions. Previously, we did not accept late work, except for rare exceptions. In Spring 2022, following equitable-grading advice to reduce emphasis on deadlines, we allowed work to be submitted (and resubmitted) up to 14 days after target dates, with a small 1% deduction/day, with students receiving whatever max score occurred across those 14 days. This paper analyzes how students made use of this "late policy." The main finding was students did not shift all work by 1-2 weeks, as we originally feared; instead, students did most work by target dates. We found many of our 265 students only used the policy lightly (51%) or used it moderately (35%) to earn a few more points 1-2 days after target dates. Only 14% were heavy users of the policy, and they had reasonable course outcomes. Student feedback was positive, and instructors stated they saved time and energy due to reduced late requests.

Computer science instructors have long advised students that success in CS1 requires many hours, such as 8-10 hours/week outside class time, but students often don't believe it. Recently, the most-widely used CS1 learning system (zyBooks), which is web-native and records student activity data, began providing instructors with data on student time spent reading and answering reading questions, solving small homework problems, and coding the programming assignments, all online and auto-graded, representing nearly all a student's time outside class. In our 300+ student CS1 course at a large state university in Spring 2022, we required all work to be done in the zyBook and analyzed student time, including analysis relative to self-reported prior programming experience. Students who completed the class averaged 6.1 hours/week, with a large standard deviation of 2.3, and averaged a B+. Students averaged 6.9 hours in weeks 1-5 leading up to the midterm, peaking at 9 hours in Week 5. We found that over 90% of students who averaged 9-12 hours/week earned As or Bs, even those reporting no prior programming experience. Spending under 4 hours/week nearly guaranteed failing the midterm, and almost no students who spent fewer than 6 hours/week got an A on the midterm (unless they had prior experience). We also found that measuring actual time is important because students overreport time in surveys. With this concrete time data available to share with CS1 students, the hope is that future students may be more likely to allocate the time needed for success in CS1.

Coral was introduced several years ago to ease the learning in college-level introductory programming courses. Coral consists of a simple textual code language and corresponding flowchart language and a free web-based educational simulator. Previous researchers described the benefits of Coral in CS0 courses and the first weeks of CS1 courses. We previously used Coral in CS1 and enjoyed the teaching experience, due to: the simple intuitive syntax, the simulator's auto-creation of a flowchart from code, and the simulator's visualization of code and flowchart program execution. However, we wanted to ensure we weren't hurting students with the transition from Coral to C++. This paper describes our experiences of teaching Coral in a ~100-student CS1 section for weeks 1-3 versus two other sections that taught C++ only. We performed analyses to answer three research questions: (1) Do students learn Coral more easily than C++? (2) Do students easily transition from Coral to C++? and (3) Do Coral-treated students do equally well on later C++ programs? We analyzed performance on auto-graded code-writing problems in zyBooks. We did not find support for (1), but did find support for (2) and (3), with Coral-treated students easily switching to C++ and performing equally well on later C++ programs. We conclude that CS1 instructors who enjoy the early-weeks teaching benefits of Coral can do so confidently knowing that students will perform equally well later in the course.

Cheating in introductory programming classes (CS1) is a well-known problem. Various methods have been suggested to reduce cheating, but many are time-consuming, resource intensive, or don't scale to large classes. We introduced a class intervention having 6 low-effort commonly-suggested methods to reduce cheating: (1) Discussing academic integrity for 20-30 minutes, several weeks into the term, (2) Requiring an integrity quiz with explicit do's and don'ts, (3) Allowing students to retract program submissions, (4) Reminding students mid-term about integrity and consequences of getting caught, (5) Showing instructor tools in class (including a similarity checker, statistics on time spent, and access to a student's full coding history), (6) Normalizing help and pointing students to help resources. Via manual evaluation of similarity checker results on 7 held-constant labs with one instructor teaching 100-student sections, for two pre-intervention and two intervention sections, suspected-cheating reduced 62% (30.5% down to 11.5%). Because manual evaluation could be biased and is time consuming, we developed two automated coding-behavior metrics per lab -- time spent programming, and % of students with highly-similar code -- that may suggest how much cheating is happening. Time spent increased by 56% (7 min to 10.9 min), and % of students with highly-similar code dropped 48% (38.5% to 20%). We later repeated the intervention with a second instructor and different labs and achieved similar (in fact, even stronger) results, with time rising 84% (13 min to 24 minutes) and % dropping 66% (55.5% to 19%). All findings were statistically significant with p < 0.0001.