Interview guides · Columbia University

Columbia University Software Engineer Interview Guide

Columbia University Software Engineer interview guide: four reported rounds, scenario and behavioral questions, and a 7-day plan with answer outlines.

The 60-second brief

Columbia University is a university, so the engineering role here is about the software that supports teaching, research and campus operations rather than a commercial product. Candidates describe the work as building and maintaining internal applications, integrating third-party educational tools, and moving data between campus systems. Two groups come up by name: Research Compute Services, which supports researchers who need computational tools and data storage, and the Office of Computing and Instructional Technology (OCIT), which deploys software for classrooms. Candidates also mention software that has to talk to Audio/Visual equipment in lecture halls. Example projects they list include moving a legacy student-portal application to cloud infrastructure, building an API that connects research databases, and automating administrative workflows.

This guide is for engineers preparing for a Software Engineer interview at Columbia University, typically with a couple of years of professional experience (candidates describe two to five years, with some variation by team). It covers the four reported rounds, how to answer the scenario, experience and behavioral questions candidates report, the languages and tools the role lists, and a seven-day plan. It does not cover algorithm-puzzle practice, because candidates describe the technical conversation as straightforward questions and scenarios rather than whiteboard exercises.

Candidates report four rounds over roughly three to five weeks: a phone screening, two to three team interviews, a technical evaluation folded into broader conversation, and a final panel with cross-functional university teams.

Focus areas

Problem Solving
Scenario-Based Reasoning
Adaptability

Overview

Candidates describe the job as running real systems for real campus users. The work includes internal applications, integrations with third-party educational tools, secure data flow between campus systems, uptime and tier-level support for the applications you own, bug reports from faculty and students, and patches. That shapes the loop: the reported questions ask what you would do when something breaks, how you would handle an unclear request, and how you have worked with people outside engineering. Your answers should sound like someone who has operated software in production, not only written it.

The reported question mix has three parts. Scenario questions cover instructional software failing before a major exam, a researcher with extremely vague requirements, an application that works locally but fails on the university servers, and a security vulnerability in a legacy campus application. Experience questions ask for your resume and a quick-learning project, the architecture of the most complex web application you have built, your testing and coverage philosophy, an optimization story, and your code review process. Behavioral questions cover why Columbia, technical disagreement, explaining a complex issue to a non-technical stakeholder, slower or more bureaucratic pacing, and constructive feedback. Candidates describe the technical side as conversational rather than a whiteboard exercise, so the skill being exercised is giving an ordered, concrete answer out loud.

The stack the role lists is broad rather than deep. Candidates name Python, Java, JavaScript or C++ depending on the team, RESTful APIs, SQL and NoSQL databases, and troubleshooting and debugging as core. Cloud platforms (AWS, GCP or Azure), containers, Docker and Kubernetes, high-performance computing concepts and A/V integration appear as nice-to-have or less common topics. Review one language you can discuss comfortably, be ready to write and explain a basic query and read a query plan, practise tracing an error through logs, and know how a memory leak shows up in a web application.

The Columbia University interview process

These are the stages candidates describe, in the order they report them; the mix of video and in-person sessions varies by hiring department.

Phone Screening

Candidates report a first call that reviews your basic qualifications and experience and checks that you and the team agree on what the role involves, including work hours. Use it to deliver a clean account of your background and to collect logistics for the rest of the loop. Fit with the requirements candidates describe (a core language, web applications with REST APIs, SQL or NoSQL databases, debugging) is the thing to make easy to see.

What to demonstrate

How your experience lines up with the languages, web, API and database work the role lists
Whether expectations about the role and work hours match
How clearly you summarise your own background

How to prepare

Write a short walkthrough of your career that ends at why a university engineering team, and rehearse it aloud until it holds together without notes.
Prepare a one-line answer for each requirement candidates describe: your main language, a REST API you built, a database you managed, a bug you traced.
List your own questions: which teams you will meet next, what the team supports, and whether the role is on-site, remote or mixed.

Team Interviews

Candidates report two to three interviews with different teams you would work alongside. One example given is a video call with Research Compute Services followed by an in-person or virtual session with OCIT and related infrastructure teams. Candidates describe the tone as easygoing, with plenty of room for you to talk. Because the audience changes from session to session, adjust which of your projects you lead with: research data and computational tools for one group, classroom deployment and A/V integration for another.

What to demonstrate

Experience working with teams and users outside software engineering
Practical technical background relevant to each team's area
How you describe your own role in past projects

How to prepare

Read what each team supports and write two questions per team about its users and current infrastructure.
Prepare a cross-team troubleshooting story and an explain-it-simply story, each with a named outcome.
Pick two projects, one data or backend-heavy and one user-facing, and be able to explain the technical choices you made in each.

Technical Evaluation

Candidates report that the technical evaluation sits inside a broader conversation: short, straightforward technical questions mixed with scenario-based problem solving, rather than extended whiteboarding. Topics candidates list include how a frontend, backend and database fit together, finding bugs in existing code or tracing errors through logs, basic queries, relational versus non-relational databases, and data integrity. Less common topics are HPC concepts, containers and deployment pipelines. Treat the plain questions as real ones and answer them in an ordered way.

What to demonstrate

Working knowledge of the languages, frameworks and infrastructure a team uses
A step-by-step troubleshooting method when something fails
Database fundamentals such as basic queries and data integrity

How to prepare

Practise saying a diagnosis sequence aloud for the failure scenarios: restore service, gather evidence (logs, versions, configuration differences), isolate, fix, then prevent.
Be able to draw a standard web application with browser, API, database and background jobs, and say where each kind of error would show up.
Rehearse a concise answer on testing, code review and securing sensitive student or research data, with a concrete example of each from your own work.

Final Panel Interview

Candidates report a final panel, in person or virtual, with cross-functional university teams. The panel mixes technical and non-technical people, so the same project may need two explanations. Expect to repeat or deepen themes from earlier rounds, which makes a consistent set of stories important.

What to demonstrate

How you communicate with a mixed technical and non-technical audience
Collaboration with departments whose priorities differ
Consistency between your account of your experience and what earlier rounds heard

How to prepare

Prepare a two-level explanation of your most complex web application: one version in plain language about what it does for users, one with the architecture.
Rehearse your stories to the point where the outcome and your specific decision come first, since several people will hear them at once.
Prepare a closing set of questions about the users, current infrastructure challenges and how the team handles busy periods in the semester.

Where candidates lose points

Jumping to a fix in the failure scenarios, such as the instructional software crash or the application that works locally but not on the university servers

Give the order out loud: restore or work around first so the class or exam can continue, then collect evidence (logs, versions, configuration and environment differences), isolate, fix, and add a check so it does not recur. Naming the sequence before the guess is what makes the answer sound practised.

Starting to build when a researcher's requirements are vague

Ask who will use the tool, what data goes in, what output they need and by when, and what a successful first version looks like. Offer a small first deliverable they can react to, and say how you would confirm it with them before expanding it.

Treating the straightforward technical questions on testing, code review and security as too basic to answer properly

Give a concrete answer with an example: the kinds of tests you write and where, why coverage is a signal rather than a target, what you check in a review (correctness, tests, naming, security, who maintains it), and how you handle sensitive student or research data. Short and specific beats a generic statement of principle.

Telling optimization or cross-team stories without evidence or without your own part

Bring a baseline and a result for the slow query or slow code story, and make your decision the centre of the troubleshooting story. If a team claimed its part was fine, say what you showed them.

Giving a why-Columbia answer that would fit any employer, or implying a university role is a step down in pace

Anchor the answer in the work candidates describe, such as research data tools, classroom deployment or A/V integration, and in a project of yours that matches. Treat slower pacing as a real working condition you have a plan for, not something to apologise for.

Questions & practice

What would you do if a critical piece of instructional software failed right before a major exam?

Medium · Scenario & Problem Solving

Approach

Triage before touching anything: confirm the scope (one course, one building or every user), the exact symptom (login failure, error page, slow load) and when the exam starts, because the time left decides between fixing and working around.
Check the cheapest high-signal causes first: monitoring and recent changes (a deploy, config edit or patch), then shared dependencies such as single sign-on, DNS, an expired TLS certificate, database connectivity and server capacity under a sudden load spike.
Mitigate before root-causing: roll back the last change, restart or fail over, or add capacity. If it is a vendor-hosted product, open the highest-priority vendor ticket at once, since you cannot patch their code.
If service cannot be restored in time, give the instructor concrete fallbacks (delay or extend the window, an offline or paper version, a backup platform) and send short updates on a fixed rhythm through one channel, with one person owning communication.
Afterwards run a blameless review and add prevention: a change freeze around exam periods, a load test before known peaks, synthetic checks that alert before users do, and a runbook for this failure.

Follow-up

Restarting does not help and the exam is about to begin. What exactly do you tell the instructor?
The tool is a third-party hosted product. How does your plan change?
What would you put in place so the next exam period does not repeat this?

Walk me through your approach if a researcher asks you to build a tool, but their requirements are extremely v

Medium · Scenario & Problem Solving

Walk me through your approach if a researcher asks you to build a tool, but their requirements are extremely vague.

Approach

Start from the research question and today's workflow rather than features: what data goes in, what result comes out, who runs it and how often. Ask for a real sample input and an example of the output they want, such as a table or a figure.
Write the requirements back in plain language on one page, with two or three concrete input-to-output examples as acceptance checks, split into must-have and later. Get the researcher to confirm it before building.
Pin down the non-functional constraints early: data size (fits in memory on one machine or needs a cluster), whether it contains identifiable or human-subjects data (that changes storage and access rules), reproducibility (pinned versions, logged parameters) and who maintains it after you.
Build the smallest working slice against their real data, such as a script or small CLI, demo it early, and iterate. That surfaces misunderstandings for little cost and avoids building a general platform nobody asked for.
Treat scope changes explicitly: keep a short change list, re-estimate when an item is added, and leave a README and tests so the tool survives the handoff.

Follow-up

After every demo the researcher adds another feature. How do you manage scope without damaging the relationship?
The dataset turns out to be far larger than one machine can hold. What changes in your design?
Who owns and maintains the tool once you move on to other work?

How would you handle a situation where a deployed application works perfectly on your machine but fails on the

Medium · Scenario & Problem Solving

How would you handle a situation where a deployed application works perfectly on your machine but fails on the university servers?

Approach

Get the real failure first: server logs, stack trace, exit code or HTTP status, and when it started. Then reproduce it in an environment that mirrors the server (staging or the same container image) instead of guessing from the laptop.
Diff the environments systematically and change one variable at a time: runtime version, dependency versions (lockfile versus an unpinned install), OS and system libraries, environment variables and secrets, config files, working directory, timezone and locale.
Check the classic Linux-server gaps: filesystem case sensitivity (macOS is case-insensitive by default, Linux is not), file permissions and the service account the app runs as, absolute paths, and memory or disk limits.
Check the network path from the server: firewall rules, proxy settings, DNS, internal TLS certificates, and whether the database or API is reachable on the expected port from that host.
Fix it so it stays fixed: pin dependencies, build one artifact (for example a Docker image) that CI tests and the server runs, move config into environment variables, and add a startup check that fails loudly when required config is missing.

Follow-up

The logs show nothing and the process simply exits. What do you try next?
It works for a few hours after each deploy and then fails. Which suspects move to the top of your list?
How would you stop this class of problem from coming back?

What steps would you take if you discovered a security vulnerability in a legacy campus application?

Medium · Scenario & Problem Solving

Approach

Confirm without exploiting: use the smallest non-destructive check to verify the issue, record what it is, where it is and how you found it, and keep it out of public tickets and open chat channels.
Assess severity: what data is exposed (student records in the US fall under FERPA), whether it is reachable without authentication or from outside the network, and whether logs show signs it has already been used. A CVSS-style rating keeps the prioritisation consistent.
Report promptly through the institution's security channel and to the application owner. Do not quietly patch it alone, because disclosure, legal and notification duties may apply.
Contain first, then fix properly: restrict access (VPN only, disable the affected feature, a WAF rule) and rotate any exposed credentials. Then remove the cause, for example parameterised queries for SQL injection or upgrading a vulnerable library.
Legacy code rarely has tests, so write characterisation tests around the affected behaviour before changing it. Afterwards look for the same pattern in other applications and add dependency scanning so the next one is found earlier.

Follow-up

The original developers are gone and the app has no tests. How do you patch it safely?
The owner wants to wait until the end of the semester to fix it. How do you respond?
How would you determine whether the vulnerability has already been exploited?

Explain why the owner filter ignores the listing index

Medium · composite index · query plans · sort elimination

The only index on resource is (tenant_id, status, updated_at DESC, resource_id DESC). A new endpoint returns one user's resources across all statuses, newest created first: WHERE tenant_id = $1 AND owner_user_id = $2 ORDER BY created_at DESC LIMIT 20. On a tenant with 2M rows it takes 900 ms and EXPLAIN shows a sort above a large scan. Explain precisely why the existing index cannot serve it, give the index that can, and state which of these the new index still will not help: owner_user_id alone across tenants; the same query ordered by updated_at. PostgreSQL 16.

Approach

Separate the two jobs an index does. For filtering, a composite btree is seekable only on a left prefix, so with no predicate on status the scan can at best range over tenant_id and test owner_user_id per row; PostgreSQL 16 has no btree skip scan to jump the unconstrained column.
For ordering, the index is sorted by (status, updated_at) within a tenant and not by created_at, so the LIMIT cannot stop early: every matching row is read and then sorted. That is the 'Sort Method: top-N heapsort' line, and it is why the plan reads 2M rows to answer with 20.
Derive the replacement from the access path — equality, equality, then the ordering column: CREATE INDEX CONCURRENTLY ON resource (tenant_id, owner_user_id, created_at DESC). The scan seeks to the (tenant, owner) range and walks 20 entries in order, so the Sort node disappears along with the row-read.
Treat INCLUDE (title, status) as conditional, not free. An index-only scan still visits the heap for any row whose page is not marked all-visible, so on a table taking 1.2k writes/second the win depends on autovacuum keeping the visibility map current, and the wider index costs more on every insert.

Follow-up

90% of rows are status='active'. Would a partial index WHERE status = 'active' change your answer, and for which of the three queries?
A dashboard runs this for 40 owners in one page load. What changes about the design?

Stop tag and share joins from fanning out a page

Medium · join fan-out · semi-joins · many-to-many

resource_tag is (resource_id, tag_id) with PK (resource_id, tag_id); resource_share is (resource_id, shared_with_user_id, permission). The tagged-and-shared listing inner-joins resource to both, filters tenant_id, tag_id = ANY($2) and shared_with_user_id = $3, orders by updated_at DESC and takes 50. Pages come back with fewer than 50 distinct resources and the total in the header is far too high. Explain the row multiplication, rewrite both the page query and the count query so each is correct, and name the index each one needs. PostgreSQL 16.

Approach

Do the arithmetic against the predicates that are actually there. An inner join emits one row per matching child row, and both joins are filtered: tag_id = ANY($2) admits only the requested tags, shared_with_user_id = $3 admits one user's share rows. So a resource holding three of the requested tags and shared with $3 once yields three rows, not one — the multiplier is its count of matching tags times its share rows for that single user, and that second factor is 1 unless the table admits duplicate (resource_id, shared_with_user_id) pairs. LIMIT 50 then limits rows rather than resources, and COUNT(*) counts pairs — the header is the product, not the population.
Reject DISTINCT as the fix. It deduplicates after the product has been built, so the planner must materialise and sort the fanned-out set before the LIMIT can apply, and it leaves any SUM or AVG in the same select list wrong.
Rewrite both filters as semi-joins, keeping resource as the only row source: AND EXISTS (SELECT 1 FROM resource_tag rt WHERE rt.resource_id = r.resource_id AND rt.tag_id = ANY($2)) and the same shape against resource_share. A semi-join stops at the first match per resource and preserves the driving index order, so ORDER BY updated_at DESC, resource_id DESC LIMIT 50 still stops after 50 rows.
Count with the same predicates and no join at all: SELECT count(*) FROM resource r WHERE r.tenant_id = $1 AND r.status = 'active' AND EXISTS (...) AND EXISTS (...). Nothing multiplies a resource, so the number is the population.

Follow-up

The filter changes from 'any of these tags' to 'all of these tags'. Rewrite it and state what it costs relative to the ANY form.
A resource can be shared with the same user twice under different permissions. Does your count change, and should it?

Walk me through your resume and highlight a project where you had to learn a new technology quickly.

Medium · Technical & Experience

Approach

Keep the resume arc short: for each role, one line on scope and stack, chosen to connect to what this role lists (web applications, REST APIs, SQL and NoSQL databases, debugging). Then spend most of the answer on one project.
For the learning story, state why the new technology was needed (a constraint, not curiosity), then how you learned it: official docs and a tutorial, a throwaway prototype to test the risky part, reading existing code, and asking someone experienced to review early work.
Show real depth with one concrete detail you only learn by using the tool: a pitfall you hit, a configuration choice you made, or a trade-off you weighed against an alternative.
Close with the outcome (what shipped, who used it, what improved) and what you would do differently. Sink-the-answer mistake: listing many technologies with no depth on any of them.

Follow-up

What was the hardest concept in that technology, and how did you know you had understood it?
What mistake did you make because you were new to it?
How would you get productive in an unfamiliar codebase and stack in your first weeks?

Explain the architecture of the most complex web application you have built.

Medium · Technical & Experience

Approach

Open with who used the application and what it did, then sketch the components: client (single-page app or server-rendered), API layer, background workers or queue, database and cache, authentication, external integrations, and where it was hosted.
Trace one read request and one write request end to end, for example login through authentication to the API, the database query and the response. Following a request shows how the pieces interact better than listing boxes.
Explain the data model: the core tables or collections, the key relationships and indexes, and why you chose relational or document storage for this data.
Name two or three decisions you owned and their trade-offs, for example a monolith versus separate services, synchronous calls versus background jobs, or what you cached and how you invalidated it.
Cover operations: how it was deployed, how you monitored and logged it, how it behaved when a dependency failed, and the real load numbers you know. Do not inflate scale, and say what you would change today.

Follow-up

Where was the bottleneck, and how did you find it?
What happened to users when the database or an external service was unavailable?
If you rebuilt it today, what would you change first and why?

How do you approach writing tests for your code, and what is your philosophy on code coverage?

Medium · Technical & Experience

Approach

Describe a test pyramid: many fast unit tests on pure logic, fewer integration tests against real dependencies (a database in a container, the HTTP layer), and a handful of end-to-end tests on the user flows that matter most.
Test behaviour, not implementation details, so refactors do not break tests. For every bug, first write a test that reproduces it and fails, then fix the code and watch the test pass.
Treat coverage as a map, not a target: line coverage only shows code was executed, not that results were checked, and branch coverage is stricter. 100% coverage can still miss a wrong assertion, so use coverage to find untested risky code. Mutation testing measures whether tests catch changes.
Keep tests deterministic: control time, randomness and network calls with fakes or injected clocks, isolate test data, and run the suite in CI on every pull request.
Name the edge cases you habitually cover (empty and null inputs, boundaries, unicode, timezones, permission failures), and for untested legacy code write characterisation tests before changing it.

Follow-up

A team enforces 90% coverage but bugs still reach production. What is going wrong?
How do you test code that depends on an external API or a piece of hardware?
A test fails intermittently in CI. What do you do with it?

What is your process for reviewing a peer's code before it gets merged into the main branch?

Medium · Technical & Experience

Approach

Start with context: read the ticket and the description to understand the intent, check that CI is green, and for a non-trivial change pull the branch and run it. If the change is very large, ask for it to be split.
Review in priority order: correctness and design (does it solve the stated problem, edge cases, error handling, concurrency), then security (input validation, injection, authorisation checks, secrets in code, sensitive data in logs).
Then check performance and data: N+1 queries, missing indexes, unbounded loops or result sets, and whether migrations are reversible and backward compatible with the running version.
Check that tests cover the new behaviour and its failure paths, then readability and naming. Leave formatting to linters and formatters rather than comments.
Make comments useful: explain the why, label blocking issues versus optional suggestions, phrase uncertainty as a question, respond promptly, and move a long back-and-forth to a quick conversation.

Follow-up

The author disagrees with one of your blocking comments. How do you resolve it?
How do you review a large change in a part of the codebase you do not know?
What do you look for specifically when a change touches authentication or sensitive data?

One log partition stops advancing while the others drain

Easy · poison message · head-of-line blocking · consumer lag

Search results for a subset of tenants are hours stale; the rest are current. The projection consumer reports lag of zero on 15 of 16 partitions and 400,000 on one. Its error rate is flat and its CPU is idle. outbox_event has no pending rows older than a second, so the relay has published everything it holds. Identify the mechanism, give the ordered checks, and state what you do in the first ten minutes versus what you change permanently.

Approach

Read the lag distribution first. A slow consumer lags everywhere; zero on fifteen partitions and 400,000 on one is not throughput. Idle CPU on the stuck partition means the consumer is not advancing its offset at all, which points at one message it cannot get past rather than at a rate problem.
Exonerate the producer before touching the consumer. No pending outbox rows older than a second means the relay published, so the event exists in the log. This separates never sent from sent and never applied, which are different code paths and usually different owners.
Read the message at the stuck offset and the handler's log lines for its event_id. A flat error rate with no progress has two explanations and you must distinguish them: the handler is throwing and the retry loop is swallowing it, or the handler is blocking on something and never returning. Idle CPU with no error lines favours the second.
Mitigate before diagnosing further. Move the offending event to a dead-letter store and commit the offset past it. Adding consumers does nothing here, because a partition is consumed by exactly one member of the group, and the blast radius is every aggregate hashed to that partition, not only the aggregate that produced the bad event.

Follow-up

The dead-lettered event carried aggregate_version 7 and the projection had applied 6. What must the replay do differently if 8 and 9 landed in the meantime?
How do you show staleness to the user while the partition is behind, given the API already returns the projection's watermark?

Suggested practice checklist

Every day ends with something written or recorded, so you can hear where your answers are vague.

Day 1 — Map the loop and inventory your projects

Write out the four reported rounds (phone screening, team interviews, technical evaluation, final panel) and one line on what each is likely to need from you.
List the languages, database and API experience the role describes against your own, and mark any gap.
Pick five or six projects or incidents from your history that could carry a story: a launch, an outage, a migration, a disagreement, a piece of feedback, a slow query.

Deliverable: A one-page loop map plus a project inventory with one line per project on what you personally decided.

Day 2 — Phone screening narrative and why Columbia

Write and rehearse your career walkthrough, ending at why a university engineering team.
Write your answer on why you want this role at Columbia, using one named project as evidence.
Write the project where you learned a new technology quickly: what you had to learn, how you ramped up, what you shipped.

Deliverable: A written career walkthrough, a why-Columbia answer and a quick-learning story, each rehearsed aloud once.

Day 3 — Failure scenarios: write the diagnosis sequence

For the instructional software failing before an exam, write the sequence from first minute to follow-up, including who you tell and when.
For the application that works on your machine but fails on the university servers, list the environment differences you would check: versions, configuration, permissions, network, data.
For the vague researcher request, write the clarifying questions and the small first deliverable you would offer.
For the legacy application vulnerability, write the steps from verifying it to reporting it, containing exposure and scheduling a fix.

Deliverable: Four written step sequences, one per scenario, each readable aloud in a short, ordered answer.

Day 4 — Technical conversation: architecture, tests, code review

Draw the most complex web application you have built (clients, API, database, background work) and mark where each kind of failure would appear.
Write your testing approach and your view on coverage with one example of a test that caught a real bug.
Write your code review checklist and one example of a review that changed the outcome.
Review how a memory leak shows up in a web application and the tools you would use to find it.

Deliverable: An architecture sketch, a testing and coverage statement, and a review checklist, each with one real example.

Day 5 — Slow queries and log-based debugging

Write the slow code or slow query story with a baseline and a result, using EXPLAIN ANALYZE or a profiler output you have actually seen.
Work the SQL practice exercise on why an owner filter ignores a listing index, and say aloud what you would change.
Work the SQL practice exercise on tag and share joins fanning out a page, then explain the row multiplication in plain words.
Work the log-partition debugging exercise and narrate your steps as if to a colleague.

Deliverable: A written optimization story with before and after numbers, plus a spoken explanation of each practice exercise.

Day 6 — Cross-team and stakeholder stories

Write the cross-team troubleshooting story with the isolation steps and your own decisions.
Write the technical disagreement story, including what evidence settled it.
Write the explain-it-to-a-non-technical-stakeholder story, with the plain-language version you actually used.
Write the constructive feedback story, ending with the proof the change stuck.

Deliverable: Four written stories, each with a result line and a line naming your specific decision.

Day 7 — Panel rehearsal

Prepare your answer on adapting to slower or more bureaucratic pacing with a concrete example.
Run all stories and scenario answers aloud in order, once as if to a technical panel and once as if to a faculty member.
Prepare team-specific closing questions for Research Compute Services and OCIT style teams, and a question about the busiest times of the semester.

Deliverable: A recording or spoken run-through of every story, plus a final list of questions to ask each team.

Stories for a campus engineering team

Candidates report a conversational loop in which behavioral questions carry as much weight as the technical ones. The reported prompts ask about working across teams, explaining technical issues to people outside engineering, disagreement, pacing, and feedback. For a role that serves faculty, researchers and administrators, prepare stories where the other party was not an engineer, and where you can name your own decision and the outcome.

Describe a time when you had to troubleshoot an issue that spanned across multiple teams' domains (e.g., softw

Medium · Scenario & Problem Solving

Describe a time when you had to troubleshoot an issue that spanned across multiple teams' domains (e.g., software, network, and hardware).

Approach

Choose an incident where the symptom appeared in one place and the cause sat in another layer (application, network, hardware), and where you ran the investigation rather than forwarding a ticket. Open with the symptom and who was affected in two sentences.
Show the isolation method. Reproduce the failure, then cut the system in half: compare behaviour from inside and outside the suspect network segment, line up application logs with network or device logs on the same timestamps, and bypass or swap one component at a time. Say which evidence ruled each layer in or out.
Cover coordination. Bring each team in with a specific, testable question ("requests leave the app server but never reach the device, can you check your side for these timestamps?") instead of a verdict on whose fault it was, and keep one shared timeline of what was tried.
Close with the fix, who made it and what changed afterwards, such as a runbook, a monitor on the boundary between the systems, or a configuration that is now tracked. Give the outcome in concrete terms.
The story sinks when you were a bystander or when the cross-team part was only a handoff. Keep your own decisions at the centre.

Follow-up

One team insisted its part was fine. What evidence did you bring, and what did you do when it still was not accepted?
How did you know the cause you fixed was the real one and not a coincidence?
What would you instrument now so the next incident takes less time to locate?

Describe a time you had to optimize a slow piece of code or a slow database query.

Medium · Technical & Experience

Approach

Start from a baseline, not a hunch: the measured run time or latency, how you measured it (EXPLAIN ANALYZE, a profiler, slow-query logs, timing around the call) and the workload it ran on. A number before and a number after makes the story checkable.
Name the diagnosis. For a query it might be a sequential scan where an index should serve, a filter applied to a function of a column so the index cannot be used, an N+1 pattern from an ORM, a join that multiplies rows, or a sort over a large result. For code it might be the hot loop the profiler pointed to, repeated work that can be hoisted or cached, or a nested scan replaced by a hash lookup.
State the change and its price. An index speeds reads but slows writes and costs storage; a cache adds invalidation; a rewrite can alter ordering or null handling. Say how you confirmed identical results (compare outputs on a sample, run the test suite) and how you watched it after release.
Say what you decided and which alternatives you rejected, so the story shows judgement as well as the fix.

Follow-up

Why an index rather than caching the result, or the other way round?
How did you make sure the faster version returned exactly the same rows?
What happens to this fix if the table grows tenfold?

Why are you interested in working as a Software Engineer at Columbia University specifically?

Medium · Behavioral & Culture Fit

Approach

Build the answer from three parts: something specific about the work, a piece of your experience that connects to it, and what you want from your next role. Candidates describe work on internal applications, integrations with third-party educational tools, research data and storage, and software tied to classroom A/V; pick the one or two parts you find interesting.
Back the interest with evidence from your history: a tool you built for non-engineer users, a migration of an old system, a data pipeline for analysts. A claim such as "I like building for people who depend on the tool every day" needs the project that proves it right behind it.
Address the university-versus-company question directly and honestly. Say what draws you to supporting teaching and research, long-lived systems and faculty or staff as your users, without running down product companies and without leaning on the institution's reputation.
If you know which team you are meeting (Research Compute Services, OCIT), name what you would hope to work on there. The weak version of this answer would fit any employer unchanged, so cut any sentence that does.

Follow-up

What attracts you to a university rather than a product company?
Which of the problems you would expect on this team would you want to take first?
What would you want to learn here that your current role cannot teach you?

Tell me about a time you disagreed with a teammate or manager about a technical direction. How did you resolve

Medium · Behavioral & Culture Fit

Tell me about a time you disagreed with a teammate or manager about a technical direction. How did you resolve it?

Approach

Pick a disagreement about a real technical direction, such as a library, a schema, build versus buy, or a rollout approach, where both positions were reasonable. State the other person's position fairly in one sentence before giving yours.
Show how evidence settled it: a small prototype, a benchmark, or a written comparison on criteria like maintenance cost, who supports it afterwards and migration risk, or asking a third person to weigh in.
Give the outcome, including if you lost. Committing fully to a decision you argued against, or changing your own view, is a stronger story than winning.
Keep the other person a competent colleague. The story fails if they are a villain, or if the resolution was "I escalated" with no attempt to understand their reasoning.

Follow-up

What would have changed your mind?
In hindsight, was the decision the right one?
How did your working relationship with that person look afterwards?

Describe a situation where you had to explain a complex technical issue to a non-technical stakeholder.

Medium · Behavioral & Culture Fit

Approach

Choose a situation where the listener had a decision to make: a faculty member or manager asking why a feature cannot ship by a date, or why a system is down. Say who they were and what they needed to decide.
Show the translation. Lead with impact and options in their terms (what stops working, for whom, until when), use one concrete example from their world, drop internal jargon, and give a recommendation with the cost of each option.
Show how you checked understanding: ask them to restate the plan or say what they would tell their own colleagues, then send a short written summary.
Give the outcome, the decision they made, and what you would change in how you explained it. The story sinks if you simplified until it was wrong, or if they were only told something and never made a decision.

Follow-up

What did you leave out on purpose, and what did you refuse to oversimplify?
How did you respond when they pushed back or insisted on the original request?
What did the written follow-up say?

How do you adapt to an environment where project pacing might be slower or more bureaucratic than a startup?

Medium · Behavioral & Culture Fit

Approach

Say what slower or more procedural means in practice: approvals, scheduled change windows, sign-off from several departments with their own priorities. Then give a real example from your own work instead of describing your temperament.
Describe specific behaviours: learn the approval path early and start the long-lead items (access requests, reviews, procurement) first while you build; cut work into increments that fit the allowed windows; write decisions down so they survive handoffs; send brief status updates so nobody has to ask.
Show that you use the pace well: tests, documentation and handoff notes matter more when other staff will maintain the code later. If a process step ever caught a problem you would have missed, say so.
Be candid about what frustrates you and how you manage it. Do not disparage startups, and do not claim to love bureaucracy.

Follow-up

Tell me about a time a process step slowed something you felt was urgent. What did you do?
When would you push to change a process rather than work within it?
How do you keep momentum while waiting on another department?

Tell me about a time you received constructive feedback and how you applied it to your work.

Medium · Behavioral & Culture Fit

Approach

Choose real feedback that stung a little, about behaviour or technical practice: review comments on missing tests, unclear pull request descriptions, or telling people late that a deadline was slipping. A disguised strength ("I work too hard") will not land.
State what you heard and your first honest reaction, then what you did: asked for a specific example, wrote down a concrete change such as a checklist or a template, and asked the reviewer to check the next instance.
Show proof it stuck: the next occurrence went differently, the review comments changed, or you now apply the habit when you review other people's work.
The story sinks on defensiveness, blaming the person who gave the feedback, or having no change to point to afterwards.

Follow-up

What did you do in the first day after hearing it?
How do you ask for feedback now?
Tell me about a time you gave someone else difficult feedback.