code-pair-interviews — Cursor rule: what it does, how to install
Sets up Cursor for live coding interviews by enforcing plan outlines, simple initial solutions, clean naming, and edge-case handling.
.cursor/rules/code-pair-interviews.mdcWhat code-pair-interviews does
The rule forces Cursor to behave like a candidate during a pair programming interview. It requires outlining a high-level plan before writing any code. The assistant focuses on a straightforward baseline first, leaving optimization for later stages. Solutions are split into modular classes and functions following the Single Responsibility Principle.
Formatting conventions are strictly defined. Indentation uses 2 spaces, lines stay between 80 and 100 characters, and descriptive variable names replace short abbreviations like calc. Functions require docstrings covering parameters and return values, while self-explanatory logic remains uncommented.
Because alwaysApply: false is set in the frontmatter, Cursor will not load this rule across every prompt by default. You trigger it intentionally when practicing interview problems or staging a mock session.
What it helps with
- outline a step-by-step plan before generating interview code
- refactor dense logic into modular functions adhering to SRP
- enforce 2-space indentation and 80-100 character line limits
- add function docstrings and edge-case error checks
Example prompts for the agent
- Help me solve this array problem: outline your approach first, then write clean code
- Refactor this class into modular units with descriptive variable names
- Check this interview solution for edge cases and add docstrings to the methods
How to install code-pair-interviews
Manually: put the files in place
.cursor/rules/code-pair-interviews.mdcFrontmatter: description, globs, alwaysApply
Manually: put the files in place
.claude/rules/code-pair-interviews.mdThe paths frontmatter field limits the files: move globs from the source into paths
AGENTS.md
Codex reads AGENTS.md: paste the rule text there
Manually: put the files in place
.github/instructions/code-pair-interviews.instructions.mdThe applyTo field sets which files it applies to: move globs from the source into applyTo
Manually: put the files in place
.devin/rules/code-pair-interviews.mdManually: put the files in place
.clinerules/code-pair-interviews.mdStep by step, with commands for each platform: Cursor rules: .mdc files, four modes and what replaced .cursorrules
Questions about code-pair-interviews
How to install code-pair-interviews in Cursor?
Save the rule file to .cursor/rules/code-pair-interviews.mdc in your project repository.
What does the code-pair-interviews rule do?
It configures Cursor to follow pair programming interview standards, focusing on high-level planning, simple baseline solutions, 2-space indentation, and thorough edge-case testing.
Why does the rule have alwaysApply set to false?
The alwaysApply: false flag prevents Cursor from forcing strict interview constraints, like 80-100 character line limits, onto everyday development files.
Source text
code-pair-interviews.mdc · CC0-1.0
---
description: "Cursor rules for code pair interviews development with integration."
globs: **/*
alwaysApply: false
---
You are an expert software developer focused on producing clean, well-structured, and professional-quality code, suitable for a code pair programming interview.
Code Structure and Organization
- Organize code logically with a clear separation of concerns.
- Break down problems into smaller, self-contained units using functions and classes.
- Ensure modularity and reusability of code components.
- Adhere to the Single Responsibility Principle: each function/class should have one specific job.
- When tackling complex problems, begin by outlining a high-level plan before writing code.
- Start with a simple, straightforward solution to the core problem, optimizing later if time allows.
- Select appropriate data structures and algorithms with a focus on clarity and efficiency.
- Example: Use a hash map for quick lookups when appropriate.
Coding Style
- Maintain consistent indentation using 2 spaces (prefer spaces over tabs).
- Use meaningful and descriptive names for variables, functions, and classes.
- Avoid single-letter or cryptic abbreviations.
- Example: Use `calculate_total_cost` instead of `calc`.
- Employ comments judiciously to explain non-obvious logic or provide high-level overviews.
- Use docstrings for functions and methods to describe purpose, parameters, and return values.
- Avoid over-commenting self-explanatory code.
- Keep lines of code within a reasonable length (80-100 characters) to enhance readability.
- Use blank lines to separate logical blocks of code and improve visual organization.
Coding Best Practices
- Write clean and readable code.
- Prioritize clarity in code structure and style.
- Consider edge cases and implement error handling.
- Strive for efficient solutions.
- Test code thoroughly with various inputs, including edge cases.
- Start simple and optimize later.
© PatrickJS · CC0-1.0 · PatrickJS/awesome-cursorrules
