Technical Interview Questions: Delete the Theater

Technical interview questions are broken. Most companies ask LeetCode riddles that have zero correlation with production engineering. They test memorization of binary tree traversals while ignoring the ability to debug a distributed transaction failure at 3 AM.

Here's the reality: The best engineers we've hired couldn't reverse a linked list on a whiteboard. They could architect fault-tolerant systems that processed 10 million events per second. The worst hires aced every algorithmic question and shipped nothing.

This article destroys the traditional interview playbook. We're giving you the actual technical questions that separate those who build from those who theorize.

Table of Contents

• ▹Why Most Technical Questions Fail
• ▹System Design Questions That Actually Matter
• ▹Database and Data Structure Reality Checks
• ▹Network Protocol and Infrastructure Questions
• ▹Language-Specific Technical Depth
• ▹Production Debugging Scenarios
• ▹Performance Optimization Questions
• ▹Security and Attack Surface Analysis
• ▹The Questions We Actually Ask at ByteForth
• ▹FAQ

Why Most Technical Questions Fail

Traditional technical interview questions optimize for the wrong signals. They measure pattern recognition under artificial time pressure. They don't measure architectural judgment, operational instincts, or the ability to delete code.

The fundamental flaw: Whiteboard coding has a 0.14 correlation with job performance according to Google's internal research. Companies still do it because it's easy to standardize, not because it works.

Real engineering competence shows up in three areas:

1. ▹System-level thinking - Can they reason about distributed state, failure modes, and scaling bottlenecks?
2. ▹Production instincts - Do they understand observability, deployment strategies, and incident response?
3. ▹Technical judgment - Can they choose boring technology that ships versus chasing framework hype?

Everything else is theater. Delete it.

When we interview engineers at ByteForth, we skip the LeetCode circus entirely. We ask them to design real systems we're actually building. We give them production incidents from our monitoring stack and watch how they debug. We show them our codebase and ask what they'd delete first.

The correlation with actual performance? Near-perfect. The candidates who thrive in these scenarios ship features in week one. The ones who struggle with real-world complexity never make it past probation.

System Design Questions That Actually Matter

System design questions should test architectural instincts, not memorized patterns. Here's what actually predicts success:

Question: Design a real-time analytics pipeline that ingests 500,000 events per second from IoT devices, supports sub-second query latency, and maintains exactly-once processing semantics. Walk me through your data flow, storage layer, and failure recovery.

What we're testing: Do they immediately ask about write patterns? Do they understand the CAP theorem tradeoffs? Can they reason about backpressure, partition strategies, and hot shard detection?

Red flags: They jump straight to Kafka without asking about event schema evolution. They propose a single PostgreSQL instance. They ignore network partition scenarios.

Green flags: They sketch a tiered architecture with stream processing (Apache Kafka for ingestion, time-series DB for hot data, object storage for cold). They discuss idempotency keys for exactly-once semantics. They mention circuit breakers and graceful degradation.

Another brutal one:

Question: You're seeing P99 latency spikes every 60 seconds in your API gateway. CPU and memory look normal. Network shows no packet loss. Debug it.

What we're testing: Do they understand garbage collection pauses? Can they reason about connection pool exhaustion? Do they check for cron jobs or background tasks stealing resources?

The best candidates immediately ask for GC logs, connection metrics, and a timeline correlation with deployment events. They don't guess randomly.

For more on optimizing database query patterns that eliminate latency spikes, see our article on what is indexing in database.

Database and Data Structure Reality Checks

Most interviews ask you to implement a hash table. Production databases don't care. They care if you understand transaction isolation levels, index selectivity, and query planning.

Question: Your application writes 10,000 rows per second to PostgreSQL. Read queries are getting slower every day. The table has 500 million rows. Fix it without vertical scaling.

What separates good from great:

• ▹Average engineer: "Add more indexes."
• ▹Strong engineer: "Partition the table by time range. Archive old data to object storage. Add covering indexes for hot query patterns. Consider read replicas with streaming replication."
• ▹Elite engineer: "First, I'd check EXPLAIN ANALYZE on slow queries to see if we're doing sequential scans. Then I'd look at table bloat from UPDATE churn. Might need VACUUM or pg_repack. Partitioning helps, but only if queries filter on the partition key. I'd also consider a write-optimized LSM tree database like RocksDB for hot data if latency matters more than relational semantics."

Data structure questions should connect to real performance problems:

Question: When would you use a skip list over a B-tree? Give me a production scenario.

Good answer: Skip lists are simpler to implement for concurrent access without locking complexity. They're used in Redis sorted sets because lock-free skip lists outperform B-trees under high concurrency. Write latency is more predictable since you don't have page splits.

Bad answer: "I'd use a skip list when... um... I need O(log n) search?"

Delete theoretical questions. Ask about production tradeoffs.

Network Protocol and Infrastructure Questions

Network knowledge separates backend engineers from distributed systems engineers. Most candidates can't explain TCP congestion control or HTTP/2 multiplexing.

Question: Your microservices are experiencing intermittent 504 timeouts. The application logs show no errors. Network infrastructure team says everything's fine. What do you check?

What we're looking for:

1. ▹Connection pool exhaustion: Are services keeping connections open too long?
2. ▹DNS resolution delays: Is the DNS cache expiring and causing lookup storms?
3. ▹Load balancer health checks: Are aggressive health checks exhausting backend capacity?
4. ▹TCP retransmits: Use tcpdump or Wireshark to check for packet loss.
5. ▹MTU mismatches: Are jumbo frames being fragmented?

The best engineers immediately ask for distributed tracing data (OpenTelemetry, Jaeger) to visualize request flow across service boundaries.

Another critical one: Explain the difference between connection timeout, read timeout, and idle timeout. When would you tune each?

• ▹Connection timeout: Time to establish TCP handshake. Tune this low (< 5s) to fail fast on unreachable hosts.
• ▹Read timeout: Time waiting for response data. Set based on expected p99 latency of downstream service.
• ▹Idle timeout: How long to keep connection alive with no activity. Balance connection reuse against server resource consumption.

Most engineers have never thought about this. Production systems fail because of wrong timeout configurations.

For related infrastructure optimization, check out our breakdown of Oracle Autonomous Database and how it eliminates manual tuning overhead.

Language-Specific Technical Depth

Language questions should probe memory models, runtime behavior, and performance characteristics. Not syntax trivia.

For Python engineers:

Question: Why is Python slow? Be specific about the GIL, reference counting, and bytecode interpretation. When would you still choose Python over Go?

Strong answer: Python's Global Interpreter Lock prevents true parallelism for CPU-bound tasks. Reference counting adds overhead to every object operation. The bytecode interpreter is slower than JIT compilation or native code.

But: Python's ecosystem (NumPy, pandas, scikit-learn) and development velocity make it dominant for data science, ML pipelines, and scripting. For I/O-bound services, the GIL doesn't matter. Use async frameworks like FastAPI or asyncio for concurrent request handling.

Choose Python when: Developer productivity matters more than raw throughput. Choose Go or Rust when you need sub-millisecond latency or efficient CPU utilization.

For JavaScript/TypeScript engineers:

Question: Explain event loop blocking. How would you handle a CPU-intensive task in a Node.js API without blocking the event loop?

Correct answers:

1. ▹Offload to worker threads (Worker Threads API)
2. ▹Spawn child process with message passing
3. ▹Use a job queue (Bull, BullMQ) with separate worker processes
4. ▹Compile CPU-heavy logic to WebAssembly
5. ▹Move it to a different service in a language built for CPU work

Wrong answer: "Just use async/await." (Async doesn't help with CPU-bound synchronous operations.)

For Rust engineers:

Question: When would you use Arc<Mutex<T>> versus Arc<RwLock<T>>? What's the performance tradeoff?

What we're testing: Do they understand lock contention, read-heavy versus write-heavy workloads, and the cost of writer starvation?

Production Debugging Scenarios

Debugging questions reveal operational maturity. Give candidates real incidents and watch their diagnostic process.

Scenario 1: Your API response times suddenly jumped from 50ms to 2 seconds. No code changes in the last 3 hours. No alerts from infrastructure. Debug it.

Diagnostic checklist:

1. ▹Check recent deployments (even if "no code changes" - config changes count)
2. ▹Examine database slow query logs and connection pool stats
3. ▹Look for external API dependency slowdowns
4. ▹Review recent DNS changes or load balancer configuration
5. ▹Check for resource exhaustion (file descriptors, memory, disk I/O)
6. ▹Correlate with traffic patterns (did volume spike?)

The best answer we've heard: "First, I'd check if metrics show this across all instances or just a subset. If it's all instances, it's likely a shared dependency (database, cache, external API). If it's one instance, could be a noisy neighbor problem in cloud infrastructure or a bad deploy canary. I'd look at distributed traces for a sample of slow requests to see exactly where time is spent."

Scenario 2: Users report intermittent data corruption. 1 in every 10,000 writes shows stale data. It's non-deterministic and doesn't reproduce locally.

What separates senior engineers:

• ▹They immediately suspect race conditions in distributed systems
• ▹They ask about database transaction isolation levels
• ▹They check for cache invalidation issues
• ▹They look for clock skew in distributed timestamps
• ▹They examine event ordering in message queues

Red flag answer: "I'd add more logging and try to reproduce it."

Strong answer: "Non-deterministic data corruption at low frequency screams race condition or eventual consistency violation. I'd first check if we're reading from a replica before write replication completes. Then I'd look for cache writes before database commits. I'd examine if we're using optimistic locking correctly. Finally, I'd check for clock drift causing timestamp comparison failures in distributed systems."

Learn more about eliminating inconsistent system states in our piece on AI agent architecture.

Performance Optimization Questions

Performance questions should focus on measurement, profiling, and actual bottleneck identification. Not premature optimization.

Question: Your application's memory usage grows unbounded over 48 hours until the process crashes. How do you debug it?

Systematic approach:

1. ▹Take a heap dump at high memory usage (jmap for Java, heapdump for Node.js, py-spy for Python)
2. ▹Analyze object retention - What's holding references to objects that should be garbage collected?
3. ▹Check for connection leaks - Are database connections, file handles, or sockets not being closed?
4. ▹Review caching logic - Are caches growing unbounded without eviction policies?
5. ▹Examine event listeners - Are you adding listeners without removing them?

Common culprits:

• ▹Unbounded in-memory caches without LRU eviction
• ▹Event emitters with accumulated listeners
• ▹Closures capturing large objects
• ▹Database connection pools never releasing connections
• ▹Circular references preventing garbage collection

Question: How would you optimize this SQL query that's taking 30 seconds?

SELECT users.name, COUNT(orders.id) 
FROM users 
LEFT JOIN orders ON users.id = orders.user_id 
WHERE users.created_at > '2025-01-01' 
GROUP BY users.name 
ORDER BY COUNT(orders.id) DESC 
LIMIT 100;

What good engineers do:

1. ▹Run EXPLAIN ANALYZE first to see actual execution plan
2. ▹Check for missing indexes on users.created_at and orders.user_id
3. ▹Consider if users.name has high cardinality (if not, might be slow GROUP BY)
4. ▹Question if we need LEFT JOIN or if INNER JOIN suffices (excludes users with no orders)
5. ▹Ask if this needs to be real-time or can be materialized view / cached

Optimization strategies:

• ▹Add covering index on (users.created_at, users.id, users.name)
• ▹Add index on orders.user_id
• ▹If query runs frequently, create materialized view refreshed hourly
• ▹If exact counts don't matter, use probabilistic counting (HyperLogLog)
• ▹Partition tables by date if data volume is massive

The wrong approach? "Just add an index." No measurement, no understanding of actual bottleneck.

Security and Attack Surface Analysis

Security questions should test threat modeling, not memorized attack types.

Question: You're designing a REST API for a banking application. Walk me through your authentication, authorization, and attack surface mitigation strategy.

Comprehensive answer includes:

1. ▹Authentication: OAuth 2.0 with JWT tokens, short-lived access tokens (15 min), refresh tokens in HttpOnly cookies with rotation, MFA for sensitive operations
2. ▹Authorization: Role-based access control (RBAC) with principle of least privilege, resource-level permissions checked at every API call
3. ▹Transport security: TLS 1.3 only, certificate pinning for mobile clients, HSTS headers
4. ▹Input validation: Parameterized queries for SQL injection prevention, input sanitization for XSS, request size limits for DoS prevention
5. ▹Rate limiting: Per-user and per-IP rate limits, exponential backoff on failed auth attempts
6. ▹Audit logging: Immutable audit trail of all sensitive operations with cryptographic signatures
7. ▹Data encryption: Encryption at rest for PII, field-level encryption for sensitive data, key rotation strategy

Question: How would you detect and prevent a credential stuffing attack?

Strong answers:

• ▹Monitor for login attempts with high failure rates from distributed IPs (indicates botnet)
• ▹Implement CAPTCHA after N failed attempts
• ▹Use device fingerprinting to detect automated clients
• ▹Check against known compromised password databases (Have I Been Pwned API)
• ▹Enforce password complexity and reject common passwords
• ▹Implement account lockout with escalating delays
• ▹Alert on successful logins from new devices/locations
• ▹Require MFA for high-risk operations

Question: Your API is getting hammered with 100,000 requests per second from a botnet. Your rate limiter isn't stopping it. Why not, and how do you mitigate?

Why rate limiting fails:

• ▹Botnet uses distributed IPs, so per-IP limits don't trigger
• ▹Attackers rotate user agents and headers to evade fingerprinting
• ▹Rate limiter uses in-memory state that doesn't scale to 100K req/s
• ▹Application-layer rate limiting is too late (requests already hit servers)

Proper mitigation:

1. ▹Edge-level filtering: Use DDoS protection at CDN/WAF layer (Cloudflare, AWS Shield)
2. ▹Distributed rate limiting: Use Redis cluster for shared rate limit state
3. ▹Challenge-response: Require JavaScript execution proof-of-work for suspicious traffic
4. ▹Behavioral analysis: Block traffic that doesn't behave like real browsers (no cookie support, missing headers)
5. ▹Null-route at network layer: Drop packets before they hit application servers

Our approach to securing distributed systems is covered in our analysis of BAS building automation system attack vectors.

The Questions We Actually Ask at ByteForth

Here's what separates our interviews from the theater:

1. Codebase archeology: We show candidates our actual production code (sanitized). We ask: "What would you delete first? What's the biggest architectural mistake you see?"

Why this works: It tests judgment, code reading skills, and willingness to challenge existing decisions. Engineers who ship fast can spot cruft instantly.

2. Incident post-mortem review: We give them a real production incident from our logs. Database went read-only. API started returning 500s. Customer data was temporarily inaccessible.

We hand them:

• ▹Grafana dashboards showing metrics before/during/after
• ▹Application logs with error traces
• ▹Database slow query logs
• ▹Network packet captures

Task: Write the post-mortem. Identify root cause, contributing factors, and preventive measures.

What we learn: Can they correlate signals across systems? Do they blame people or processes? Are their prevention strategies realistic?

3. Technology selection defense: "You need to build a feature that requires low-latency geospatial queries. Defend your database choice. Then argue against your own choice."

Why this works: It reveals if they can think critically about tradeoffs. Can they steelman opposing positions? Or do they just parrot HackerNews opinions?

4. Delete the feature: "We have 50 features in our product. Which 30 would you delete and why?"

What we're testing: Product sense, understanding of 80/20 rule, ability to say no. Engineers who can't delete features will bloat your codebase.

5. Build versus buy: "We need real-time collaboration (like Google Docs). Build it or integrate a third-party solution? Show your math."

Strong answer includes:

• ▹Engineering time cost (3 engineers × 6 months = $300K+)
• ▹Opportunity cost (what features don't get built?)
• ▹Operational complexity (WebSocket infrastructure, conflict resolution, scaling)
• ▹Third-party cost analysis (Yjs, Liveblocks, Pusher pricing)
• ▹Lock-in risk assessment

Engineers who immediately say "build it" don't understand business constraints. Engineers who immediately say "buy it" lack engineering ambition. The best answer is: "Depends on whether real-time collaboration is our core differentiator or table stakes."

For understanding when to build custom infrastructure versus using managed services, see our take on enterprise SaaS solution tradeoffs.

FAQ

What's the single most important technical interview question to ask?+

"Show me your GitHub. Walk me through the hardest technical problem you've solved in production." Code on a resume means nothing. Shipped code in production under real constraints reveals everything. Ask them to explain their architectural decisions, what they'd change now, and what they learned from production failures. If they can't point to real systems they've built and debugged, they're theorists, not engineers.

How do you evaluate system design skills without whiteboard architecture diagrams?+

Give them a real architecture problem you're currently solving. Provide actual constraints: traffic patterns, budget limits, team size, compliance requirements. Ask them to write a technical design doc like they would for your engineering team. Then have them present it and defend their choices against realistic objections. Whiteboard diagrams test drawing skills. Design docs test communication, tradeoff analysis, and practical engineering judgment. The engineers who thrive here ship features in week one.

Should technical interviews include live coding at all?+

Yes, but not LeetCode problems. Give them a real bug from your production codebase (sanitized). Watch them navigate unfamiliar code, add logging, form hypotheses, and isolate the issue. Or have them optimize an actual slow database query from your monitoring dashboard. Live coding should test debugging skills, code comprehension, and systematic problem-solving under realistic conditions. The ability to reverse a binary tree predicts nothing about production engineering competence. Delete the algorithmic theater.