Over the last few months, I have had conversations with people from all over the tech world about various and sundry subjects related to our fields — Professors, Undergrads, Ph.D. students, CEOs and CTOs, Senior Software Engineers, Junior Engineers, Data Scientists, and everything in between. From all of these points of view, we have observed one particular issue: the role of the junior engineer is disappearing. Some that I have talked to think it is a natural byproduct of the advent of artificial intelligence (AI) coding assistants. Others believe that it is the beginning of the end of the computer science degree altogether, and that in five to ten years there will be a massive shortage of senior-level engineers. Still others believe that this dip in junior-level positions is temporary, and that no course correction is necessary. In this article, I will explain my point of view on the crisis of the junior engineering role, and what I think we can do about it.

Let’s begin with what I perceive to be the difference between a junior engineer and their more experienced counterparts. The biggest difference between junior and senior/staff/lead engineers is the ability to understand a problem from its highest level, break the problem down into smaller pieces, solve the smaller pieces, and then, very importantly, put the smaller pieces together again in the right way to make the final product as efficient and robust as possible.

My view of how this works in the classic tech company is that the higher-level engineer will break down the business problem into smaller problems for more junior engineers to solve. Often, in bigger projects, the lead engineer will break the problem into still-large sub-problems that need to be further broken down. The senior engineer will break that sub-problem down and assign the smaller pieces to junior engineers. The lead and senior engineers work on ensuring that all of the pieces that they broke apart will fit nicely together, and the junior engineers build the bulk of the code.

Junior engineers learn from this experience by watching how their superiors break down these problems and put them back together again. This is particularly effective in in-person environments, and less-so in remote environments (another contribution to the disappearance of junior-level roles). It has been shown over and over that people learn more effectively in in-person environments both in school and out. In conversations that I have had outside of or adjacent to the tech world, this trend towards remote environments reflects issues that are faced by junior lawyers, financiers, and nearly every other industry. If a junior engineer wants to advance their career, they must learn to do the job of their superiors. However, traditionally, the main use case for a junior engineer is to implement the code that would take too much time for a higher-level engineer to build.

I think that at this point, you might see the problem for many junior engineers. If a senior or even lead engineer can break down his problem into the smallest pieces and task an AI coding assistant with writing those pieces, then why bother with a junior engineer at all? Junior engineers take training and code review and mentorship. Junior engineers make mistakes, and can sometimes make mistakes that are very difficult to spot. Previously, junior engineers were necessary to a business because the senior and lead engineers cost too much money to task with writing the bulk of a codebase. Now, junior engineers cost too much time, money, and hassle to not replace them with AI coding assistants.

In college, there is a skill taught that I would argue is even more important than coding. I am speaking of course of the skill of breaking problems down into abstract sub-problems, solving those sub-problems, and then piecing them all back together again — in short, problem-solving skills. In the age of AI coding assistants, I think that this skill is more important than ever for future junior engineers to hone. Certainly the skill of writing efficient and elegant code is still a requirement, but it is comparatively less important than this problem-solving skill that separates us from AI coding assistants. To be clear, colleges have always taught problem-solving skills in nearly any degree that they offer. Computer science was the pinnacle of the abstract problem-solving degree.

I believe that the response of computer science departments should be to refocus themselves on the skill abstract problem-solving. When I was an undergraduate from 2011 to 2015, professors could assign difficult problem sets that honed both the problem-solving skill and the coding skill. Now, we as professors cannot effectively force students to hone their coding skills. They have to choose to do that instead of having an AI coding assistant do it for them. However, we can still certainly force them to hone the problem-solving skill.

This refocusing could, and maybe should, lead to a different high-level design of the computer science degree. What started as a specialized mathematics degree has transformed in many colleges into a degree to learn to code. Mathematics is very clearly a problem-solving field, and at this moment in time, the field of computer science must reconnect with its roots. I propose that we should incorporate more math courses into computer science degrees, for the simple sake of directly honing problem solving skills.

During my vast conversations, everyone agreed that regardless of whether computer science degrees reconnect with their mathematical roots, we will certainly see huge changes in the composure of computer science courses. I believe that assignments should focus on solving a problem and then, if necessary, coding it up. We need to realize that, in a complete flip from the past ten to fifteen years, the vast majority of a student’s time spent on a given assignment will almost certainly not be spent coding — it will be spent problem-solving. If the problem that we assign is trivial or not challenging enough, then the student will either not gain anything from the assignment because they did not have to think critically about the problem, or because it was easy enough that they could ask an AI assistant how to solve the problem. As AI assistants improve, we might not even be able to guarantee that a student could not outsource the problem-solving itself. So how do we ensure that they do the work?

One word, two per semester: Exams. Exams in the field of computer science should not test a student’s recall. They cannot really effectively test a student’s coding ability without giving them access to a computer and therefore an AI assistant. But, exams can still rigorously test a student’s problem-solving skills. Write difficult exams, even ones that might be too difficult for some or most of the students. This is not to scare them, but to make them realize what they should be focusing on. If students outsource the problem-solving practice from assignments, they will, and should, almost certainly fail their midterm. There will be two possible outcomes: either the student doesn’t learn the meaning of this and continues to outsource everything to AI, or the student begins to hone their problem-solving skills by doing their assignments themselves. In the case of the former, I would say that they deserve to fail the class, because they are not putting in the effort and they are not learning the material.

I personally loved exams as a student. I was, and am, a good problem solver, and even better under pressure. I do not like exams as a professor. I hate grading exams, especially because students who I know to be intelligent often perform poorly. On top of that, I would so much rather assign one or two more interesting programming assignments in their place. But it seems to me that the times are gone where we could trust that our assignment was unique enough that our students couldn’t find the answer on google. Now, the students don’t even need to spend three hours carefully constructing google search queries to find a PDF in a different language with the solutions to one of the three problems in their weekly problem set1. Now, we know with certainty that our students can use an AI-assistant to solve almost any of the programming assignments that we create. Exams — physical, in-person exams — will create junior engineers with the best shot of being successful in industry, because they will provide students with a reason to hone their problem-solving skills above all else.

Before last December, I can hardly remember a time in my life where I was not a student. After ten years of college and three degrees, I was about to go gallivanting around the country for the better part of a year in celebration of having finished. I was not going to be in any one place longer than a month, but I promised Lisa, my Ph.D. advisor, that when I finally moved to a place for a long enough time that I could teach a college class, I would give it a shot.

A year later, after driving a loop around the greater forty-eight states, I found myself in Bend, Oregon for about five months. My promise to Lisa, which had never truly faded in my mind, was at the forefront of my mind. As it turned out, there is a branch of Oregon State University (the Cascades campus) about five minutes from where I was living, and they were hiring computer science professors. Not long after I arrived in Bend, I was meeting with the head of the C.S. department. I didn’t want to sound picky, so I told her that I would feel comfortable teaching whatever class they needed me to. I was surprised to find out that they would be delighted to have me, and that I would be teaching Programming Language Fundamentals, a class for juniors.

In the interest of full disclosure, the last time I even thought about this class was when I took the Boston University version of it as a sophomore in college… nine years ago.  Teaching data science, or machine learning, or databases, or algorithms, or theory, almost any other class, would have been more in my wheelhouse.  I remembered Programming Language Fundamentals fondly, but vaguely.

Finally, ten days before class was due to begin, and two days before I went on vacation for a week, I received the course material.  The course had been created for online learning.  I was going to be teaching in-person.  There was plenty of material, but the class was designed with the intention for students to do roughly 30 pages of reading per class (book chapters and supplementary readings).  All of the assignments were online.  There were no exams or projects.  It seemed to me that the class had been well-designed for an online class.  Grading was automatic across the board, which would make it perfect for large online classes.  But I had less than twenty students.  To complicate the situation, the homeworks and quizzes were supposed to be completed outside of class, and the questions were very fact- and recall-based. This would make the class extremely vulnerable to cheating, and even more so with the advent of ChatGPT.  I decided to plan my own in-person version of the class.

I had hoped, perhaps a bit too ambitiously, to plan the whole class ahead of time.  I went to Lisa and Mahe, the professor who teaches the same class at Georgetown, for advice. Mahe warned me not to plan more than two classes ahead.  “You never know what they will get stuck on.  Sometimes a subject takes one week, sometimes it takes two weeks.  It’s up to them.  Don’t plan too far ahead.”  Thankfully, planning a class is more involved than attending a class.  For the first time in my life, I was reading the textbook and taking notes, not for myself, but for other people.  I found that I paid much better attention when it was for someone else.  Not only do I have to absorb it, I have to be able to regurgitate it.  As I created the lecture content, I also had to figure out what would make a good in-class activity, and how to design a homework to solidify what we learned in class.  As I planned the first two classes, I didn’t know whether I would strike the right balance of difficulty, and I realized why Mahe had told me not to plan too far ahead.  What if I made it way too difficult?  Or worse, what if I made it way too easy?

Finally, it was the first day.  I had chosen to write on the board instead of creating powerpoint slides so that I could ask people to come to the board and solve problems.  For the first five minutes, my handwriting was shaky, and I forgot my train of thought a couple of times. That all changed when I asked the first student to draw something on the board.  I threw him an open marker, which he deftly dodged.  He laughed.  I laughed. I said, “that wasn’t the smartest move was it?”  The rest of the class laughed.  All of a sudden, the nerves were gone, and I never looked back from there.

The note-taking aspect was not one of my students’ favorites throughout the class. Most of their classes employed powerpoint slides or digital reading lists, and so in class, note taking was optional. Since I was writing on the board, note taking was required. I am still unsure whether this was the best option, but my students adapted quickly, and nobody fell behind because the contents of the course were not online.

Like the course content itself, the nature of assignments had to change as well. Instead of online, multiple-choice questions, homeworks would be hand-written and reasoning-based. Students were asked to show their work and hand in homeworks at the beginning of class. I also used ChatGPT myself to check how it would answer my questions, deliberately chose questions that it got wrong, and, importantly, told my students that I had done this. I anticipated some pushback, but in reality the reaction to this was just shy of revolt for some students, who remarked that they had not been given a hand-written assignment since high school. However, by the end of the class, nearly every student didn’t seem to mind it.

In addition to reworking homeworks, I created an in-class activity for each class. These were meant to be shorter, but more difficult than homeworks. Students had the extra aid of me being there to help, and the cheating deterrent of me being there to help. Why go to ChatGPT, when the person who knows the answer is standing right in front of me? The combination of hand-written homeworks and in-class activities seemed to reduce the amount of cheating that occurred in my class, and students felt like they were learning more because they were being asking to interpret what they learned instead of recite it.

The second week, I assigned the first of two projects for the class.  They were going to be given three weeks to complete it. Everyone happily nodded their heads to acknowledge that they understood. For the next two weeks, I asked about everyone’s progress at the beginning of class.  Everyone seemed pretty confident. 

The week before the project was due, I chose to have in-class project time in lieu of an in-class activity.  It was only then that I learned that nobody had actually started the project yet.  They assumed that the project would be easy and that it would take them a couple of hours to do the day before it was due.  I, on the other hand, had intended that they would have plenty of time to finish if they started two weeks before it was due.  There were a mixture of reactions.  Some people seemed unfazed.  Others were overwhelmed.  One person dropped the class. 

My initial reaction was that clearly people should have known to start the project earlier.  But then I realized that I could have been more clear about what I expected from them.  I reminded them of a class policy that I had implemented that allows them three late days that they could use over the course of the class for any assignments.  Almost everyone used at least one late day for the project.  They clearly learned their lesson, because within a week of the second project being assigned, nearly every student had started.

I learned my lesson too.  If everyone is struggling, it’s likely not their fault.  The second project had more frequent check-ins over the course of four weeks, instead of just a due date at the end. On the due date, nearly everyone had turned in the project on time, and the rest were planning on using their last late day or two. There were no overwhelmed students knocking on my door.

Each class has been of varying difficulty.  The course goes through a number of subjects in the realm of programming languages.  Sometimes, classes are difficult for me.  The last time I took this class was nine years ago, and some of the subjects are more familiar to me than others.  I have made… numerous mistakes, both during lecture and in defining assignments. When I threw an open marker to a student on the first day, I accidentally set myself up to rebound from my mistakes, and to mitigate my students’ mistakes.  If I make a mistake, my students know that if they point it out and make a joke out of it, I will laugh it off.  They also know that if they make a mistake, they can laugh it off.  I always correct myself when I’m wrong and I give credit to the student who corrects me.  The result of this has been that nearly everyone is comfortable participating in class.  I don’t take myself too seriously, and it has clearly rubbed off on my students. After all, we’re doing math and writing code, not solving world hunger.

Lisa has, for many years now, insisted that I would make a great college professor. I have always enjoyed teaching, and was Lisa’s teaching assistant five times during the course of my Ph.D. studies.  Am I a great professor yet?  Definitely not.  Was I even a good professor?  We will see when I get my reviews back.  Was I completely comfortable teaching this class, as I had claimed I would be?  Definitely not at the beginning.  Am I a better teacher than when I showed up and said that I would be comfortable teaching any class?  Certainly.  Did I learn a lot about teaching?  Absolutely.  These have been my main takeaways from my first time teaching a college course:

1. Don’t be afraid to ask your own professors for their input.  They are usually psyched that you liked their class and teaching style enough that you want to replicate it.

2. Don’t be afraid to make the class your own.

3. Don’t plan too far ahead.

4. Remember that if everyone is struggling, it’s likely not their fault.

5. You will likely never be able to make it impossible for students to cheat. Making it inconvenient seems to be far more effective.

6. Correct yourself when you miss something.

7. Don’t take yourself too seriously.

Did I have fun?  Definitely.

I would like to thank Lisa and Mahe for their guidance and encouragement, and the OSU Cascades computer science professors for their trust and help.