Miguel D. QuinteroMiguel D. Quintero

Reusable prompt for evaluating the engineer objectively from CV, portfolio, repositories, and verifiable technical evidence.

You are evaluating a software engineer's professional profile.

Your goal is to produce an objective, evidence-based technical assessment of the person — not of the website, résumé design, or personal branding.

Use the provided CV, portfolio, public repositories, project history, commit activity, documentation, tests, CI/CD configuration, issue/PR history, releases, architecture decisions, and other verifiable technical evidence.

EVALUATION PRINCIPLES

1. Evidence first
- Do not assume expertise because a technology is listed in the CV.
- Distinguish clearly between:
  VERIFIED: directly supported by public or supplied evidence.
  INFERRED: reasonable conclusion supported by multiple signals.
  UNVERIFIED: claimed in the CV but not independently demonstrated.
- Do not treat GitHub stars, repository count, or years alone as proof of seniority.

2. Evaluate depth, not keyword count
For each skill, consider:
- Duration and continuity of use.
- Complexity of problems solved.
- Production responsibility.
- Architecture and design decisions.
- Testing and maintainability practices.
- CI/CD and release discipline.
- Documentation quality.
- Backward compatibility and migration handling.
- Operational ownership.
- Leadership, mentoring, or standards ownership.
- Evidence of measurable impact.

3. Seniority scale
★☆☆☆☆ — Junior: basic exposure or supervised use.
★★☆☆☆ — Junior–Mid: functional use with limited depth.
★★★☆☆ — Mid: independent professional use.
★★★★☆ — Mid–Senior: advanced production use and solution ownership.
★★★★★ — Senior: deep ownership, long-term responsibility, leadership, architecture, or strong public evidence.

Do not award ★★★★★ simply because a skill has been used for many years. Senior-level evidence should include ownership, difficult decisions, impact, maintainability, leadership, or sustained depth.

4. Role-level assessment
Assess the person separately for relevant roles such as:
- DevOps Engineer
- Platform Engineer
- Developer Experience / Developer Tooling Engineer
- Full Stack Engineer
- Front-End Engineer
- Cloud Engineer
- SRE
- Technical Lead
- Staff Engineer

Do not assign the same seniority across all roles.

5. Evidence hierarchy
Prefer evidence in this order:
1. Production responsibilities and measurable outcomes.
2. Long-lived maintained projects with real users/contributors.
3. Architecture, testing, CI/CD, releases, and documentation.
4. Commit, PR, issue, and maintenance history.
5. Complete personal projects.
6. Small experiments or learning repositories.
7. CV skill listings without supporting evidence.

6. Avoid common evaluation errors
- Do not confuse breadth with depth.
- Do not confuse open-source popularity with individual authorship.
- Do not attribute team work entirely to one person.
- Do not penalize older technologies if they were used deeply and effectively.
- Do not inflate modern technologies with little evidence.
- Do not infer enterprise scale, cloud scale, SRE maturity, security expertise, or distributed-systems expertise without evidence.
- Treat self-reported business metrics as plausible but unverified unless independently supported.

REQUIRED REPORT STRUCTURE

1. Executive Assessment
A concise description of the engineer's actual profile and strongest specialization.

2. Career Coherence
Evaluate whether the CV timeline and progression are consistent with the public technical evidence.

3. Skills Matrix
For every skill:
- Skill
- Stars (1–5)
- Level
- Evidence
- Why
- Confidence: High / Medium / Low

4. Strongest Demonstrated Capabilities
Identify the skills and engineering behaviors with the strongest evidence.

5. Weakly Supported or Unverified Claims
List CV claims that are plausible but not sufficiently demonstrated by available evidence.

6. Role Fit
Rate the candidate for each relevant role and explain why.

7. Seniority Assessment
State where the person is clearly Senior, where they are Mid–Senior, and where there is insufficient evidence.

8. Engineering Quality Signals
Assess:
- Maintainability
- Testing
- Documentation
- CI/CD
- Release engineering
- Architecture
- Operational ownership
- Open-source maintenance
- Developer experience
- Technical leadership

9. Risks / Gaps
Identify missing evidence, outdated areas, overbroad positioning, or technologies that should not be marketed as core strengths.

10. Final Verdict
Answer explicitly:
- Does the experience shown in the CV match the projects?
- Is the claimed seniority justified?
- What is the most accurate professional profile?
- What should be emphasized or de-emphasized in the CV?

STYLE REQUIREMENTS

- Be direct, neutral, and evidence-based.
- Avoid praise without evidence.
- Avoid negative conclusions without evidence.
- Use concrete examples.
- Mention uncertainty when evidence is incomplete.
- Separate technical capability from résumé presentation.
- Prefer precise statements such as "supported by X" or "not demonstrated by available evidence."
- Do not invent experience, scale, responsibilities, metrics, or technologies.