Teaching Statements and Portfolios

If you are heading toward an academic job, especially at a teaching-focused college or in a teaching-track faculty role, you will be asked for a teaching statement, and possibly a teaching portfolio. In a study of 457 search committee chairs, 57% asked for a teaching statement at some point in their search, and a later study found it is the teaching document committees use most. The good news is that your TA work is the raw material. This page covers what a statement is for, how to structure one, the mistakes committees see most, and how to build a portfolio as you go, so you are not starting from nothing the fall you go on the market.

Defaults that work. If you only take four things from this page:

Show, don't declare. Two or three specific moments from your teaching beat any statement of passion.
Connect goals, methods and evidence: what you want students to learn, what you do about it, and how you know it worked.
Write about computing, in terms a CS committee recognizes: debugging, testing, decomposition, not generic "critical thinking."
Start the portfolio now. Save materials, get observed, and collect midsemester feedback while you TA.

What a teaching statement is for

A committee reads it to picture you teaching: what a class with you would be like, and whether you will be a thoughtful, effective colleague. It is usually one to two pages, in the first person. Check every job ad: some departments ask for up to three pages, and some ask for a separate statement on diversity, community or mentoring. How much it matters varies: at research universities it is often read quickly; at teaching-focused colleges and in teaching-track searches it carries real weight, often alongside a teaching demonstration.

A structure that works

An opening idea, about how students learn computing, tied to a real moment from your teaching.
Your goals: what students should be able to do, beyond knowing the content. Debug, decompose a problem, test, work in a team, weigh trade-offs.
Your methods, with examples: two or three episodes, each linking a goal, what you did, and why it fits computing.
Evidence: how you know it worked. Your assessments, feedback, and what you changed because of it.
Inclusion, throughout: concrete practices woven into the examples, not a separate paragraph of values.
Growth and fit: what you are working on next, and which courses you could teach or create in this department.

Weak and better

Weak	Better
I am passionate about teaching and believe every student can learn.	In intro programming office hours, I noticed most students stuck on recursion had never traced a call by hand, so I began opening each session with a five-minute stack-trace drawing.
I use active learning to engage students.	In my 40-person discussion section, students predict the output of a short program, vote, then debug in pairs. The wrong predictions show me which misconception to address next.
I value diversity and create an inclusive classroom.	I post worked examples of each lab before the deadline and rotate pair-programming roles, so students who arrive without prior coding experience aren't quietly sidelined by those who have it.
My evaluations were very positive.	Midsemester feedback showed students couldn't tell what the autograder checked, so I published the test descriptions. End-of-term comments about unclear expectations dropped from frequent to rare.

The better versions are invented examples; use your own real moments and numbers.

Mistakes committees see most

Platitudes with no examples: "passionate," "student-centered," "lifelong learners."
Methods with no reasons: listing techniques without saying what they are for.
No evidence that anything worked, and no sign you changed anything because of it.
Generic language that could come from any field.
Teaching as a chore, something done to fund research. Committees notice.
One statement for every job. Keep your core ideas, but tailor examples and courses to each institution.

If you have little teaching experience

Use what you have: office hours, labs, grading, tutoring, mentoring undergraduates in research, and what you learned as a student from the teachers who helped you. One well-observed moment from a single office hour is better than a broad claim about a course you didn't run.

Get feedback on it

Treat it like a paper. Ask faculty who have sat on search committees, and recent graduates now teaching elsewhere, to read it. A published rubric (in the reading list) rates statements on goals, methods, assessment, inclusive environment, and structure; use it to check your own draft.

The teaching portfolio

Committees rarely ask for a full portfolio, but building one gives you the evidence for your statement, material for interviews, and what teaching-track applications often want. Keep adding to it every term.

Your teaching statement, as the frame.
A table of courses: course, term, your role (TA, head TA, instructor), enrollment, format, duties.
Sample materials you made: assignments, labs, rubrics, slides, autograder tests.
Student evaluations, summarized, with representative comments and context.
Observation reports from faculty or peers.
Midsemester feedback, and what you changed in response.
Samples of student work, with permission.
Teaching development: workshops, courses, certificates.
Awards, and invitations to teach or guest lecture.
A short reflection on what changed from term to term, and why.

Build it while you TA

Save what you make, as you make it, in one folder.
Ask your instructor to observe a section and write a few paragraphs about it.
Run midsemester feedback around week 3 or 4: a few anonymous questions (what helps, what doesn't, one suggestion). Record what you changed.
Keep a short teaching journal: a line or two when something works or fails. These become the moments in your statement.
Cover a lecture if you get the chance, and keep the observer's notes (see Covering a Lecture).
Ask a letter writer who has seen you teach.