El Sistema de Alerta Temprana de Deterioro de Habilidades: Descubra Qué Habilidades Profesionales Necesitan Actualización Antes de que le Cuesten Caro
Por qué importa este prompt
Skill decay is invisible until it's tested. A professional who assumes year-old expertise is still current walks into an interview, an audit, or a client deliverable with confidence that doesn't match their actual recall speed — and the gap surfaces at the worst possible moment: live, in front of the person deciding whether to hire or retain them. Generic "brush up before the interview" advice doesn't say which of five skills actually need the limited prep time, so people either over-prepare on something that barely matters or walk in cold on the one thing that will actually get tested.
Para qué lo usamos
You are a senior data analyst who hasn't written a SQL window function or CTE in 14 months because your current role is mostly dashboard maintenance in a no-code BI tool. You just landed a technical interview for an analytics engineering role in five weeks, and the recruiter confirmed it includes a live SQL screen.
Prompt
You are a career-development strategist who audits skill currency before it becomes a visible gap in interviews, performance reviews, or client work. CONTEXT: - My core professional skills, with when I last actively used each one: [LIST SKILLS AND LAST-USE DATES, e.g., "SQL window functions/CTEs — 14 months ago. Python/pandas — weekly. Public speaking to executives — 3 months ago. Statistics/hypothesis testing — 2 years ago. Tableau — daily."] - My current role or target role: [DESCRIBE, e.g., "Senior data analyst, targeting a move into analytics engineering within 12 months"] - Upcoming situations where these skills will be tested: [DESCRIBE, e.g., "Technical interview with a live SQL screen in 5 weeks"] TASK — complete all three steps in order: Step 1 — SCORE DECAY RISK. For each skill listed, assign a decay-risk rating (Low / Medium / High) based on: time since last active use, how fast that specific skill or tool domain changes (a scripting language with frequent syntax/library churn decays faster than an interpersonal skill like negotiation or public speaking), and whether the skill is foundational (slower to decay) or highly specialized (faster to decay). Step 2 — SCORE CRITICALITY. Cross-reference each skill's decay risk against how critical it actually is to my stated role/target role and to the specific upcoming situation(s) I listed. A skill can be highly decayed but low-priority if it won't actually be tested or used soon. Step 3 — TRIAGE. Using only the intersection of HIGH decay risk and HIGH criticality, produce a short, forced-ranked priority list — no more than [MAX NUMBER OF PRIORITIES, e.g., "3"]. For each priority skill, give one specific refresh action completable in under [TIME BUDGET, e.g., "2 hours"] this week — not "take a course" or "review documentation," but a concrete, scoped task (e.g., "solve 15 SQL problems specifically using RANK, ROW_NUMBER, and recursive CTEs on a practice platform"). If any priority skill is too decayed for a single short session to meaningfully fix, say so explicitly and propose a short multi-day micro-practice plan instead of pretending one session will work. CONSTRAINTS: - Do not recommend refreshing any skill that scores low on criticality, no matter how decayed it is - Every refresh action must be scoped to the stated time budget — reject vague actions like "brush up on X" - Explicitly name which skills you are NOT prioritizing and why, so the triage logic is visible, not just the conclusion - If a skill needs more than the time budget allows, say so rather than under-promising a quick fix OUTPUT FORMAT: 1. Skill Decay & Criticality Table (columns: Skill, Last Active Use, Decay Risk, Criticality, Priority Rank or "Skipped — why") 2. Top Priority Refresh Actions (one concrete action per priority skill) 3. Flag: any skill requiring a structured multi-day plan instead of a single session, with a brief day-by-day outline
Resultado
Skill Decay & Criticality Table:
| Skill | Last Active Use | Decay Risk | Criticality | Priority |
|---|---|---|---|---|
| SQL window functions / CTEs | 14 months ago | High | Very High (live SQL screen) | #1 |
| Statistics / hypothesis testing | 2 years ago, rigorous use | High | Medium (may surface in a case study) | #2 |
| Python / pandas | Weekly | Low | Medium | Skipped — low decay, not the bottleneck |
| Tableau | Daily | Low | Low (target role uses dbt/Looker, not Tableau) | Skipped — low decay and low relevance to target role |
| Public speaking to executives | 3 months ago | Low | Low (interview is technical, not presentation-based) | Skipped — currently fresh and not tested here |
Top Priority Refresh Actions:
- #1 — SQL window functions/CTEs (2-hour action): Solve 15 problems on a SQL practice platform (StrataScratch, LeetCode SQL, or similar), restricted specifically to RANK/DENSE_RANK/ROW_NUMBER, LAG/LEAD, and recursive CTEs — these are the two pattern families interviewers test most often and the ones most likely to have gone stale after 14 months of dashboard-only work. Do not spend this time on basic JOINs or WHERE clauses; those haven't decayed.
- Flag — SQL needs more than one session: 14 months of disuse on a skill being tested live is too much decay to fix in a single 2-hour cram. Instead of one session, run a 5-day micro-practice plan: Day 1–2, window functions only (30 min/day); Day 3, recursive CTEs only (30 min); Day 4, mixed practice problems under light time pressure (45 min); Day 5, one full mock technical screen with a timer (60 min). This spaced structure will retain better than a single long cram session the night before.
- #2 — Statistics/hypothesis testing (90-minute action): Review p-values, confidence intervals, and how to read A/B test significance results, since that is the most likely case-study angle in an analytics engineering interview — not full distribution theory or regression derivations, which are lower-yield for this specific interview format.
Not prioritized, with reasoning: Python/pandas and Tableau are both in weekly-to-daily active use, so their decay risk is already low regardless of how long the interview prep window is. Public speaking is currently fresh (used 3 months ago) and this interview format doesn't test it. Spending any of the 5-week prep window on these would be time taken directly away from the one skill — SQL — that is both highly decayed and highly likely to be tested.
La mayoría de los consejos sobre actualización de habilidades trata todas las habilidades oxidadas por igual: si no la ha usado recientemente, repásela. Ese consejo desperdicia el único recurso que realmente escasea antes de una entrevista, una entrega a un cliente o una presentación de alto riesgo: el tiempo. Este prompt se construye alrededor de una idea específica: el riesgo de deterioro y la relevancia son dos variables separadas, y solo su intersección importa. Una habilidad puede estar extremadamente oxidada y ser completamente irrelevante para lo que está por suceder, y una habilidad puede estar solo ligeramente oxidada pero situarse justo en el camino de lo que se evaluará la próxima semana.
Por qué el riesgo de deterioro y la relevancia se califican por separado
Combinar «qué tan oxidada está esto» y «qué tan importante es esto ahora» en una sola lista de prioridades basada en la intuición es exactamente lo que hace que las personas se sobrepreparen en una habilidad que apenas importa y lleguen sin preparación a la que sí importa. Calificarlas como dos ejes separados obliga al modelo —y a la persona que usa el prompt— a notar combinaciones que no coinciden con la intuición, como una habilidad usada hace solo tres meses (hablar en público en el ejemplo) que, de todos modos, se omite correctamente porque no es lo que se va a evaluar.
Por qué el prompt exige una lista visible de «omitido — por qué»
Una lista de prioridades con tres elementos parece completa por sí sola, pero oculta el razonamiento que hizo que otras habilidades quedaran fuera. Obligar a la salida a nombrar qué se omitió y por qué hace que la lógica de la clasificación sea auditable: si el razonamiento para omitir Tableau o Python parece incorrecto para quien lo lee, puede corregir las entradas y volver a ejecutar el prompt, en lugar de confiar silenciosamente en una lista ordenada que no puede verificar.
Por qué el prompt se niega a subestimar una solución rápida
La mayoría de los prompts a los que se les pide producir una «acción de actualización de 2 horas» producirán fielmente una, incluso cuando dos horas realmente no sean suficientes, porque eso es lo que se pidió. Este prompt instruye explícitamente al modelo para que señale cuándo el deterioro de una habilidad es demasiado severo para el presupuesto de tiempo indicado y proponga, en su lugar, un plan breve de varios días. Esta restricción existe porque un plan de 2 horas confiado pero inadecuado para una habilidad con 14 meses de desuso es peor que un plan honesto de 5 días: crea una falsa confianza justo al entrar en la situación exacta para la que la persona intenta prepararse.
Cómo adaptarlo
El prompt funciona para cualquier profesional cuya experiencia abarque habilidades con tasas de deterioro muy diferentes: un abogado cuyas habilidades de litigio están afiladas pero cuyo conocimiento de una normativa recién modificada está oxidado, un gerente cuyos instintos de liderazgo de personas están actualizados pero cuya familiaridad con una herramienta de RR. HH. específica ha decaído, o un desarrollador cuyas habilidades básicas del lenguaje están bien pero cuyo conocimiento de certificación de una plataforma en la nube está dos versiones por detrás. Enumere las habilidades, anote cuándo usó activamente cada una por última vez, nombre la situación próxima que las pondrá a prueba, y deje que la calificación de dos ejes haga la clasificación en lugar de adivinar.