Capstone Performance Review and Rubric
Back to Capstone Project Overview
Back to Capstone Project Expectations
Overview
You will notice that much of the rubric assesses:
- Your regular, continual, and active participation in the project
- Your ability to collaborate with your team
- Your ability to implement features and solve problems while adhering to the project’s conventions
As such, you will be assessed throughout the duration of the project rather that during one final evaluation session at the end. Just like on the job, you are expected to perform at a high level consistently and not just on the days when you are undergoing review.
Self Assessment
Self assessment is a required part of the project. Failure to submit the self-assessment will result in a failure for the project. It is an opportunity for you to reflect on your work, identify areas for improvement, share your successes, and celebrate your accomplishments. Self evaluation is also common in professional environments. Typically this happens during your annual review (or whatever cadence your company uses).
You should include the following in your self assessment:
- Share feedback you have received from at least two teammates
- You can copy and paste feedback from Slack if written or summarize if verbal
- List your contributions to the project
- Can be submitted as issues you completed or as a list of tasks/features you implemented
- What technical areas do you feel strongest in?
- Examples: Ruby, Rails, JavaScript, React, Testing, Debugging, Deployment, Project Management, Collaboration, Git Workflow, etc
- Discuss 2-3 areas of improvement for yourself as a developer and team member
- Assign yourself a score in each category
Rubric
Students are expected to score in the Meets Expectations category. If any one category score is Below Expectations OR two or more categories are Approaching Expectations, the project will be considered failing.
Work Ethic and Attitude
- Exceeds Expectations:
- Regularly brings questions and ideas to check-ins
- Responds with an appropriate urgency to messages in Slack during work hours
- Demonstrates a positive attitude and willingness to learn
- Takes initiative to research and propose solutions to problems
- Completes self assessment with thoughtful reflection and clear action items
- Meets Expectations:
- Attends every live or async daily check-in, on time, and notifies the instructor if they are unable to attend
- Actively participates in daily stand-ups, providing clear updates on progress and blockers
- Responds to Slack messages within a reasonable amount of time during work time
- Shows enthusiasm for the project and a desire to improve
- Maintains a positive and respectful attitude in all team interactions
- Completes self assessment with thoughtful reflection
- Approaching Expectations:
- Misses or is late to up to two live or async daily check-ins without notifying the instructor
- Does not always provide clear updates on progress and blockers during daily check-ins
- Occasionally responds to Slack messages slowly such that other teammates are blocked
- Slow to ask questions
- Actively participates in the project but does just enough to get by
- Completes self assessment but reflection is lacking
- Below Expectations:
- Misses or is late to three or more live or async daily check-ins without notifying the instructor
- Daily updates are unclear, vague, or lacking detail at least half the time
- Asks questions infrequently, if at all
- Sporadic or infrequent communication in Slack
- Does not participate in the project or does not contribute to the project in a meaningful way
- Does not fill out the self assessment
Collaborative Workflow
- Exceeds Expectations:
- Consistently updates project board and includes progress and blockers
- Provides constructive and actionable feedback on 4 or more pull requests
- Uses co-authored commits on paired pull requests
- Solicits project ideas and feedback from quieter teammates
- Meets Expectations:
- Moves tasks along on the project board in real time (or close to it)
- Communicates effectively with team members and project manager through appropriate channels
- Collaborates well on pair programming tasks, showing both the ability to lead and follow
- Provides constructive and actionable feedback on at least 3 pull requests
- Seeks clarification when requirements or tasks are unclear
- Demonstrates active listening skills during team discussions and meetings
- Shows willingness to help team members when they encounter difficulties
- Transparently communicates blockers and seeks help when appropriate
- Approaching Expectations:
- Updates the project board about once per day
- Provides constructive and actionable feedback on at least 2 pull requests
- Ineffective time boxing: Spends too much time trying to figure things out on their own before asking for help or struggles to communicate blockers and seek help in a timely manner
- Below Expectations:
- Updates project board less than once per day
- Provides constructive and actionable feedback on 1 or fewer pull requests
- Behaving in an anti-collaborative way. This might look like:
- Not contributing to project planning or decision making discussions
- Disappearing for 24 hours or more (Monday-Friday) without notice or explanation
- Not following the project’s defined workflow
- Missing deadlines, meetings, or discussions without notice more than once
Code Quality
- Exceeds Expectations:
- Proactively seeks to understand and improve code performance by asking questions and researching solutions
- Shows a keen interest in learning about tools and architecture solutions outside of the scope of lessons taught at Turing
- Actively participates in reviews of their own code and addresses feedback effectively
- 100% of code is well tested, including sad paths and edge cases
- Meets Expectations:
- Demonstrates strong understanding of the primary programming language and framework used in the project through implementation and successful completion of all issues assigned
- Effectively addresses feedback from code reviews
- At least 90% of code is well tested, including sad paths and edge cases
- Implements proper error handling
- Demonstrates understanding of code organization principles (e.g., separation of concerns, SRP, DRY)
- Maintains a clean and organized codebase, following agreed-upon coding standards
- Approaching Expectations:
- Usually demonstrates a strong understanding of the primary programming language and framework used in the project though occassionally strays from conventions or the project’s coding standards
- Usually addresses feedback from code reviews but occassionally misses details
- Improperly handles some errors
- Most code is well tested but some edge cases or sad paths are not tested
- Below Expectations:
- Does not demonstrate a strong understanding of the primary programming language and framework used in the project either through incorrect implementation or lack of completion of issues assigned
- Does not follow the project’s coding standards
- More often than not, does not implement error handling
- Code is not well tested missing many edge cases and sad paths
Technical Problem Solving
- Exceeds Expectations:
- Always breaks down complex issues into manageable components
- Proactively identifies potential problems and proposes solutions before they become critical issues
- Assists teammates as needed in debugging and problem solving
- Regularly seeks out, applies, and offers feedback to improve problem-solving approaches
- Meets Expectations:
- Consistently breaks down complex issues into manageable components
- Identifies potential problems before they become critical issues
- Shows the ability to apply existing knowledge to new situations and technologies
- Effectively uses debugging tools and techniques to isolate and resolve issues
- Regularly applies feedback to improve problem-solving approaches
- Approaching Expectations:
- Breaks down complex issues but not always effectively or into the smallest reasonable pieces
- Can usually adapt existing knowledge to new situations and technologies but occassionally jumps immediately to asking for help
- Uses debugging tools and techniques to resolve issues but does not always isolate the root cause
- Regularly seeks out feedback but does not always act on it to improve problem-solving approaches
- Below Expectations:
- Often skips breaking down complex issues into the smaller more reasonable pieces
- Cannot identify potential problems in code implementation
- Struggles to adapt existing knowledge to new situations and technologies often jumping immediately to asking for help
- Struggles to debug without asking for help
- Does not seek out feedback or ignores it when given
Git Workflow and Deployment
- Exceeds Expectations:
- Uses Pull Request templates and at least four PRs include specific questions/asks of the code reviewer
- Always creates focused, small pull requests that are easy to review
- Rebases before merging
- Deletes branches after merging
- App has passing CI and is deployed successfully after every PR is merged
- Meets Expectations:
- Uses Pull Request templates and at least three PRs include specific questions/asks of the code reviewer
- Writes clear and descriptive commit messages following a consistent convention
- Creates focused, small pull requests that are easy to review, but one may be larger than expected
- Regularly pushes code and keeps the remote repository up-to-date
- Uses a new branch for each issue and each Pull Request; Never reuses a branch
- App has passing CI and is deployed successfully after almost every PR is merged, with few exceptions (misses no more than twice)
- Approaching Expectations:
- Uses Pull Request templates and at least two PRs include specific questions/asks of the code reviewer
- Creates focused, small pull requests that are easy to review, but up to two may be larger than expected
- Commit messages are usually clear and always professional, but don’t always follow a consistent convention
- Uses a new branch for each issue and each Pull Request but may accidentally reuse a branch once or twice
- App usually has passing CI and is usually deployed successfully after a PR is merged, with some exceptions (misses no more than 3 times)
- Below Expectations:
- Uses PR templates but fewer than two PRs include specific questions/asks of the code reviewer
- Commit messages are often unclear, sometimes unprofessional, and don’t always follow a consistent convention
- Creates focused, small pull requests that are easy to review, but more than two may be larger than expected
- Inconsistently pushes code or pushes directly to
main - Regularly reuses a branch or includes multiple issues in a single branch and PR
- App has passing CI less than half the time and is not always deployed successfully after a PR is merged (misses more than 3 times)
