Hiring Técnico

Interpretar resultados de test de mobile developer: del score a la decisión

ClarityHire Team(Editorial)2 min read

El score sin contexto es ruido

¿Es 72/100 bueno? Pregunta backwards. La pregunta correcta: ¿qué sabe y qué aprenderá para este rol?

Construir rúbrica primero

Rúbrica iOS

Code correctness (0-30): compila (10), requirements (15), edge cases (5) Architecture (0-25): state management (10), testable (10), no overengineering (5) Knowledge (0-20): lifecycle (8), memory safety (7), async (5) Code quality (0-25): readability (10), no bugs (10), commits (5)

Pass threshold: 65-70.

Rúbrica Android

Correctness (0-30): compila (10), requirements (15), edge cases (5) Architecture (0-25): ViewModel/Repository (10), DI (10), separation (5) Knowledge (0-20): coroutines (8), lifecycle (7), testing (5) Quality (0-25): readability (10), no bugs (10), build config (5)

Pass: 65-70.

Qué significan scores

85+: strong hire

Solucionó cleanly, edge cases, mergeable. Acción: next round.

70-84: adequate con gaps

Funciona pero rough edges. Acción: depende de seniority.

60-69: passing técnicamente, concerning estratégicamente

Pasó porque requirements met, no porque solución sea good. Acción: entrevista deeply.

<60: not ready

Pass excepto growth excepcional.

Walk-through: donde scores se vuelven decisiones

"Walk me through cómo guardaste user preference."

Strong (72→80+): "UserDefaults para simple, Codable+JSON para complex, errors check, mocked file system." Weak (72→55): "No estoy seguro, no pensé en errors."

Errores de interpretación

"Didn't finish" vs "doesn't know"

Time-out es signal sobre time-management, no competencia.

Overweighting un aspecto

¿Fail por no tests? Depende de team y rol.

Grading wrong para platform

SwiftUI vs UIKit, Java vs Kotlin: depende de qué haces.

Weak score = weak engineer

Strong devs tienen bad days. Score es un signal.

Borderline scores

65-70

Targeted second assessment. O live coding.

60-64

¿Qué es el gap? Aprendible? Hire e invierte.

Building validity

¿High scorers succeed? ¿Low scorers struggle? Adjust rubric.

Red flags

  • "Code is ugly but works" — uglyness compounds
  • No async-await — depende del rol
  • Different way — no equal wrong
  • Used library — penalizar es backwards

En hiring meeting

No "72/100." Sí: "72 con strong correctness 28/30, weaker arch 18/25. Walk-through: solid lifecycle. Gap: testability. Para mid-level, acceptable."

Consistencia

  • Misma rúbrica
  • Score on rúbrica, no gut
  • Two graders independientes
  • Document reasoning
  • Adjust por outcomes
mobile-developmentiosandroidresultadosdecisiones

Artículos relacionados