Behavioral Tips

// Question: 'Tell me about a time you dealt with a difficult bug.'

// Situation: 'Our payment service was intermittently failing
//   for about 2% of transactions on weekends.'

// Task: 'As the on-call engineer, I needed to diagnose and
//   fix it before Monday's peak traffic.'

// Action: 'I correlated the failures with database connection
//   pool exhaustion, traced it to a missing timeout on a
//   third-party API call, added a 3-second timeout with
//   retry logic, and deployed with a feature flag.'

// Result: 'Payment failures dropped to 0.01%, saving an
//   estimated $50K in lost weekend revenue. I also added
//   monitoring alerts so the team would catch similar
//   issues earlier.'

// Tip 1: Don't start coding immediately.
// Spend 5 minutes thinking → saves 15 minutes of rewriting.

// Tip 2: State the brute force first.
// 'The naive approach is O(n^2)...but I think we can do
// O(n) using a hash map. Let me explain before coding.'

// Tip 3: If stuck after 3 minutes, ask for a hint.
// 'I'm thinking about using X, does that sound like the
// right direction?' — This is better than silent struggling.

// Tip 4: Code the core logic first, handle edge cases after.
// Get the main algorithm working, then add null checks,
// empty input handling, etc.

// Tip 5: Talk while you code.
// 'I'm initializing two pointers at each end because...'

// Great clarifying questions by problem type:

// Array/String:
// 'Can there be negative numbers?'
// 'Is the array sorted?'
// 'Should I handle empty input?'
// 'Are there duplicate values?'
// 'ASCII or Unicode characters?'

// Graph:
// 'Is it directed or undirected?'
// 'Can there be cycles?'
// 'Are edge weights positive?'
// 'Is the graph connected?'

// Design:
// 'How many users/requests per second?'
// 'What is the read/write ratio?'
// 'What are the latency requirements?'
// 'Do we need strong or eventual consistency?'

// Instead of going silent, try these phrases:

// 'Let me trace through this example manually to see
//  if I can spot a pattern...'

// 'I've been thinking about a hash map approach, but
//  the ordering constraint makes me think maybe a
//  stack or monotonic structure would be better.'

// 'The brute force would be O(n^2) with nested loops.
//  I wonder if sorting first could help us do better.'

// 'I'm stuck on how to handle this edge case. Can you
//  give me a hint about what should happen when the
//  input has all identical values?'

// 'This reminds me of the two-sum pattern — let me
//  think about whether a complement approach works here.'

// Strong communication pattern:
// Step 1: 'I understand the problem as...'
// Step 2: 'My initial thought is to use X because...'
// Step 3: 'The trade-off is A vs B. I'll go with A because...'
// Step 4: While coding: 'This loop handles the case where...'
// Step 5: 'Let me verify with the example: for input [1,2,3],...'
// Step 6: 'The time complexity is O(n) because we visit each
//          element once. Space is O(n) for the hash map.'

// Weak communication:
// 'Um...let me think...okay I'll try this...'
// *codes silently for 20 minutes*
// 'I think this works.'

// 'Tell me about yourself' template:
// 'I'm a [role] with [X years] of experience focused on [area].
//  Most recently at [Company], I worked on [project] where I
//  [key achievement with metric]. I'm excited about [company]
//  because [specific reason tied to their product/mission].
//  I'm looking for [what you want in next role].'

// Failure question template:
// Situation: what happened
// What went wrong and YOUR role in it (own it)
// What you learned
// How you applied that lesson later
// Do NOT blame others or external factors

// 'Why this company?' — research 3 specific things:
// 1. A product feature you admire
// 2. A company value that resonates
// 3. A technical challenge they face that excites you