Interview Basecamp
Interview questions
Software engineer interviews that are not a whiteboard puzzle still test how you work: what you roll back, how you read a latency graph, and what you refuse to ship on Friday. The questions below skip puzzle trivia and ask for the judgment hiring managers probe in screens and onsite conversations. Answer with the constraint, the option you did not pick, and how you knew the system was actually healthy afterward. Role prep for a software engineer turns that into a prep course of Learning Blocks you can drill, separate from a Job prep course tied to one posting.
Incidents, disagreements, and the work you chose not to start.
What interviewers look for
You noticed the failure, you had a way back, and you used it. Interviewers want the signal that told you to revert, how long users were exposed, and what you added so the next attempt was safer. A story that blames QA, or one where rollback was theoretically possible but you never practiced it, is weak.
What interviewers look for
You can explain their design as fairly as yours, and you can say what would have made you right. They listen for whether you committed after the decision. Candidates who relitigate the review, or who cannot recall the other person's constraint, sound difficult to work with.
What interviewers look for
The hotfix is the start. They want the customer impact, the gap that let it through, and one change to alerts, tests, or the design. A timeline with no follow-up is an on-call story, not an ownership story.
What interviewers look for
You found the specific stuck point, pointed at the next step, and left them able to finish. Interviewers discount heroes who rewrite the change themselves. They also discount vague coaching with no artifact: a pairing session, a failing test, a diagram.
What interviewers look for
A cost you could point at: incidents, lead time, or a change nobody would touch. They want who you convinced and what you explicitly delayed. Paying down debt because it felt cleaner, with no user or team cost, is a preference, not a decision.
How you choose a design and how you prove a system is sick or healthy.
What interviewers look for
You start from what the user must never see stale or lost, and from the read and write rates. A cache helps reads and creates invalidation problems. A queue absorbs bursts and adds delay. Stronger consistency costs latency. Interviewers want the failure you are buying, not a tool name.
What interviewers look for
A path: compare the deploy to the latency break, split by endpoint and dependency, and look at saturation before you rewrite anything. They want you to separate a slow dependency, a lock, a bad query plan, and a retry storm. Guessing the cache is the problem because caches are often the problem is not a method.
What interviewers look for
An additive change, a version or a compatible default, and a way to see who still calls the old shape. Interviewers want a removal plan with a date and a measurement, not a flag you will forget. Breaking clients and calling it their upgrade problem fails unless you truly control every caller.
What interviewers look for
The query you are serving, how selective the index is, the write cost, and whether the access pattern is stable. A new table needs a reason the existing one cannot represent the fact. They listen for measurement: explain, a slow log, or a known read path. Indexing every column is not caution.
What interviewers look for
You can name the shared state and the interleaving you suspect. A stress test that sometimes fails is a start; a deterministic test that forces the order is better. Interviewers want the invariant you are protecting. Hoping the race is rare enough is not a fix, and it is not a test.
The deadline, the page, and the requirement you are not sure you should build.
What interviewers look for
A smaller slice that is safe to ship, or a dated risk if you ship the whole thing. Interviewers want the conversation early, with the cut you recommend, not a Thursday surprise. Quietly working longer hours until Friday is not a plan.
What interviewers look for
You stabilize before you understand the history: impact, a recent change, a rollback or a failover you are allowed to use, and who else to wake. They want you reading the runbook and the graph, not refactoring an unfamiliar service in the dark. Leaving a note for the owners in the morning is part of it.
What interviewers look for
You ask what decision the data serves, how long it must live, and who can see it. Strong candidates offer a smaller retention, a coarser field, or a hash. Interviewers want you to raise it with the person who owns the requirement, not to silently collect more because the ticket said so.
What interviewers look for
You put the missing work on the table: migration, tests, rollout, the unknown dependency. They do not want a performance where you win the argument. They want the assumption that differs, and a willingness to cut scope so the dates can meet. Going silent and padding later helps no one.
What interviewers look for
You stop the bleeding first: quarantine it with an owner and a ticket, if the team allows that, and keep the signal honest. Then you find the nondeterminism. Interviewers dislike both extremes: deleting the test to go green, and leaving everyone blocked while you research it for two days with no communication.