Entrevistas para puestos de ingeniería senior

## ❌ Weak communication pattern
"I'd use Redis for caching because it's fast."
 
## ✅ Strong communication pattern  
"For the caching layer, I'd use Redis over Memcached for two reasons:
1. We need data structures beyond simple key-value — sorted sets 
   for the analytics leaderboard and hash maps for link metadata.
2. Redis persistence lets us survive cache restarts without a 
   thundering herd hitting the database.
 
The tradeoff is Redis uses more memory per key than Memcached, 
and horizontal scaling requires Redis Cluster setup. Given our 
~50GB working set, a single Redis instance with a read replica 
handles the load for the first year."

## Common Senior Behavioral Questions
 
1. "Tell me about a time you disagreed with a technical decision."
2. "Describe a project that failed. What was your role?"
3. "How do you handle a situation where two teams have conflicting priorities?"
4. "Tell me about a time you mentored someone and it changed their trajectory."
5. "Describe a time you had to make a technical decision with incomplete information."
 
## STAR Framework Response Structure
 
S - Situation: Brief context (2 sentences max)
T - Task: What was your specific responsibility  
A - Action: What YOU did (not the team)
R - Result: Quantified outcome + what you learned

## Example: Technical Disagreement
 
Situation: "Our team needed to migrate from a monolith to 
microservices. The architect proposed extracting all 12 services 
at once over 6 months."
 
Task: "As the senior engineer responsible for the payment system, 
I believed the big-bang approach was too risky for our revenue-
critical path."
 
Action: "I wrote a one-page proposal for a strangler fig pattern — 
extract one service at a time, starting with the lowest-risk 
domain (notifications). I included a rollback plan for each phase 
and showed how we could measure success before extracting the 
next service. I presented it at the architecture review meeting."
 
Result: "The team adopted the incremental approach. We extracted 
4 services in 6 months with zero customer-facing incidents. The 
remaining 8 services were migrated over the next year. The key 
lesson: I learned that proposing a concrete alternative is more 
effective than opposing someone's plan without one."

// Given: Current architecture overview
interface CurrentSystem {
  api: 'Express monolith, single process';
  database: 'PostgreSQL, single primary, 500GB';
  cache: 'Application-level in-memory cache';
  queue: 'Cron jobs for async processing';
  deployment: 'Single EC2 instance, manual deploys';
}
 
// Task: "We're seeing 5-second response times during peak hours
// and had two outages last month. What would you change?"
 
// Framework: prioritize by impact and reversibility
const recommendations = [
  {
    change: 'Add Redis caching layer',
    impact: 'high',
    effort: 'low',
    reasoning: 'In-memory cache dies on restart. Redis survives deploys.',
    risk: 'Low — additive change, fallback to database on cache miss',
  },
  {
    change: 'Add read replica for PostgreSQL',
    impact: 'high',
    effort: 'medium',
    reasoning: '500GB DB with read-heavy load. Route analytics/reports to replica.',
    risk: 'Medium — need to handle replication lag for consistency-sensitive reads',
  },
  {
    change: 'Replace cron with proper job queue (BullMQ/SQS)',
    impact: 'medium',
    effort: 'medium',
    reasoning: 'Cron misses jobs if process crashes. Queue provides retry and visibility.',
    risk: 'Low — can migrate one job at a time',
  },
  {
    change: 'Containerize and deploy to ECS/K8s',
    impact: 'high',
    effort: 'high',
    reasoning: 'Single EC2 = single point of failure. Containers enable horizontal scaling.',
    risk: 'High — large infrastructure change, do this after quick wins',
  },
];

## Story Bank (prepare before interviews)
 
### Technical Leadership
- [ ] Led a major migration or refactoring effort
- [ ] Made a reversible architectural decision under uncertainty
- [ ] Introduced a new technology or practice to the team
 
### Conflict and Communication
- [ ] Disagreed with a manager or architect and resolved it
- [ ] Mediated between two teams with conflicting priorities
- [ ] Gave difficult feedback to a peer or direct report
 
### Impact and Growth  
- [ ] Mentored someone who grew significantly
- [ ] Identified and fixed a systemic issue (not just a bug)
- [ ] Reduced operational burden measurably (on-call, deploy time)
 
### Failure and Learning
- [ ] Project that failed — what you learned
- [ ] Decision you would make differently now
- [ ] Production incident you caused or resolved
 
## For each story, prepare:
- 30-second version (elevator pitch)
- 2-minute version (standard interview response)
- 5-minute version (deep-dive if asked to elaborate)

## Negotiation Framework
 
1. Never give a number first
   - "I'd like to understand the full compensation package
     before discussing numbers."
 
2. Research the market range
   - levels.fyi, Glassdoor, Blind, ask your network
   - Know the 25th, 50th, and 75th percentile for your role
   
3. Negotiate on multiple dimensions
   - Base salary, equity/RSUs, signing bonus, remote flexibility,
     title, team placement, review timeline
 
4. Use competing offers honestly
   - "I have another offer at $X. I'd prefer to join your team,
     but I need the compensation to be competitive."
 
5. Get it in writing
   - Verbal offers mean nothing. Wait for the written offer
     letter before making any decisions.