Why the Programming Tutor Profile Matters More in 2026 Than Ever
The programming instructor of 2020 is not the programming instructor of 2026. Five years ago, a strong Python or JavaScript teacher could carry an entire cohort with syntax walkthroughs, algorithm drills, and a few whiteboard sessions on design patterns. Today that same instructor would be considered underqualified for a serious cohort at Refonte Learning. The reason is simple: the modern software engineer is expected to ship code that lives inside a generative-AI-augmented workflow, deploy to distributed cloud infrastructure on day one, and integrate observability, security scanning, and cost governance into the same pull request. Teaching that stack requires a very different tutor profile.
When we describe a Refonte Learning programming tutor in 2026, we are describing a working practitioner. Not a career educator. Not someone who left engineering a decade ago to run bootcamps full-time. The people who lead our live sessions on backend systems, full-stack development, Python, TypeScript, Go, Rust, and language-agnostic software design are, in the majority, engineers who still commit code to production systems each week at product companies, consultancies, or their own startups. Teaching is a second craft they hold alongside the first, and the two reinforce each other.
This child article, part of the Refonte domain expert tutors pillar, zooms into the specific profile of the programming vertical. If you have read the sibling profiles for AI engineering, cloud, or DevOps, you will notice both similarities and important differences. Programming tutors sit at the foundation. Almost every other track (AI, cloud, data, DevOps) builds on top of code, so our programming tutors carry a distinct responsibility: they set the coding culture, the review standards, and the mental habits that students will bring into every other course.
We wrote this profile for three audiences. First, prospective students who want to know exactly who will be on the other end of the camera during live sessions. Second, hiring managers evaluating whether a Refonte graduate has been mentored by real engineers. Third, senior engineers curious about joining our tutor bench who want to understand the bar. Across all three audiences the message is consistent: at Refonte Learning we treat teaching as a technical discipline in itself, and we hire, prepare, and support programming tutors accordingly.
The sections that follow break down the profile in depth: the technical background we look for, the pedagogical training we require, the domains our programming tutors specialise in, the review and feedback culture they carry, the tools they use during sessions, the tradeoffs of hiring practitioner-tutors versus career educators, common failure modes we watch for, and how the profile continues to evolve as the industry changes. By the end you should have a concrete mental model of what it means to be, or to learn from, a Refonte programming tutor.
The Baseline: Seven Years of Shipping Real Code
The first filter for any programming tutor at Refonte Learning is production experience. Our baseline is seven years of shipping code into systems that had real users, real revenue, or real regulatory consequences. We phrase it that way deliberately. Years-in-title inflation is rampant in the industry, and a resume that says "Senior Software Engineer, 8 years" means very little on its own. What we look for underneath the title is evidence of ownership: features shipped end to end, incidents diagnosed at 2am, migrations run against live databases, deprecations negotiated with downstream consumers, and postmortems written and shared.
Seven years is not an arbitrary number. It is the point at which most engineers have lived through at least one full product cycle: greenfield build, scaling pains, technical debt reckoning, and either a rewrite or a graceful evolution. Tutors who have not been through that arc tend to teach a naive version of software engineering, one where the codebase is always young and every architectural decision is fresh. Students trained by that kind of instructor struggle badly when they enter real teams that are working inside ten-year-old monoliths.
Within that seven-year baseline, we look for breadth across at least two paradigms. A tutor whose entire career has been one language and one framework, no matter how deep, will teach students to think inside that box. Our strongest programming tutors have worked across at least two of: object-oriented systems in Java or C#, dynamic scripting in Python or Ruby, statically typed functional-leaning code in TypeScript or Kotlin, and systems programming in Go or Rust. That breadth translates directly into the classroom, where students inevitably ask "why not use language X instead" and deserve a real answer rather than dogma.
We also require current relevance. A tutor who last shipped production code in 2019 does not qualify, regardless of how impressive that pre-2019 career was. The programming world has changed too much in the intervening years: containerised local development is table stakes, LLM-assisted coding has reshaped the pull request workflow, observability tooling has consolidated around OpenTelemetry, and package ecosystems have matured or fragmented in ways only current practitioners fully feel. Recency of practice is non-negotiable.
Finally, we look for evidence of technical writing and communication outside the classroom. A blog with careful architectural writeups. A conference talk. A meaningful open-source contribution with a substantive PR discussion attached. Internal documentation that other engineers actually read. This external signal matters because it demonstrates the tutor already thinks about explaining ideas to others in structured written form, which is more than half the job of teaching.
Pedagogical Training Layered on Technical Depth
Technical depth alone does not make a good tutor. Some of the best engineers we have ever worked with would be poor teachers, because their intuition is so internalised they cannot decompose it for a learner. To bridge that gap, every Refonte Learning programming tutor goes through a structured pedagogical onboarding before they are allowed to lead a live cohort session, following our tutor preparation standards closely.
Onboarding starts with cognitive load theory. New tutors read a compact internal briefing on how working memory limits determine what a student can absorb in a single session, then they redesign one of their own past teaching artifacts under those constraints. This exercise is deliberately uncomfortable. Most senior engineers write documentation and give talks assuming an audience roughly like themselves. Teaching in a cohort means designing for someone who does not yet have the mental scaffolding to hang new concepts on, and cognitive load theory gives tutors a vocabulary for that shift.
Next comes worked-example pedagogy. Programming is notoriously hard to teach because the gap between reading code and writing code is enormous. Modern research on programming education, going back to the work of Sweller and van Merrienboer, consistently shows that worked examples with fading scaffolding outperform pure problem-solving for novices. Our tutors are trained to structure sessions around annotated worked examples first, then partially completed examples, then blank-page problems. This progression is baked into how we design live sessions and asynchronous exercises.
The third pillar is deliberate practice design. Our tutors learn to distinguish between practice that feels productive (typing along with the instructor) and practice that actually builds transferable skill (retrieval, spaced repetition, interleaved problem types, and immediate corrective feedback). They design lab exercises accordingly, and they resist the very common temptation to make live sessions into demo shows. A Refonte programming session should leave students exhausted from thinking, not entertained by watching.
We also train tutors in what we internally call "question triage." In any live session, students will ask questions at wildly different levels: some are foundational misunderstandings, some are advanced edge cases, some are off-topic curiosities. A skilled tutor learns to categorise questions in real time and decide which to answer immediately, which to defer to office hours, and which to redirect to the cohort chat for peer discussion. This skill takes months to develop and we support it with session recordings and structured debrief conversations.
Finally, tutors practise on internal pilot sessions before they ever touch a paying cohort. A senior tutor observes, gives detailed written feedback, and signs off (or does not) on readiness. This apprenticeship model, described in more depth in how Refonte selects tutors, mentors, and trainers, is one of the reasons our tutor quality remains consistent even as we scale.
Specialisation Tracks Within Programming
"Programming tutor" is too broad a title to be useful. Inside the Refonte Learning programming bench we maintain distinct specialisation tracks, and we match tutors to cohorts based on those tracks rather than treating them as interchangeable. This matters because a great backend Go engineer is not automatically a great React instructor, and pretending otherwise leads to sessions where the tutor is a half-step ahead of the students, which is exactly where teaching quality collapses.
Our main specialisation tracks include backend systems, full-stack web, Python for engineering, systems and low-level programming, mobile development, and language-agnostic software design and architecture. Each track has its own set of core competencies, its own preferred exercise progression, and its own set of reference tutors who define the bar for that track. When we recruit a new tutor we always fit them to a primary track and, ideally, a secondary track for cross-coverage.
The backend systems track focuses on API design, database modelling, transactional integrity, caching strategy, background job architecture, and inter-service communication patterns. Tutors on this track are expected to be fluent with at least one of Postgres, MySQL, or a comparable relational engine at the query-optimiser level, not just the ORM level. They should have opinions on eventual consistency, on when to reach for a message broker, and on the operational cost of microservices versus modular monoliths.
The full-stack web track requires fluency across the modern JavaScript and TypeScript ecosystem: React or a comparable framework, server-side rendering patterns, edge deployment models, browser performance budgets, and accessibility fundamentals. We deliberately require accessibility as a first-class competency for full-stack tutors, because it is one of the most consistently underserved areas in bootcamp curricula and one of the most consistently demanded in real hiring rubrics.
The Python for engineering track (distinct from Python for data science, which lives in the AI and data pillars) covers packaging, dependency management with modern tools like uv or Poetry, async patterns with asyncio, type checking with mypy or pyright, and production concerns like structured logging and profiling. Tutors on this track often have background in DevOps tooling or platform engineering, which is why we cross-reference the programming pillar overview when advising students on which cohort to join.
Cross-cutting all tracks is our architecture and software design specialisation. A subset of our senior tutors focus specifically on teaching the discipline of designing systems: decomposing requirements, choosing boundaries, managing coupling, and reasoning about tradeoffs. These tutors often lead capstone reviews and design interviews, and they are the ones we lean on when a student needs to level up from "can write features" to "can own a service."
The Code Review Culture Programming Tutors Set
One of the most underrated parts of a programming tutor's job at Refonte Learning is code review. Every serious cohort involves students submitting pull requests against exercise repositories, capstone codebases, or their own project repos, and every PR gets reviewed by a tutor. This is not a light touch review. Our internal standard is that a tutor review should read like a review from a thoughtful senior engineer on a real team: substantive, specific, prioritised, and respectful.
We train tutors to structure reviews in a specific order. First, correctness: does the code do what it claims to do, and are there tests that prove it. Second, safety: are there security, concurrency, or data-integrity issues that would cause harm in production. Third, design: is the code shaped in a way that a future maintainer will find reasonable. Fourth, style and idiom: is the code written the way an experienced practitioner of this language would write it. Fifth, teaching moments: are there opportunities to introduce a concept the student has not yet met but would benefit from.
This ordering matters. New tutors, especially those with a perfectionist streak, tend to lead with style nits and buried the important structural feedback at the bottom. Students then fix the nits, feel productive, and never internalise the deeper lesson. We coach against this pattern explicitly during onboarding, and we spot-check reviews as part of ongoing quality assurance.
We also require tutors to distinguish between blocking feedback and suggestions. On a real engineering team, some review comments must be addressed before merge and some are optional improvements. Learning to make that distinction is part of learning to work in industry, so we mirror it in our reviews. Tutors use explicit markers ("blocking", "suggestion", "nit", "optional") so students learn to read reviews like a working engineer, not like a graded assignment.
The code review culture flows directly into our broader tutor feedback loop with students, which formalises how written PR feedback, live session interactions, and one-to-one mentoring conversations reinforce each other. Students who complete a Refonte programming track have typically received several hundred substantive code review comments across the cohort, which is arguably the single largest quality differentiator between our graduates and self-taught developers who have never had their code seriously reviewed.
Finally, tutors are expected to model receiving feedback as well as giving it. When a student pushes back on a review comment with a reasonable argument, the tutor is expected to engage with the argument, and to change their mind publicly when the student is right. This modelling matters enormously. It teaches students that code review is a technical conversation between peers, not a verdict handed down from above, which is exactly the mindset they need to succeed in real engineering teams.
The Tooling Fluency We Require
A programming tutor in 2026 needs to be fluent with a specific set of tools that were not universal even three years ago. We do not treat this as optional. Sessions where the tutor fumbles with the toolchain destroy student confidence and waste session time, and students trained by tutors who avoid modern tooling arrive in the workforce with a visible gap.
On the AI-assisted development side, our tutors are expected to be genuinely fluent with at least one of the current generation of coding assistants: GitHub Copilot, Cursor, Claude Code, or comparable. Fluent does not mean "has installed it." It means the tutor has integrated the assistant into their own workflow, has strong opinions on when it helps and when it misleads, and can teach students to use it critically rather than as a crutch. We spend meaningful session time on prompt patterns for code generation, on how to review AI-generated code, and on the specific failure modes of AI assistants around security and edge cases.
On the environment side, tutors must be comfortable with container-based local development using Docker or its alternatives, with devcontainers or GitHub Codespaces for reproducible student environments, and with the specifics of their language's modern package management. For Python that means uv or Poetry rather than raw pip and virtualenv. For JavaScript that means pnpm or bun in addition to npm. For Go and Rust it means cargo and go modules used at a level beyond the tutorial defaults.
On the version control side, we require far more than "can use git." Our tutors teach interactive rebase, cherry-pick, bisect for debugging, and the mechanics of a good pull request narrative. They also teach the pull request as a communication artifact, not just a code delivery mechanism. Writing a good PR description is a professional skill, and our tutors model it in every exercise repository they contribute to.
On the testing side, tutors are fluent with the modern test frameworks in their track (pytest, vitest, jest, go test, cargo test, and so on), with property-based testing where appropriate, with contract testing for services, and with the discipline of writing tests before or alongside code. They also teach students to distinguish between unit, integration, and end-to-end tests and to make reasoned choices about the mix.
On the observability side, we expect tutors to be comfortable with structured logging, distributed tracing via OpenTelemetry, and basic performance profiling. Even in an introductory backend course, students should leave with a working intuition for how to observe a running system, because debugging in production is a first-class skill and one that traditional curricula ignore.
This tooling fluency is one of the reasons we point students toward the AI Engineering program when their interests bridge programming and AI: the tutor bench there specifically integrates AI-assisted development as a curriculum topic rather than an afterthought.
Tradeoffs: Practitioner-Tutors vs Career Educators
Every tutor hiring philosophy involves tradeoffs, and we want to be honest about ours. Refonte Learning has deliberately built a bench of practitioner-tutors, people whose primary identity is still working engineer and whose teaching is a serious secondary craft. This choice comes with real costs alongside its benefits, and we manage those costs actively.
The biggest benefit is currency. A tutor who is actively debugging a production incident this month brings that fresh context into next week's session on error handling. A tutor who last worked on a real system three years ago cannot. Students consistently rate this currency as one of the most valuable things they get from Refonte cohorts, especially when they compare notes with peers who trained at institutions dominated by career educators.
The second benefit is credibility. When a tutor can say "here is how we handled this exact tradeoff at my company last quarter," students engage differently than they do with a textbook example. This is not just motivational. It transfers real judgment, the kind of soft knowledge about when to break a rule that only comes from being in the room where rules are broken.
The first cost is scheduling friction. Practitioner-tutors have day jobs that occasionally intrude. We manage this with generous lead-time expectations, clear substitution protocols, and a bench deep enough that any single tutor's unavailability can be covered. Our session cancellation policies exist precisely to make this manageable without disrupting students.
The second cost is teaching skill variance. A career educator has, by definition, spent more hours refining pedagogy. Some practitioner-tutors take years to reach the same fluency in explanation. We compensate with the structured pedagogical onboarding described earlier and with ongoing peer observation. But we accept that our newest tutors will be technically stronger than they are pedagogically polished, and we assign them accordingly, often starting them in code review and office hours before live sessions.
The third cost is content freshness maintenance. Because our tutors are not primarily educators, they do not naturally spend their weekends updating course materials. We solve this with a dedicated curriculum team that maintains the shared assets and with an explicit expectation that tutors flag outdated material rather than either working around it or updating it themselves at random. This division of labour keeps materials consistent across cohorts while preserving tutors' time for what they are best at: teaching live and reviewing code.
The fourth cost is that practitioner-tutors sometimes struggle with true beginners. An engineer with fifteen years of experience has often forgotten what it feels like to not understand a for-loop. We address this by not asking senior practitioners to teach absolute beginners. That work goes to a different tier of instructors, often earlier-career engineers who are closer to their own learning journey and who can meet novices where they actually are.
Common Failure Modes We Actively Watch For
Because we take teaching seriously as a craft, we also take failure modes seriously. Over years of running programming cohorts, we have identified a specific set of tutor failure patterns and built process around detecting and correcting them. Being explicit about these helps prospective students understand what quality looks like, and helps tutors self-diagnose before problems compound.
The first failure mode is what we call the "demo trap." A skilled engineer, given a live audience, naturally wants to show them the exciting parts: the elegant solution, the impressive refactor, the clever library. But watching an expert code is not learning to code. Students leave demo-heavy sessions entertained and confident, then discover they cannot reproduce anything on their own. We counter this by requiring that every live session include substantial hands-on segments where students code and the tutor watches, not the other way around.
The second failure mode is the "depth spiral." An enthusiastic tutor answers a student question by going three levels deeper than the question required, dragging the whole cohort into territory they were not prepared for. This is especially common with senior tutors who genuinely love the depth. We coach tutors to answer at the level of the question and offer the deeper rabbit hole as an optional followup, either in office hours or in linked reading.
The third failure mode is "consulting mode." Some tutors, particularly those from consultancy backgrounds, unconsciously slip into diagnosing student code rather than teaching students to diagnose their own code. The student gets their bug fixed but does not learn to debug. We watch for this in review patterns and in office hour recordings, and we coach tutors toward Socratic patterns where the student is walked through the diagnostic process.
The fourth failure mode is inconsistency in feedback standards across tutors on the same cohort. If Tutor A merges a PR that Tutor B would have requested changes on, students learn to game the system rather than internalise real quality bars. We address this with shared review rubrics per module and with periodic calibration sessions where tutors review the same anonymised student submission and compare notes.
The fifth failure mode is the "one true way" tutor. A tutor with strong opinions about, say, functional versus object-oriented style, or REST versus GraphQL, can subtly indoctrinate a cohort against making their own judgments. We value strong opinions, but we require tutors to present alternatives fairly and to teach the reasoning frameworks that let students choose for themselves in future roles.
The sixth failure mode is disengagement drift. Even excellent tutors can slowly drift toward autopilot on their fifth or sixth cohort teaching the same material. We rotate assignments, refresh curriculum meaningfully each cycle, and pair drifting tutors with newer ones for mutual re-energising. Sustained enthusiasm is part of the job, and we treat it as a measurable quality signal.
How the Profile Connects to Other Refonte Tutor Tracks
Programming tutors do not work in isolation. They sit inside a broader ecosystem of specialised tutor benches at Refonte Learning, and understanding those connections helps clarify what the programming profile is and is not. Students who are choosing between tracks, or considering a cross-track path, benefit from seeing how the profiles differ.
Compared to the Refonte AI engineering tutors profile, programming tutors go deeper on general-purpose software engineering fundamentals and lighter on model architecture, evaluation, and MLOps. An AI engineering tutor is expected to reason about vector databases, retrieval augmentation, and fine-tuning tradeoffs at a level programming tutors are not required to reach. Conversely, programming tutors go deeper on code review discipline, general-purpose language idioms, and non-AI backend patterns. Students often benefit from cross-exposure, and we build joint sessions where appropriate.
Compared to the Refonte cloud tutors profile, programming tutors know enough cloud to deploy student projects reliably but do not carry the deep AWS, GCP, or Azure certification-level knowledge that cloud tutors do. Cloud tutors focus on infrastructure as code, networking, IAM, and multi-region architectures. Programming tutors focus on the application-layer code that eventually gets deployed onto that infrastructure. When students want to specialise in platform work, we move them toward the cloud track and the corresponding tutor bench.
Compared to the Refonte DevOps tutors profile, programming tutors handle CI/CD basics and container fundamentals but are not expected to be experts in Kubernetes operators, GitOps at scale, or observability platform engineering. DevOps tutors bring that depth. Again, we build cross-track pathways for students who want to add operational depth to their programming skills, because the modern full-stack engineer benefits enormously from real exposure to how their code runs in production.
Across all these tracks, the underlying philosophy is shared. Every Refonte Learning tutor track privileges recent practitioner experience, structured pedagogical training, substantive code and artifact review, and a code of conduct that treats students as future colleagues rather than customers to be entertained. The profiles differ in surface area but not in seriousness.
We also share process between benches. The same recruiting funnel, the same onboarding curriculum for pedagogy, the same feedback loop mechanics with students, and the same session policies apply across programming, AI, cloud, and DevOps. This shared spine is what lets students move between tracks without experiencing a jarring shift in teaching culture. It is also what lets tutors move between adjacent tracks over time as their own careers evolve.
How the Profile Is Evolving Through 2026 and Beyond
The programming tutor profile is not static. Every year we revisit what a competent programming instructor at Refonte Learning needs to know, and every year the answer shifts. Being explicit about the direction of that shift helps prospective tutors self-assess and helps students understand the trajectory of their education.
The most significant recent shift is around AI-assisted development. As recently as 2023, we treated coding assistants as an optional add-on. By 2025 they were mandatory tooling. In 2026 we are pushing further: our tutors are expected not just to use AI assistants but to teach the meta-skill of directing them, verifying their output, and knowing when to override them. This includes teaching students to write code review comments on AI-generated pull requests, which is rapidly becoming a core professional skill.
A second shift is around type systems and static analysis. The line between dynamically typed and statically typed languages has blurred significantly. TypeScript is now the default for serious JavaScript work. Python has embraced gradual typing to the point where untyped new code is considered a smell in most professional settings. Our tutors are expected to teach type-driven design across languages, not treat it as a niche concern. This shift has raised our hiring bar meaningfully for the Python track in particular.
A third shift is around security as a mainstream concern for application developers. The old model, where security was a specialist team that swept in late, has collapsed. Every developer is now expected to reason about supply chain risk (Trivy scans, dependency provenance), about authentication and authorisation patterns, and about the specific classes of vulnerability common to their stack. Our programming tutors carry more security responsibility in their curricula than they did three years ago, and we hire for this now explicitly.
A fourth shift is around asynchronous and concurrent programming as a default rather than an advanced topic. Modern applications, driven by streaming AI responses, real-time collaboration, and event-driven architectures, expect developers to reason about concurrency early. Our tutors introduce async patterns earlier in curricula than they used to, and we favour candidates with real concurrency experience across at least one language.
A fifth shift is around durability of skill in the face of tooling churn. The pace of framework and library change has been aggressive. Our tutors are increasingly evaluated on their ability to teach durable underlying concepts (HTTP semantics, database transactions, memory models, network topology) rather than the current-flavour framework. A student who deeply understands what a React server component is doing can migrate to whatever comes after React. A student who only knows the current syntax cannot.
We expect further evolution through 2027 and beyond. As agentic development environments mature, the role of the human developer will shift more toward specification, review, and system design. Our tutor profile will shift with it, and we will continue to publish updates to this profile as the industry moves.
Working With Refonte Programming Tutors: What Students Actually Experience
Profiles and philosophies matter, but what matters most to a prospective student is the day-to-day experience of learning under a Refonte programming tutor. Here is what that actually looks like, week by week, inside a typical cohort.
Each week opens with a live session, usually two to three hours, led by the primary tutor. The session mixes concept introduction, worked examples, hands-on coding segments, and open Q&A. Students are expected to have completed pre-work before the session, and the tutor calibrates the depth based on the cohort's pre-session assessment results. Sessions are recorded, so students who miss live or want to review can return to them, subject to our recording policy.
Between sessions, students work through structured exercises in a shared repository. Each exercise is submitted as a pull request against their fork, and every PR gets a substantive tutor review within a target turnaround window. Reviews are the workhorse of learning. Most students report that they learn more from the accumulated review comments than from the live sessions, which is exactly the ratio we design for.
Office hours run multiple times per week, staffed by rotating tutors from the cohort's bench. Students bring specific stuck points, debugging challenges, or design questions. Office hours are deliberately Socratic. Tutors guide students to their own answers rather than handing over fixes. This is often the moment when a student's intuition really develops, because they experience diagnosing their own code with expert supervision.
Capstone projects, typically in the second half of a cohort, involve tighter one-to-one mentoring. Each student is paired with a senior tutor for architectural reviews, mid-project checkpoints, and a final defence. The capstone is where the accumulated skills come together, and where the practitioner-tutor profile pays off most obviously: students get feedback on their project that resembles feedback they would get from a senior colleague in a real workplace.
Across all of this, the tutor is expected to be a mentor as well as an instructor. Career questions, technical direction questions, and "should I take this job offer" questions all come up, and tutors are expected to engage seriously with them. The relationship is not just transactional. Many Refonte Learning graduates stay in contact with their tutors for years, which is one of the strongest signals we have that the profile is working.
About Refonte Learning and Next Steps
Refonte Learning is an EdTech platform built by practitioners for practitioners. We operate cohort-based programs across programming, AI engineering, cloud, DevOps, and data, all staffed by tutors who meet the profile described in this article and its sibling pieces in the domain expert tutors pillar. Our corporate parent, Refonte Infini Infiniment Grand (SIREN 949 841 605, verifiable on the French INPI registry), operates a French SAS with an operational office at 1 Poulton Close, Dover, Kent, United Kingdom, CT17 0HL.
If you are a prospective student, the best next step is to read the specific program page for the track you are considering and to attend one of the open information sessions where you can meet current tutors in person. If your interests bridge programming and AI, take a closer look at our AI Engineering program, where the programming tutor bench and the AI engineering tutor bench work jointly on curriculum.
If you are a senior engineer considering joining our tutor bench, the profile above is your self-assessment checklist. Reach out through the tutor recruiting channel on our site. We are always looking for practitioners who take teaching seriously as a second craft.
And if you are a hiring manager evaluating a Refonte graduate, we invite you to ask them what their PR review experience looked like, how many substantive review comments they received across their cohort, and what their tutor's professional background was. The answers will tell you a great deal about the quality of the training they received.