1. The Changing Definition of a Software Engineer

Artificial intelligence is fundamentally changing the way software is developed. Tasks that once required considerable programming experience, technical knowledge, and hours of implementation can now be accomplished with the assistance of AI coding agents in a fraction of the time.

A developer can describe a feature in natural language, provide the necessary context, and ask an AI agent to generate an implementation. The developer's responsibility increasingly involves understanding the problem, defining requirements, evaluating generated solutions, identifying limitations, and ensuring that the resulting system behaves as expected.

This shift raises an important question: If the nature of software development is changing, why are we still hiring software engineers using methods designed for a fundamentally different job?

For decades, software engineering recruitment has relied heavily on programming exercises, algorithmic challenges, data structure questions, and examinations of language-specific knowledge. These methods were developed around an assumption that the ability to write code is one of the strongest indicators of someone's ability to develop software.

That assumption is becoming increasingly difficult to defend.

When AI systems can generate code, the ability to produce code manually is no longer a sufficient measure of engineering capability. The more important question is whether someone can determine what needs to be built, communicate that requirement precisely, guide AI systems toward a reliable implementation, and critically evaluate the result.

This does not mean programming knowledge has become irrelevant. Rather, the relative importance of different engineering competencies is changing.

The industry therefore needs to reconsider not only what it teaches aspiring engineers but also how it identifies, evaluates, and recruits them.

2. The Decline of Traditional Junior Engineering Recruitment

One of the most concerning developments in the software industry is the declining demand for entry-level software engineers.

Historically, organizations maintained a relatively predictable engineering career structure. Junior developers handled smaller implementation tasks, learned from experienced colleagues, gradually assumed greater responsibilities, and eventually developed into independent engineers.

This structure provided an important mechanism for producing the next generation of experienced technical professionals.

AI-assisted development is disrupting this arrangement.

Organizations can now delegate a growing number of routine implementation tasks to AI systems. Consequently, some companies have less incentive to recruit junior developers for work that can be completed by existing engineers using AI tools.

At the same time, experienced engineers remain valuable because they possess the judgment required to understand complex systems, evaluate architectural decisions, identify risks, and take responsibility for production software.

This creates an imbalance: organizations increasingly prefer experienced engineers, while opportunities for developing that experience are becoming less available.

2.1 The experience paradox

The traditional engineering career progression depends on an ecosystem in which junior developers receive opportunities to gain experience.

However, when organizations reduce junior recruitment, fewer people enter the professional development pipeline.

This creates an experience paradox:

• Companies want experienced engineers.
• Junior engineers need professional opportunities to become experienced.
• Companies reduce entry-level recruitment because AI makes certain junior-level tasks easier to automate.
• Fewer junior engineers receive the experience necessary to become senior engineers.

In the short term, hiring experienced professionals may appear economically rational. In the long term, however, an industry that consistently avoids developing junior talent risks weakening its own talent supply.

The problem is therefore not simply that junior engineers are losing jobs. It is that the industry may be undermining the mechanism through which its future engineering workforce is developed.

2.2 The problem is not necessarily a shortage of capable people

It would be inaccurate to conclude that new graduates are inherently less capable of succeeding in modern software engineering.

Many aspiring engineers have strong analytical abilities, technical curiosity, and the potential to become excellent product-oriented engineers.

The difficulty is that their education and traditional hiring evaluations may not reflect the work organizations increasingly expect them to perform.

A candidate might perform exceptionally well in algorithmic interviews but struggle to understand ambiguous product requirements. Another might have relatively limited programming experience but demonstrate excellent reasoning, communication, and the ability to build useful software with AI assistance.

Traditional recruitment methods may identify the former more easily, even when the latter could be better suited to the evolving role.

This suggests that the industry has an assessment problem, not merely a talent problem.

3. Why Traditional Technical Interviews Are Losing Their Predictive Value

Traditional technical interviews generally attempt to evaluate engineering ability through controlled programming exercises.

Candidates may be asked to reverse a linked list, implement a sorting algorithm, solve a graph problem, or optimize a particular function.

These exercises have historically served several purposes:

1. Evaluating knowledge of programming fundamentals.
2. Measuring analytical and algorithmic reasoning.
3. Assessing familiarity with programming languages and data structures.
4. Observing how candidates approach technical challenges under pressure.

Although these competencies remain useful, they do not necessarily represent the most important activities in AI-assisted software development.

Consider a modern engineering task: building a customer management application.

The difficult part may not be implementing a database query or writing a user interface component. Instead, it may involve understanding what the customer actually needs, identifying missing requirements, deciding which functionality is essential, selecting appropriate constraints, and determining whether the proposed implementation solves the underlying problem.

A candidate who can write code quickly but cannot understand these requirements may produce an technically functional but fundamentally incorrect system.

Conversely, a candidate who understands the problem, communicates effectively, and knows how to guide AI toward a suitable implementation may produce a significantly better outcome.

3.1 Coding ability versus engineering judgment

It is important to distinguish between programming and software engineering.

Programming primarily concerns expressing instructions in a language that a computer can execute.

Software engineering encompasses a broader set of activities, including:

• Understanding problems and stakeholder needs.
• Translating requirements into technical specifications.
• Designing systems and defining their boundaries.
• Selecting appropriate technologies and implementation strategies.
• Evaluating correctness, security, and maintainability.
• Managing complexity and changing requirements.
• Testing, deploying, and maintaining software.

Programming is an important component of software engineering, but it is not the entirety of the discipline.

AI does not eliminate the need for engineering knowledge. It changes how that knowledge is applied.

As implementation becomes increasingly assisted by AI, the ability to exercise sound engineering judgment becomes more important.

3.2 The limitations of artificial interview environments

Another limitation of traditional coding interviews is that they frequently measure performance in an artificial environment.

Candidates are given a narrowly defined problem and a limited amount of time to produce a solution, often without access to their normal development tools.

Real software development rarely works this way.

Engineers collaborate with stakeholders, investigate existing systems, consult documentation, experiment with different approaches, revise implementations, and receive feedback.

A technical interview that prohibits AI assistance may therefore evaluate a working environment that candidates will rarely encounter in their actual jobs.

This does not make programming fundamentals irrelevant. It means the assessment environment should increasingly resemble the environment in which the candidate is expected to work.

4. The Emergence of the AI-Assisted Product Engineer

A useful way to understand this transition is through the concept of the product engineer.

A product engineer is not simply someone who implements a list of development tasks. They take responsibility for understanding a problem and delivering a solution that creates value for its intended users.

In an AI-assisted development environment, this responsibility becomes particularly important.

The engineer must be capable of moving between several interconnected activities:

1. Understanding the problem.
2. Identifying the actual requirements.
3. Translating requirements into clear instructions.
4. Guiding AI systems through implementation.
5. Reviewing and validating generated software.
6. Improving the solution through iteration.

This changes the distribution of effort throughout the development process.

Previously, a significant proportion of an engineer's time might have been spent translating an already-defined requirement into code.

Now, a growing proportion of that time can be spent determining what should be built and evaluating whether the AI-generated implementation is appropriate.

4.1 Problem identification and product sense

One of the most important competencies is the ability to understand an ambiguous problem.

Users frequently describe symptoms rather than underlying problems. They may request a particular feature because they believe it will solve an issue, even when a different approach would produce a better outcome.

A capable engineer should be able to investigate the request rather than immediately begin implementation.

For example, imagine a customer requesting a dashboard containing ten different performance indicators.

A task-oriented developer might immediately ask an AI agent to build the dashboard.

A product-oriented engineer would first investigate:

• Who will use the dashboard?
• What decisions should it help them make?
• Which indicators are actually relevant?
• Where does the underlying data originate?
• How frequently does the information need to be updated?
• Are there privacy or access-control requirements?
• What happens when information is missing or inconsistent?

The difference is fundamental.

The first approach focuses on implementing a requested feature. The second focuses on understanding the problem and designing an appropriate solution.

4.2 Systems thinking

AI can generate individual components, but successful software requires those components to operate together.

Engineers must understand how different parts of a system interact and how changes in one component affect the others.

This requires systems thinking.

A candidate should be able to reason about:

• Data dependencies and relationships.
• Application architecture.
• State management.
• Security boundaries.
• Error handling.
• Performance constraints.
• Failure scenarios.
• Long-term maintainability.

For example, an AI agent might generate a technically valid authentication implementation. However, an engineer must still determine whether it correctly handles session expiration, authorization boundaries, account recovery, and potential security vulnerabilities.

The ability to recognize these concerns is not replaced by AI-generated code.

It becomes part of the responsibility of the person directing and evaluating that code.

4.3 Written communication as an engineering competency

Natural language is becoming an increasingly important interface between engineers and AI systems.

The quality of an AI-generated implementation depends substantially on the context, constraints, and instructions provided to the model.

An engineer who cannot clearly explain a requirement may struggle to obtain a reliable implementation.

Written communication is therefore not merely a supplementary professional skill. It is increasingly part of the technical workflow.

This includes the ability to:

• Explain a problem precisely.
• Communicate functional and non-functional requirements.
• Describe expected system behavior.
• Identify constraints and assumptions.
• Document implementation decisions.
• Explain why a particular solution is appropriate.

Importantly, effective communication does not mean writing exceptionally long prompts. It means communicating the relevant information with sufficient precision and context.

5. A Different Approach to Hiring: Evaluate the Ability to Build, Not Just the Ability to Code

If traditional technical interviews are no longer sufficient, organizations need a more realistic way to assess engineering candidates.

One promising approach is to evaluate candidates through an AI-assisted product development exercise.

Rather than asking candidates to solve an isolated programming problem, organizations should provide them with a realistic but initially incomplete product scenario.

The candidate's responsibility would be to understand the problem, gather missing information, and build a working solution using an AI coding agent.

This approach evaluates the actual activities expected from modern engineers.

5.1 The proposed assessment environment

A structured assessment could contain three components:

Component A: An AI-powered customer

The candidate interacts with an AI model that simulates a customer or stakeholder.

The simulated customer has access to a detailed requirements document containing:

• The original business problem.
• Functional requirements.
• Business rules.
• Technical constraints.
• User expectations.
• Edge cases.
• Operational considerations.

However, this information is not immediately disclosed to the candidate.

Instead, the candidate must discover it through conversation.

The simulated customer responds to questions, provides additional information, clarifies assumptions, and offers feedback when presented with proposed solutions.

Component B: An AI development agent

The candidate receives access to another AI model that can generate software.

The candidate must communicate the discovered requirements to this agent and guide it toward a working implementation.

The development environment, AI model, available tools, and time constraints should be standardized across candidates.

Component C: An evaluation system

The resulting application is evaluated against the original requirements.

Automated testing can examine whether the implementation satisfies functional requirements, handles specified edge cases, and behaves correctly under different conditions.

A human evaluator then reviews the candidate's reasoning, decisions, and overall approach.

This creates an assessment that evaluates both the resulting software and the process used to produce it.

5.2 A practical example

Consider an organization hiring a junior engineer to develop a simple appointment management application.

The candidate receives a short initial description:

"Build an application that allows customers to schedule appointments with service providers."

This description is intentionally incomplete.

The candidate must investigate the requirements by interacting with the simulated customer.

During the conversation, they may discover that:

• Customers must be able to reschedule appointments.
• Providers have different working hours.
• Two customers cannot book the same time slot.
• Some appointments require advance payment.
• Customers should receive confirmation notifications.
• Administrators need the ability to cancel appointments.
• Certain providers offer services with different durations.
• Customers should not be able to access another customer's booking information.

These requirements fundamentally influence the architecture and implementation.

A candidate who immediately asks an AI agent to build an appointment application may produce something that looks convincing but fails to address important business rules.

A stronger candidate will spend time understanding the problem before committing to an implementation.

They may develop an initial version, demonstrate it to the simulated customer, receive feedback, and revise the solution accordingly.

They might even discard their initial implementation after discovering that the original architectural approach cannot accommodate an important requirement.

That willingness to reconsider an approach is an important indicator of engineering judgment.

5.3 Why the assessment should permit iteration

Real software development is iterative.

Requirements change, assumptions prove incorrect, and initial implementations frequently need revision.

An assessment should therefore allow candidates to:

• Ask questions throughout the exercise.
• Request additional clarification.
• Present incomplete implementations for feedback.
• Modify existing functionality.
• Change architectural decisions.
• Discard an approach and start again.
• Use AI assistance throughout the development process.

The objective is not to reward candidates for completing the first implementation as quickly as possible.

It is to understand how effectively they navigate an evolving problem.

A candidate who identifies a fundamental flaw and rebuilds the solution may demonstrate better engineering judgment than someone who completes an initially flawed implementation without reconsidering its assumptions.

6. What Should Actually Be Evaluated?

The proposed assessment requires a structured evaluation framework.

Simply checking whether the generated application works would be insufficient. AI systems can produce working implementations with relatively little candidate involvement.

The evaluation must therefore consider both the final result and the candidate's decision-making process.

The following competencies provide a useful starting point.

6.1 Requirements discovery

Can the candidate identify missing information and ask relevant questions?

This includes recognizing ambiguous requirements, discovering hidden constraints, and distinguishing between essential functionality and optional improvements.

A strong candidate does not assume that the initial description contains everything necessary to build the system.

6.2 Problem-solving and analytical reasoning

Can the candidate break down a complex problem into manageable components?

Can they identify dependencies, anticipate potential problems, and adapt when new information changes the original requirements?

This competency evaluates how candidates think rather than how quickly they produce an answer.

6.3 AI collaboration

Can the candidate effectively communicate with AI systems?

This should not be reduced to evaluating prompt-writing tricks.

A meaningful assessment considers whether the candidate can provide context, define constraints, review generated output, identify incorrect assumptions, and direct the AI agent toward a suitable solution.

The objective is to assess effective human-AI collaboration.

6.4 Technical judgment

Does the candidate understand the implementation well enough to evaluate its correctness?

Can they identify inappropriate architectural decisions, security weaknesses, data inconsistencies, and unnecessary complexity?

The candidate should be able to explain the generated implementation rather than simply demonstrate that an AI agent produced it.

6.5 Product thinking

Does the candidate understand the purpose of the software?

Can they distinguish between what a user requests and what the user actually needs?

Do they consider usability, business constraints, and the consequences of implementation decisions?

6.6 Communication and explanation

Can the candidate explain what they built, why they built it, and which trade-offs they considered?

Clear communication is essential when engineers collaborate with AI systems, stakeholders, and other members of a development team.

A candidate should be able to communicate both technical decisions and their reasoning.

6.7 Quality and completeness

Does the resulting application satisfy the requirements?

Does it handle edge cases? Is it usable? Does it behave consistently? Are important constraints respected?

Automated tests can provide objective evidence for many of these questions.

However, quality should not be measured exclusively by the number of completed features or the volume of generated code.

7. Standardization and Fairness in AI-Assisted Hiring

An important challenge with AI-assisted assessments is ensuring that candidates are evaluated under comparable conditions.

If one candidate receives access to a more capable model, additional development tools, or more detailed instructions, the assessment may measure access to resources rather than individual competence.

A standardized assessment should therefore define:

• The AI models available to candidates.
• The development environment.
• The available documentation and tools.
• The time allocated.
• The initial problem description.
• The simulated customer's underlying requirements.
• The evaluation criteria.

The same scenario should be presented consistently to all candidates.

This is particularly important when recruiting junior engineers, who may have significantly different levels of access to expensive AI tools and professional development environments.

7.1 Why educational credentials should not become the primary filter

Organizations frequently use university reputation, academic performance, and previous professional experience as shortcuts for evaluating candidates.

Although educational qualifications can provide useful information, they should not replace direct evidence of job-related competence.

A candidate's ability to build a useful system with AI assistance is not necessarily determined by the prestige of their university.

Likewise, a candidate who has not had access to expensive personal projects, professional networks, or extensive development resources should not automatically be considered less capable.

A practical, standardized assessment offers a potentially more direct way to evaluate individual ability.

It does not eliminate bias automatically, but it can reduce dependence on indirect indicators that are only loosely connected to actual job performance.

8. The Role of AI in Evaluating Candidates

AI can also contribute to the evaluation process.

For example, a separate evaluation agent could receive:

1. The original requirements document.
2. The completed application.
3. A collection of predefined test cases.
4. The candidate's development interaction history.
5. The candidate's written explanations.

The evaluation agent could then generate additional test cases, identify missing functionality, and report discrepancies between the requirements and implementation.

This would make it possible to evaluate relatively complex software projects without requiring human reviewers to manually inspect every individual feature.

However, automated evaluation should remain an assistive mechanism rather than the final authority.

8.1 Why human judgment remains necessary

AI evaluation systems can make mistakes.

They may overlook important implementation problems, reward superficial completeness, or produce inconsistent judgments.

They may also favor particular implementation styles or penalize reasonable alternative approaches.

For these reasons, automated evaluation should be calibrated against human judgment.

Human reviewers should retain responsibility for assessing:

• The quality of the candidate's reasoning.
• The relevance of their questions.
• The appropriateness of their technical decisions.
• Their understanding of the implementation.
• Their ability to recognize and correct mistakes.

Automated testing can establish whether specific requirements have been satisfied. Human evaluation is necessary to understand the quality of the decisions that produced the result.

The distinction is important: a system that works is evidence of implementation success, but it does not independently establish the candidate's engineering competence.

9. Learning From Other Professions: The Standardized Patient Model

Interestingly, this approach has similarities with established assessment practices in medical education.

Medical schools have used Objective Structured Clinical Examinations (OSCEs) for decades.

In these assessments, medical students interact with standardized patients, usually trained individuals who simulate particular medical conditions and respond consistently to questions.

Students are evaluated on their ability to gather information, ask relevant questions, interpret symptoms, and determine appropriate next steps.

The assessment does not simply test whether students have memorized medical knowledge.

It evaluates how effectively they apply that knowledge in a simulated professional situation.

The underlying principle is highly relevant to software engineering.

A simulated customer could play a role similar to a standardized patient.

Instead of identifying symptoms, the candidate identifies product requirements. Instead of developing a treatment plan, the candidate develops a software solution.

Both assessments evaluate the ability to investigate an initially incomplete problem, obtain relevant information, and make appropriate decisions.

This provides an established conceptual foundation for developing more realistic software engineering interviews.

10. Why Internships Alone Cannot Solve the Problem

Another possible response to the decline in junior recruitment is to expand internship programs.

Internships provide valuable opportunities to observe candidates in real working environments.

They allow organizations to evaluate performance over time rather than relying on a short interview.

However, internships are not a complete solution.

They require significant resources, supervision, time, and organizational commitment.

Large technology companies may be able to recruit hundreds of interns and establish dedicated programs around them. Smaller organizations and startups generally do not have the same capacity.

Furthermore, internships do not eliminate the need for better candidate selection.

An organization still needs to determine which candidates should receive an opportunity in the first place.

A more effective assessment process could complement internships by identifying promising candidates before organizations commit substantial resources to long-term training.

11. Implications for Universities and Engineering Education

The changing nature of engineering recruitment also has significant implications for universities and educational institutions.

Computer science education should not abandon programming fundamentals, algorithms, data structures, mathematics, or computer systems.

These subjects provide the conceptual foundation necessary to understand software and evaluate technical decisions.

However, educational institutions should reconsider how these subjects are connected to practical engineering work.

Students should increasingly be exposed to environments where AI is part of the development process.

This includes learning how to:

• Translate ambiguous problems into technical requirements.
• Design software systems before implementation.
• Work effectively with AI coding agents.
• Review and validate AI-generated code.
• Understand system architecture and dependencies.
• Identify security and reliability issues.
• Test software against real requirements.
• Explain technical decisions and trade-offs.

The objective should not be to produce graduates who can merely operate AI coding tools.

It should be to produce engineers who understand the systems they build and can take responsibility for their outcomes.

11.1 The importance of fundamentals

There is a risk of interpreting the rise of AI-assisted development as evidence that traditional computer science knowledge is no longer necessary.

This would be a mistake.

Without understanding programming, databases, networking, operating systems, algorithms, and software architecture, developers may struggle to recognize when AI-generated solutions are incorrect.

The ability to generate software and the ability to understand software are different competencies.

AI can reduce the effort required to implement a solution, but it does not automatically provide the human operator with the knowledge necessary to determine whether that solution is appropriate.

The future engineer therefore needs both foundational technical understanding and the ability to work effectively with increasingly capable AI systems.

12. A New Definition of Engineering Potential

Perhaps the most significant implication of this transition is that organizations need to reconsider what they mean when they describe someone as a promising junior engineer.

Historically, engineering potential was frequently inferred from academic performance, programming proficiency, algorithmic problem-solving, and previous technical experience.

These indicators are not necessarily meaningless, but they are incomplete.

In an AI-assisted development environment, engineering potential may be better understood through a combination of competencies:

• Curiosity to investigate unfamiliar problems.
• Analytical ability to understand complex situations.
• Judgment to identify appropriate solutions.
• Technical understanding to evaluate implementations.
• Communication skills to express requirements clearly.
• Adaptability to revise assumptions and approaches.
• Responsibility for the quality and consequences of the resulting system.

These capabilities are not entirely new. Excellent engineers have always needed them.

What has changed is their relative importance in the development process.

As AI increasingly handles implementation tasks, the ability to define, direct, understand, and evaluate those implementations becomes a more significant differentiator.

13. Conclusion: We Need to Change How We Recognize Engineers

Artificial intelligence is not simply making software development faster. It is changing the relationship between human reasoning and software implementation.

The traditional hiring model was built around a development environment in which writing code was a central activity. Modern AI-assisted development increasingly places problem understanding, system thinking, communication, and technical judgment at the center of the engineering process.

Continuing to evaluate junior engineers exclusively through traditional coding interviews risks selecting candidates for a version of the profession that is rapidly changing.

The industry needs a more realistic approach.

Instead of asking candidates to solve isolated programming problems, organizations should consider giving them real-world product scenarios, access to standardized AI tools, and the opportunity to demonstrate how they investigate requirements, guide implementation, and evaluate the resulting software.

Such an approach would not eliminate the need for technical knowledge or programming fundamentals. It would place those competencies in the context of the work engineers are increasingly expected to perform.

More importantly, it could help organizations identify capable junior engineers who might otherwise be overlooked by traditional recruitment methods.

The future of software engineering should not become a profession reserved exclusively for people who already have years of experience.

If AI changes how software is built, hiring must evolve alongside it. Otherwise, the industry risks creating a future in which organizations expect experienced engineers but no longer provide enough opportunities for new engineers to become one.

We do not just need a better way to write software. We need a better way to recognize the people capable of engineering it.

---

AI Engineering Fundamentals (Free to enroll)

Start building with language models: understand tokens and costs, design and test prompts, get validated JSON output, handle errors and safety risks, and finish with a guided document assistant project.

Machine Learning Fundamentals (Free to enroll)

Comprehensive Machine Learning Fundamentals (with Python) certification program covering core algorithms, data preparation, predictive modeling, model validation, performance optimization, and real-world machine learning applications.

Python Programming Fundamentals (Free to enroll)

Learn Python from zero in your browser, no installation needed, covering variables, decisions, loops, collections, functions, files, JSON and error handling, finishing with a real project that cleans a messy expense export into a trusted report.

---

References and Further Reading

1. Laurie Voss. A Proposal: How to Hire Junior Engineers in the Age of AI. The original proposal that motivates this discussion.

2. Laurie Voss. We Are All Product Engineers Now. Related discussion on how AI-assisted development is changing the responsibilities of software engineers.

3. Stanford Digital Economy Lab. Canaries in the Coal Mine? Research examining the effects of generative AI on early-career employment.

4. Objective Structured Clinical Examination (OSCE). Medical education assessment methodology based on standardized patient interactions and structured evaluation.

Note: The AI-assisted hiring framework discussed in this article is a proposed assessment approach. Its effectiveness, predictive validity, and fairness should be established through controlled trials and comparison with subsequent job performance.