Introduction
First-year engineering (FYE) courses are foundational in preparing students for the analytical, computational, and problem-solving demands of their disciplines. Among their core outcomes is developing students’ ability to use computer programming as a tool to solve engineering problems. While achieving syntactical proficiency is important to meeting this objective, an equally critical goal of introductory programming instruction is fostering algorithmic thinking (Rodríguez Del Rey et al., 2021). Algorithmic thinking (AT), one component of a larger computational thinking (CT) framework, involves applying logical reasoning and designing structured solutions in an abstract way (Lafuente Martínez et al., 2022; Román-González et al., 2019). Recognizing the transferability of AT across engineering disciplines, instructors in FYE courses increasingly aim to cultivate AT as a key part of programming proficiency.
One potential way to teach AT is to separate the programming planning phases from the syntax development with intermediate deliverables such as pseudocode or flowcharts. Pseudocode is a natural language representation of steps needed in a program to complete a programming task, and flowcharts are visual representations of those steps. Having students generate pseudocode or a flowchart could help them focus on the problem-solving phase, removing the complexity of new syntax language concepts. From a cognitive load theory perspective (Sweller, 1988, 2016), the plan-first approach to programming may reduce extraneous cognitive load during the planning phase, which could make it easier for students to successfully learn programming problem-solving skills. In addition, pseudocode and flowcharts are directly aligned with AT, giving students practice identifying the steps to solve a programming problem.
However, research on the effectiveness of flowcharts and pseudocode instruction in FYE is limited, especially with respect to CT or AT learning outcomes. In an earlier literature review, Lyon and Magana (2020) found only 13 empirical studies of educational interventions to develop CT in higher education. At the time, there were widely diverse conceptualizations of CT, interventions, and assessments, and authors called for more research into how CT can be developed in the classroom and what pedagogies are appropriate for the undergraduate level. A similar literature review from 2025 also revealed a broad sparsity of papers investigating pedagogies within the higher education context for algorithm design, a concept highly related to AT (Liu et al., 2025). While a great amount of progress has been made, such as the development of scales to measure AT and CT in engineering and computing education (e.g., Algorithmic Thinking Test for Adults by Lafuente Martínez et al., 2022, and the Engineering Computational Thinking Diagnostic by Mendoza Diaz et al., 2023), much more empirical work is needed to evaluate the impact of various pedagogies.
The current study began to address this research gap by comparing students’ AT skills following (1) instruction on flowcharts and pseudocode or (2) standard, syntax-oriented instruction within a programming unit in a first-year engineering course. The goals of this study were to evaluate whether the flowchart/pseudocode instructional intervention led to improved students’ AT performance, and to explore whether students’ AT performance correlated with other variables such as programming experience and course performance. Results and insights will inform future programming instruction, considering to some extent the growing availability of generative AI (GenAI) tools that can automate coding tasks.
Literature Review
Computational Thinking and Algorithmic Thinking
Computational thinking has been recognized as a foundational competency for engineering and computing education (Mendoza Diaz & Meier, 2023). Defined as “the automation of abstractions” (Wing, 2006), CT includes the development of both an abstract model of a complex, real-world problem and a program to solve the problem automatically. Although CT originated in the fields of computer science and computing, the act of problem-solving through abstraction is relevant across engineering disciplines (Mendoza Diaz & Meier, 2023; Scherer & Leshner, 2018; Weintrop et al., 2016). Chichekian et al. (2024), for example, found that students’ verbal articulation of CT concepts during robotics challenges correlated with performance, suggesting that metacognitive engagement with problem-solving processes is a key indicator of engineering competence.
CT is often broken down into distinct cognitive processes, including abstraction, problem decomposition, algorithmic thinking (AT), pattern recognition, and data representation (e.g., Mendoza Diaz et al., 2021; Wing, 2006). The AT subcomponent focuses on the development of a stepwise, abstract solution procedure for the problem. Because successful creation of stepwise procedures requires upstream processes of problem decomposition and abstraction, some researchers interchange the words AT and CT (e.g., Lafuente Martínez et al., 2022), and many researchers advocate for instructional models and assessment approaches that elevate AT as a core learning outcome in programming education (e.g., Chen & Wang, 2023; Polat et al., 2021). Outside of CT frameworks, AT has been identified as a critical skill to facilitate programming problem-solving (Caspersen, 2007; Grover & Pea, 2013).
Instructional Strategies and Implications
Describing programming as a set of cognitive components is useful when considering effective educational interventions. According to Cognitive Load Theory (CLT; Sweller, 1988), the human brain possesses a limited working memory for processing new information. This capacity is occupied by three types of load: intrinsic load is the inherent complexity of the task; extraneous load is caused by unnecessary complexity; and germane load is the mental effort of integrating new knowledge into long-term memory. By separating the planning phase from syntax development, educators can reduce intrinsic complexity of the problem at hand. Sequencing the planning and syntax writing phases might help students focus their limited cognitive resources, leading to greater learning outcomes.
In engineering education, some instructional modules that frame programming as a tool to solve domain-specific problems have been effective. Rodríguez Del Rey et al. (2021) demonstrated that students exposed to a module of solved problems emphasizing decomposition, algorithmic structuring, and other computational thinking processes achieved significantly better outcomes on selected assessment tasks compared to those taught through traditional problem-solving approaches. Lyon & Magana (2021) found that model-based instruction, which required students to build and refine engineering models, strengthened abstraction skills and helped learners identify reusable computational patterns—key components of AT. (Malik & Coldwell-Neilson, 2017), working with undergraduates in computing programs, found that a model focused on transitioning from problem statement to solution plan to executable code fostered deeper comprehension and discouraged code-first shortcuts by emphasizing structured reasoning using relatable math and real-life examples. A second study by Malik and collaborators (2019) also found benefits of a web platform with pseudocode as a step in the problem-solving sequence, observing a significant improvement in course performance alongside a significant reduction in attrition (withdrawal) from the course.
These findings are echoed in K–12 and pre-university research, suggesting a cross-level consistency in the effectiveness of scaffolded instructional designs. For instance, Polat et al. (2021), highlighted that logic development, debugging, and decomposition are foundational instructional targets for developing computational competencies in secondary education. Malik et al. (2019) working with undergraduates in computing programs, introduced an instructional technique to structure problem-solving around math and real-world scenarios. This intervention helped students shift from shortcut-based coding toward staged reasoning processes, improving both retention and self-efficacy. Likewise, Román-González et al. (2019) and Fagerlund et al. (2021) emphasized the importance of repeated opportunities to apply abstraction and planning within programming tasks, especially for novice learners.
However, recent work cautions that representational tools like flowcharts and pseudocode enhance AT only when paired with structured, scaffolded learning experiences. Zhang et al. (2023) found that progressive flowchart training—structured by scaffolding theory—led to significantly higher learning outcomes than non-progressive use. Similarly, Wong et al. (2024) also reported significant gains in AT when primary students completed scaffolded design processes using partial flowcharts, underscoring the role of faded support and iterative feedback. Complementary findings by Shin et al. (2025) and Zhou et al. (2023) show that metacognitive scaffolds—such as faded worked examples and solution planning—improve students’ programming outcomes. Even in older studies, such as Scanlan (1989), visual representations were found to enhance comprehension and reduce error rates, though not sufficient to close deeper conceptual gaps.
Finally, Bettin et al. (2022) provide strong support for scaffolded instruction in the context of first-year engineering. Their guided inquiry approach combined language-independent questioning and cross-language code review to help students connect pseudocode reasoning with syntax comprehension. Students in the intervention group achieved nearly a full letter grade higher on programming assessments and demonstrated improved recognition of syntactic constructs, structural patterns, and control flow—key features of AT. These results affirm that meaningful improvements in programming and AT stem not from coding alone but from carefully designed pedagogies that guide students through the cognitive processes underpinning problem-solving.
Thus, the studies that have been done indicate that AT can be developed by repeatedly guiding students through the process of planning, structuring, and evaluating computational solutions instead of merely coding them. However, there are only a few studies, and populations and instructional contexts differ. Best practices are largely unknown in the context of first year engineering courses.
Assessing Algorithmic Thinking
Although interest in developing AT has grown, assessing it remains a complex challenge. Traditional evaluations often focus on code correctness or efficiency, failing to capture how students conceptualize and decompose problems (Kules, 2016; Román-González et al., 2019). In response, researchers have emphasized the need for structured, multidimensional assessments that extend beyond programming syntax, or even emphasize that a single method is insufficient for a comprehensive assessment of computational thinking (Román-González et al., 2019).
Polat et al. (2021) proposed a framework for evaluating secondary school students’ CT competencies that includes debugging, logic structuring, and abstraction tasks. Their results suggest that relying solely on programming tasks obscures students’ deeper reasoning abilities. For adult learners, Lafuente Martínez et al. (2022) introduced the Algorithmic Thinking Test for Adults (ATTA), a validated, context-independent instrument that does not require programming knowledge. Their work supports the view that algorithmic reasoning can be reliably measured apart from code production, making it especially valuable in engineering courses where programming serves as a means to broader problem-solving goals. Most recently, the Engineering Computational Thinking Diagnostic was created and validated by Mendoza Diaz and colleagues (2023).
Literature Synthesis and Motivation for the Current Study
In summary, despite growing interest in AT, relatively few studies have directly investigated how AT develops within first-year engineering (FYE) programming contexts. Some prior research highlighted the benefits of structured pedagogical interventions such as scaffolding, model-building, and conceptual problem solving (Lyon & Magana, 2021; Rodríguez Del Rey et al., 2021), but assessments varied (Fagerlund et al., 2021; Lafuente Martínez et al., 2022). Thus, while many FYE courses emphasize outcomes like “write and execute basic code to solve an engineering problem,” they often fall short of assessing the cognitive processes behind solution planning, such as abstraction, decomposition, and logical structuring (Lyon & Magana, 2020; Rodríguez Del Rey et al., 2021).
Moreover, much of the existing literature involves student populations beyond FYE engineering such as secondary students (Polat et al., 2021; Román-González et al., 2019), computing majors (Malik & Coldwell-Neilson, 2017), or full-semester programming courses (Rodríguez Del Rey et al., 2021; Zhang et al., 2023). These studies consistently show that structured, scaffolded instruction improves AT; however, their duration and context differ significantly from multidisciplinary FYE courses where programming is only one component of a broader curriculum. This contrast underscores the need for further investigation into how algorithmic reasoning can be effectively supported within the time-constrained and varied instructional environments typical of first-year engineering education.
The present study addresses the gap in the literature by examining student AT following two different programming-unit instructional designs in a FYE course at a large university. The two instructional methods were code-first instruction (Fall 2024) and flowchart and pseudocode emphasis (Fall 2025). The research questions were as follows:
-
Does incorporating flowcharts and pseudocode in a FYE programming unit improve students’ AT?
-
How does students’ prior experience with programming impact AT scores?
The main hypothesis driving this work was that emphasis on pseudocode and flowcharts during the programming unit would improve student AT score. It was also hypothesized that higher levels of prior experience would lead to higher levels of AT, but that this effect might be mitigated by the pseudocode and flowchart instruction.
Methods
This study compared students’ AT following two different programming unit designs offered in consecutive years. The first instructional design emphasized standard programming elements and structures (2024), and the second instructional design separated the planning phase from syntax development with flowcharts and pseudocode (2025). The University’s Institutional Review Board (IRB) approved this study.
Participants
Participants were undergraduate students enrolled in selected sections of ENGE 1215, a first-year engineering course, during the Fall 2024 (287 students) and Fall 2025 (142 students) semesters. The selected course sections were those taught by one of the authors in Fall 2024 and another author in Fall 2025. Participants were excluded from the study if (a) performance on the homework assignments was below 60% (eight students in 2024 and one in 2025), indicating that they missed an assignment or did not fully engage in the assignment, or (b) the AT score was 0 (seven students in 2024 and five in 2025, indicating possible random responses). After cleaning the data, the final sample consisted of N = 239 students from the Fall 2024 cohort and N = 125 from Fall 2025.
Course Instructional Designs
ENGE 1215 is the first course in a required first-year engineering sequence at a large Mid-Atlantic research-intensive university, enrolling over 2,000 students annually. The course is structured around foundational modules including engineering disciplines, computer-aided design, programming, and engineering design fundamentals. MATLAB is the language used for the programming module. A core learning outcome for the programming module is to enable students to “write and execute basic code that aids in solving an engineering problem to demonstrate skills in computer programming as an engineering tool.”
Fall 2024. In Fall 2024, instruction was centered around helping students develop basic proficiency with MATLAB. The first class introduced the interface, built-in functions, input/output commands, and script creation. Subsequent classes covered sequential operations, data visualization, decision structures, and loops, all grounded in example-driven instruction. Activities were designed to help students develop correct code through practical examples. Each week concluded with a take-home assignment—a MATLAB Challenge—aligned with the week’s topic.
Students were not explicitly asked to develop pseudocode or flowcharts. Instead, they received structured prompts under the heading “Your program should” which functioned as de-facto pseudocode. The use of GenAI in the course was restricted during the programming unit; students were explicitly notified via a note included in the instructions of each assignment, as presented below. The following is an example of the prompt used for the MATLAB Challenges.
Fall 2025. The Fall 2025 course was redesigned incorporating structured scaffolds to guide students through algorithm planning before writing any code, an approach aligned with research emphasizing the role of explicit instruction and representation sequencing (Bettin et al., 2022; Wong et al., 2024; Zhang et al., 2023).
Instruction moved away from example-driven programming and emphasized the development of flowcharts and pseudocode as precursors to code writing. This was consistent with prior work showing that explicit attention to solution planning and algorithm design supports computational and AT development (Fagerlund et al., 2021; Malik & Coldwell-Neilson, 2017; Rodríguez Del Rey et al., 2021). Each concept, such as input/output, conditionals, or loops, was introduced through a structured “flowchart to code” approach, reflecting recommendations to embed decomposition, algorithm design, and debugging within instruction (Polat et al., 2021). Assignments were also modified to require flowcharts and pseudocode alongside final MATLAB scripts.
The first week of the programming unit began with a series of think-pair-share activities (Barkley et al., 2014) to help students externalize their reasoning and collaboratively build logic structures, aligning with research emphasizing verbalization and collaborative sense-making as mechanisms for eliciting computational thinking (Chichekian et al., 2024; Lyon & Magana, 2021). In the first class, students created flowcharts for real-life decision processes (e.g., “What to wear based on the weather”), compared numbers, and built temperature conversion logic, all before writing any code. These flowcharts were then peer-reviewed and refined through group discussions. In the second class, students revisited their diagrams to write pseudocode and then collaboratively translated these into MATLAB scripts, drawing from evidence of how guided pre-programming activities and language-independent questioning can improve novice students’ programming performance and comprehension (Bettin et al., 2022). This structured pedagogy, modeling the progression from flowchart to pseudocode to code, was consistently applied over the remaining three weeks of the programming module. In every session, students first designed logic visually, then translated it to pseudocode, and finally to MATLAB scripts, consistent with research showing that representational tools are most effective when embedded within scaffolded and progressive instructional sequences (Wong et al., 2024; Zhang et al., 2023).
The MATLAB Challenges were also modified to more explicitly foreground AT rather than code production alone. While the problem statements and technical requirements remained comparable to those used in Fall 2024, the structure of the assignments was modified to require students to externalize their reasoning before writing code. Specifically, students were required to 1) construct a flowchart to represent their solution logic, 2) write pseudocode based on that flowchart, and 3) translate the pseudocode into a working MATLAB script, following recommendations to design assessments that emphasize process and algorithm design in addition to final code (Paniagua & Braman, 2023; Polat et al., 2021). The assignments no longer provided step-by-step pseudocode guidance and instead prompted students to determine the logical structure themselves. Additionally, the use of MATLAB Copilot was permitted only as a support for translating pseudocode into code, with students responsible for validating and explaining any AI-assisted components, in alignment with emerging guidance to position GenAI as a scaffold rather than a replacement for foundational thinking (Güner & Er, 2025; Silva et al., 2024). The grading rubric was updated to include explicit credit for the completion of flowcharts and pseudocode—although not for their quality or correctness—reinforcing the instructional emphasis on engaging with algorithmic reasoning as a core strategy for programming.
Instruments
The AT scale used in this study was a subset of the ATTA instrument developed by Lafuente Martínez et al. (2022). The full ATTA includes 27 items (reported Cronbach’s α = .847) designed to assess competencies including evaluation, abstraction, decomposition, and pattern recognition, alongside the general AT term, and required over 90 minutes for completion. Seven items (6, 9, 12, 13, 25, 26, and 27) were selected from the ATTA to maintain a manageable completion time and maximize student engagement. The resulting 7-item subset yielded a Cronbach’s α of .676 (N = 386) in the present study. Items were selected based on their alignment with AT (see Table 1 of Lafuente Martínez et al., 2022), and to provide variation in difficulty (see Table 6 of Lafuente Martínez et al., 2022). Each item selected was highly correlated with overall AT.
In addition to the AT instrument, students reported their prior programming experience on a four-level scale, as follows:
0. Total Newbie: I had no prior programming experience.
1. Curious Dabbler: I tinkered with programming but never seriously.
2. Confident Coder: I had some structured programming experience.
3. Seasoned Pro: I had extensive programming experience before this class.
Additional data included students’ average normalized course grade, and average normalized grade on the MATLAB Challenge assignments of the programming unit.
Procedures
In both semesters, students reported their programming expertise at the beginning of the semester, completed a four-week MATLAB module in the middle of the semester, and responded to the AT instrument at the end of the course. Students received full credit for completing the AT instrument, regardless of performance. All instruments were administered via the university’s learning management system (Canvas) and results were analyzed in aggregate form.
In Fall 2024, the MATLAB module instruction focused on teaching students how to solve simple programming tasks with an emphasis on programming elements and structures. In Fall 2025, instruction centered on fostering AT skills using flowcharts and pseudocode. Details are included in the Course Intervention section above. The AT test was administered as an assignment at the end of the semester. Students were instructed to complete the assessment individually and were encouraged to submit thoughtful responses. Students received full credit for completing the assignment, regardless of the score earned. Seeking alignment with the instructional focus on AT, in Fall 2025 the test also included questions about students’ engagement with flowcharts and pseudocode, and perceptions of the usefulness of these tools, which are not included for full analysis in this study.
Data Analysis
All data (i.e., prior programming experience, AT test performance, and MATLAB challenge average) were downloaded from Canvas for analysis. Datasets from the two highest levels of self-reported prior programming experience (“Seasoned Pro” and “Confident Coder”) were grouped into one experience level, as only a few students (less than 10%) ranked themselves at the highest level.
Descriptive statistics were used to summarize participants’ performance on the MATLAB Challenges and the AT assessment, along with their self-reported experience. MATLAB Challenge grades were significantly negatively skewed, but the AT assessment scores were normally distributed.
To explore relationships among the variables, non-parametric Spearman’s rank-order correlation coefficients were calculated. An analysis of variance (ANOVA) was then conducted with the dependent variable of AT test performance and between-subjects factors of year (2024, 2025) and experience level (low, medium, and high). Post-hoc tests (Tukey) were used to identify subgroup differences.
An analysis of covariance was also conducted, with normalized final course grade and MATLAB challenge grades as covariates, but the analysis did not yield additional insights. Covariates were not significant, and all significant effects aligned with the original ANOVA. The results are therefore not described below.
Results
Descriptive Statistics
Figure 1 presents the distribution of students’ self-reported programming confidence levels for both cohorts.
Table 1 presents descriptive statistics for all variables examined in this study, disaggregated by the Fall 2024 and Fall 2025 cohorts. Both means and medians are reported to account for differences in data types (continuous and ordinal). The Algorithmic Thinking (AT) score ranges from 0 to 7, corresponding to the number of correct responses on the seven-item instrument, with 7 representing the maximum possible score. In this study, we do not categorize AT scores as “low” or “high”; rather, we focus on relative comparisons between cohorts. Students’ prior programming experience is self-reported on a scale from 0 (Total Newbie) to 3 (Seasoned Pro). The MATLAB Challenge average represents students’ performance on programming assignments completed during the module, while the course grade reflects the overall final grade in the course. Both variables are normalized on a scale from 0 to 1, where values closer to 1 indicate higher performance.
Correlation Analyses
Correlation analyses are reported for both the 2024 and 2025 cohorts and summarized below in Table 2.
2024 Cohort
Correlation analysis revealed a statistically significant positive relationship between programming experience and AT scores (ρ = .130, p = .045), indicating that students with more self-reported experience tended to score slightly higher on the AT instrument. Programming experience was also significantly positively correlated with MATLAB challenge grades (ρ = .153, p = .018). MATLAB challenge grades were not significantly associated with AT scores (ρ = .112, p = .084).
2025 Cohort
In 2025, the correlation between programming experience and AT scores was not statistically significant (ρ = .154, p = .087), though the direction and magnitude of the relationship was similar to the 2024 cohort. Programming experience was also not correlated with MATLAB challenge grades (ρ = .003, p = .971). The correlation between MATLAB challenge grades and AT scores was significant (ρ = .263, p = .003). In this case, students who performed better on the programming challenges tended to have higher AT skills.
ANOVA Comparison of 2024 and 2025 Cohorts
The ANOVA revealed statistically significant main effects of year, F(1, 358) = 6.612, p = .011, and experience level, F(2, 358) = 3.133, p = .045, on students’ AT scores. The interaction between year and programming experience was not significant, F(2, 358) = 0.181, p = .834. Means are illustrated in Figure 2. Contrary to our hypotheses, students in Fall 2024 had higher AT scores than students in Fall 2025. These results suggest that the instructional changes implemented in 2025, focused on flowcharts and pseudocode, did not lead to higher AT scores as measured by the current assessment approach.
Post-hoc tests revealed that the only statistically significant difference occurred between students with no programming experience and those with high programming experience (Experience Level 2), with a mean difference of −0.593, p = .039. This suggests that students with higher prior programming experience performed significantly better on the AT assessment than those with no prior experience. These results reinforce the conclusion that prior programming experience is associated with stronger AT, but only when that experience is substantial.
Discussion
Descriptive statistics revealed that the first-year engineering students in this study, in both cohorts, were equally distributed across three prior experience groups: no experience, some experience but no formal instruction, and some structured programming experience. Despite this range of prior experience, the means of the MATLAB challenge activities and course grades were above 90% for both cohorts after removing outlier data points, indicating good engagement and participation in the course materials. Performance on the AT test was normally distributed around the middle of the 7-point scale in both cohorts, indicating that the AT assessment was more difficult for the students than the course assignments, providing variability that is necessary to detect the impact of an intervention.
Correlation analyses revealed different relationships between variables in the two cohorts. In 2024, prior programming experience was positively correlated with both MATLAB challenge grades and AT performance, indicating that students with higher prior experience had better learning outcomes from the course than students with lower prior experience. In 2025, those correlations were not significant (prior experience with course assignments, p = .087, and prior experience with AT score, p = .971). It is possible that the syntax-focused course materials in 2024 provided an advantage to students with prior programming experience, perhaps because the materials were similar to their prior instruction. The updated, AT-focused programming instruction in 2025 may have reduced the benefit to more experienced students by introducing the content in a different way.
Additionally, MATLAB challenge grades were not significantly correlated with AT performance in 2024 (p = .084), whereas there was a significant correlation in 2025. The MATLAB challenge grades were not normally distributed, and it is possible that a correlation was masked by a ceiling effect in 2024. But it is also possible that the successful completion of programming challenges within a grading structure that emphasizes correctness and task completion does not necessarily contribute to students’ underlying algorithmic reasoning processes, whereas successful completion of programming challenges with a focus on AT can lead to higher AT. The 2025 results demonstrate alignment between the revised instruction and the AT assessment.
However, the ANOVA revealed a significant main effect of the year on AT performance in an unanticipated direction: students in the 2024 cohort performed significantly higher on the AT assessment than those in the 2025 cohort. This result suggests that flowcharts and pseudocode instruction resulted in losses rather than gains in AT. There was also a positive main effect of experience, with higher experience leading to higher AT performance, and no interaction between year and experience. The absence of significant interaction indicates that the instructional changes did not differentially benefit students based on their prior programming backgrounds; overall, the instruction in 2024 resulted in higher AT than the instruction in 2025.
This finding is contrary to several in the literature that demonstrate that scaffolded instruction in problem-solving improves AT outcomes. However, those studies vary in context from the current study. One important methodological difference is the duration of the intervention; several of the previous studies were conducted over entire semesters (e.g., Malik & Coldwell-Neilson, 2017; Rodríguez Del Rey et al., 2021), whereas the current study was only performed in the programming unit of a larger introductory engineering course. Therefore, it is possible that the current intervention did not have a high enough “dosage” to generate the desired effect. Studies have shown that for some interventions, a minimum cumulative threshold of exposure is required before statistically significant learning gains can be observed (e.g., Duhon et al., 2022). The 2025 instructional intervention spanned only a 4-week module, which may have fallen below the necessary cumulative threshold to influence complex cognitive skills like AT. A single programming unit is common in first-year engineering curricula. Thus, if dosage is an important factor, direct AT instruction may not be appropriate for first-year engineering courses.
Because FYE programs often have only 4- to 5-week programming units, one interpretation of our series of results is that AT may develop more robustly in these contexts through accumulated exposure to syntax rather than flowchart or pseudocode instruction (Chen & Wang, 2023; Lafuente Martínez et al., 2022; Rodríguez Del Rey et al., 2021). Mean AT performance was lower in the intervention group, while students with greater prior programming experience consistently achieved higher AT scores. The importance of hands-on practice and active engagement in writing and refining code would be aligned with Bettin et al. (2022), who demonstrated that structured algorithm development using guided inquiry significantly improved programming performance.
However, these results should be interpreted with caution for several reasons. First, the pseudocode and flowchart course materials and unit design were new at the time of the study. There may have been alignment issues or conceptual difficulty leading to increased extraneous cognitive load rather than a reduction in cognitive load (Sweller et al., 2011). Some work has shown that interventions based on best-practices need time and instructor work to achieve the promised learning gains (Bego et al., 2022). In a separate, anonymous survey administered in 2025, over 73% of students rated pseudocode as either helpful or very helpful, while only 38% of students rated flowcharts at the same levels. This disparity suggests that students perceived pseudocode as more directly aligned with their ability to write functional code—a perception consistent with prior findings that pseudocode promotes more efficient comprehension and reduces programming errors (Andrzejewska & Stolińska, 2022; Malik & Coldwell-Neilson, 2017). This perception may have been reinforced by the opportunity to translate pseudocode directly into executable code. By contrast, students may have viewed flowcharts—arguably more closely aligned with the development of AT—as less useful, prioritizing immediate programming performance over more abstract reasoning processes.
Thus, another interpretation of these findings is that this emphasis on pseudocode and flowchart instruction may have increased students’ cognitive load instead of reducing it. As mentioned in the literature review, Zhang et al. (2023) found that progressive flowchart scaffolding better supported students’ algorithmic thinking development than standard flowchart instruction. Scaffolding is an evidence-based practice supported by cognitive load theory; it provides supports at the beginning and removes them as students become more comfortable. One possibility is that flowchart and pseudocode instruction must be progressively scaffolded to be more effective than the traditional syntax-integrated problem-solving. If this is the case, it would be a finding for engineering and computing educators to consider when developing or modifying their teaching practices. More work is needed to gather evidence supporting this finding and bring forth other best practices in AT and CT instruction.
Methodological Limitations
This study followed a quasi-experimental design and was conducted over two consecutive years. There were different instructors and instructional support team members (i.e., GTAs and UTAs) across years, possibly leading to different classroom dynamics, teaching style, classroom management, interaction patterns, grading, and feedback styles. However, the two instructors (both of whom are authors of this paper) worked closely together to develop and implement the study, and course procedures such as grading rubrics were held consistent, and in the researchers’ opinion, this is not likely to have severely impacted the results. There also may have been differences in the student populations or other contextual factors changing over time that could have affected the results (e.g., generative AI adoption or attitude of students).
In addition, there were some measurement constraints in our study. The MATLAB programming challenges had a strong clustering of high grades, and the lack of variability may have limited our ability to explore meaningful correlations between performance and other variables such as AT score. Secondly, the administration of the AT instrument was a take-home assignment, making it difficult to verify students’ level of engagement. Some students may have attended only to a subset of questions, which could have influenced the results. However, our data analysis procedure did look for common indicators of lack of engagement, and those data points were filtered out. The reliability of this portion of the scale was Cronbach’s α = .674, which also should be considered when evaluating the implications of the results.
Lastly, the advancement of GenAI tools is also now an important contextual factor of any programming instruction intervention study. Although GenAI can effectively support syntax learning and code generation, overreliance on such tools, particularly for producing complete solutions, may impede the development of AT. This concern is validated in recent research showing that students who rely heavily on GenAI for code generation tend to bypass essential cognitive steps such as problem decomposition and logical structuring, leading to superficial understanding and reduced performance (Güner & Er, 2025; Zviel-Girshin, 2024). In this study, students were allowed to use GenAI to translate pseudocode into working code, and this step may have inadvertently encouraged behavior that circumvented AT development. When students bypass the cognitive processes involved in problem solving through programming by deferring to AI-generated solutions, they risk missing critical learning opportunities that support the development of algorithmic reasoning. In our study, the use of GenAI was more widespread and accepted among students in the 2025 cohort than in 2024.
The limitations of this study as well as the findings highlight several opportunities for refining instructional design, assessment methods, and grading strategies around pseudocode and flowchart pedagogies. Much more future work is needed.
Conclusion
This study examined whether shifting the instructional emphasis from writing executable code toward expressing algorithms through pseudocode and flowcharts before writing code would lead to stronger AT skills. The results did not support this expectation. Instead, results showed that students who developed programming skills through sustained engagement with coding practice without the scaffolding tools mentioned above also tended to demonstrate higher levels of AT. These results indicate that the inclusion of pseudocode and flowcharts will not necessarily improve AT in the introductory engineering course context. However, results from this study must be interpreted through its limitations, which included differences in instructors, the novelty of the instructional intervention, and the relatively short duration of student engagement with the redesigned activities. Additional research is needed to consider best-practices of cultivating AT in the FYE context, whether it is an increased duration or progressive scaffolding of pseudocode and flowcharts, or another pedagogical intervention altogether. Importantly, future studies should carefully select outcome measures that align with the intended learning objectives, particularly when assessing complex constructs such as AT.
AI Disclosure
SciSpace was used to generate summaries of the purpose and reported findings of cited papers, assisting the authors in selecting, synthesizing, and organizing this literature review. All papers included were reviewed by the authors.