Software Engineer

Pearson Virtual Schools serves K-12 students and their teachers on Connexus, a large-scale student, curriculum, and assessment data platform. Engineering Leads sit a layer above the delivery teams, spanning two or three of them and in most cases aligned to a single initiative. You are the engineering voice for those teams and the bridge between them and everyone who needs something from them. 

We are modernizing a platform that today runs primarily on legacy .NET Frameworks: IIS-based ASP.NET WebForms and MVC, an AngularJS and jQuery front end, and SQL Server. The future is design-system-based React and TypeScript single-page applications calling .NET REST services that operate in containerized modern .NET, and integrate with an API-first, event-driven model on AWS with externalized authorization. Your teams will work on both sides of this technology, the legacy and the new. 

Each team is built to a deliberately lean shape, with a dedicated engineer in test. That shape only works if the engineers stay focused on building, which means the work that would otherwise interrupt them lands with you. Release requests, the platform service tickets your teams depend on and the follow-up on them, engagement with Architecture, UX, Security, and Product, and representation in discovery all sit with the Engineering Lead. This is not a coding-primary role, and it is not a step out of engineering either. You need the depth to hold the cross-team technical view and the credibility to be believed when you use it. 

You are expected to be AI-native in how you work. That means building and operating agents, authoring reusable skills and machine-readable knowledge that others retrieve, and taking the conductor role on agentic generation batches that span your teams, where the review that matters happens at the seams rather than line by line. 

Key Responsibilities 

The Bridge to Product and Discovery 

• Represent your teams in four-in-a-box discovery, and bring back a shaped problem rather than a list of asks 

• Serve as the engineering bridge to Product, so a question about feasibility gets an answer from someone accountable for the build 

• Partner with the technical delivery manager to prioritize and sequence work across your teams 

• Speak for the teams in the forums they cannot all attend, and carry the decision back accurately 

Cross-Team Technical Coherence 

• Hold the technical view across your teams, and own the interfaces and contracts between them 

• Detect and correct architectural drift while it is still a code review rather than a migration