Software Engineer Preguntas de entrevista & Respuestas

Respuesta modelo

At my previous company, the team wanted to use a new NoSQL database for a feature that had complex relational queries. I believed a relational DB was the better fit. I prepared a short technical writeup comparing both approaches on our specific access patterns and brought it to the next design review. We ran a small spike with both options and the data supported my recommendation. The team switched approaches. The key was bringing data, not opinions — and making it easy for people to change their mind without losing face.

Respuesta modelo

We had three weeks to ship a real-time feature that required WebSockets — something I'd never used in production. I blocked out mornings for focused learning: built a throwaway prototype first, read the RFC, then examined how larger open-source projects handled edge cases like reconnection and message ordering. I also paired with a colleague who had WebSocket experience for code reviews. We shipped on time and the feature had no production incidents in the first quarter.

Respuesta modelo

Our customer-facing API had a 95th-percentile latency of 800ms. I profiled the slowest endpoints and found three N+1 query patterns in our ORM layer. I rewrote those queries with explicit joins and added a Redis cache for a heavily read user-permissions lookup. Latency dropped to 120ms at p95. The harder part was convincing the team to invest the time — I built a simple dashboard that tied latency directly to conversion rate, which made the business case obvious.

Respuesta modelo

We launched a recommendation feature that we'd built over two months, and it had near-zero engagement. We'd optimized for click-through but users found the suggestions irrelevant. I ran a post-mortem and we identified the root cause: we never talked to users before building. I wrote up the learnings as a one-pager and proposed we add a discovery phase to our feature development process. That process change outlasted the feature itself — we now have a consistent user interview step before any major build.

Respuesta modelo

At its core, you need two operations: write (given a long URL, return a short code) and read (given a short code, redirect to the original URL). For the short code, I'd use Base62 encoding of an auto-increment ID — that gives you ~3.5 billion codes with 6 characters. The write path hits a database and caches the mapping. The read path is purely cache-first with a fallback to the DB. For scale, reads massively outnumber writes, so the cache hit rate is critical. I'd add rate limiting on writes to prevent abuse, and store creation time, user ID, and click analytics separately to keep the hot read path lean.

Respuesta modelo

A process is an independent program in execution with its own memory space. A thread is a lightweight unit of execution within a process, sharing memory with other threads in the same process. Use threads when tasks need to communicate frequently and share state — they're cheaper to spawn and context-switch between. Use processes for isolation: if one crashes, others continue. In practice, I'd reach for threads for CPU-bound parallelism within a single service, and processes when I need memory isolation or need to run separate services. In Python, the GIL means threads don't give true CPU parallelism, so multiprocessing is often the right call for CPU-heavy work there.

Respuesta modelo

Eventual consistency means a distributed system will return the same value for a given key across all nodes — but not necessarily immediately. Writes propagate asynchronously, so reads in the window after a write might return stale data. I'd accept eventual consistency for things like social media like counts, user preference syncing across devices, or product inventory updates in a catalog where being slightly stale for a second or two causes no harm. I would not accept it for financial transactions, authentication tokens, or anything where stale data could cause incorrect business outcomes or security issues.

Respuesta modelo

In Java, the JVM uses a generational garbage collector. The heap is split into young and old generations based on object lifetime. Most objects die young, so the collector runs frequent, cheap minor GCs on the young generation. Objects that survive multiple collections get promoted to old gen, which is collected less often but more expensively. The G1 and ZGC collectors minimize stop-the-world pauses by doing most work concurrently. The tradeoff is memory overhead and unpredictable pause latency — GC is essentially trading throughput for automatic memory management. In latency-sensitive systems I've tuned heap sizes and GC settings, and in extreme cases moved hot-path allocations off-heap to avoid GC pressure entirely.

Respuesta modelo

First, I assess severity and exploitability — is this actively exploited in the wild, and does our usage pattern expose us? If yes, I escalate immediately to the team lead and security contact, and we treat it as an incident rather than a normal task. I'd look for a patched version of the library first. If none exists, I'd check if we can mitigate in our code while we wait for a patch or switch libraries. I'd communicate status clearly: who's affected, what the risk is, what we're doing, and what the timeline is. Sprint scope changes as a result — the vulnerability fixes land first.

Respuesta modelo

I don't touch anything without understanding it first. I'd spend the first day mapping the code's entry points, data flow, and key dependencies — running it locally and tracing requests through the system. Before writing feature code, I'd add characterization tests around the areas I need to change: tests that capture current behavior, not ideal behavior. These are my safety net. Then I'd make the smallest possible changes to add the feature, and add proper unit tests for the new code. I'd resist the urge to refactor everything I hate — that's a separate conversation with the team, with its own timeline and risk assessment.

Respuesta modelo

I'd make sure I fully understand their approach before pushing back — sometimes complexity is there for good reasons I'm not seeing. I'd ask questions to understand the constraints they're optimizing for. If I still think my approach is better, I'd write a brief comparison: the tradeoffs of each option, what we gain and give up, and my recommendation with reasoning. I'd present it as 'here's what I see — am I missing something?' rather than 'I'm right.' If after discussion the senior engineer still prefers their approach, I'd commit to it and execute it well — architectural disagreements are worth one good debate, not an ongoing argument.

Respuesta modelo

I won't give a single number for an unclear scope — that number will be wrong and I'll be held to it. Instead, I'll ask clarifying questions to understand the core requirement and identify the riskiest unknowns. Then I'll give a range: 'Based on what I know, this is 3–5 days, but these three open questions could push it to 2 weeks.' I'll name what I need to narrow the estimate: a decision on the edge case behavior, access to a specific system, or a day to spike the unfamiliar part. Good estimates are a conversation, not a deadline pulled from the air.