cswork / libraryOpen practice workspace

Interview guides · MidFirst Bank

MidFirst Bank Software Engineer Interview Guide

MidFirst Bank Software Engineer interview guide: reported rounds, questions and how candidates describe the process.

The 60-second brief

As a Software Engineer at MidFirst Bank, you serve as a critical architect of the digital infrastructure that supports one of the largest privately owned banks in the United States. You are not just writing code; you are building secure, scalable, and efficient financial solutions that directly impact the daily banking experience of our customers. Your work bridges the gap between complex financial regulations and user-friendly digital products, ensuring that our systems are both robust and performant. This role requires a balance of technical precision and a deep understanding of the financial services domain. You will work within agile, cross-functional teams to modernize legacy systems, develop new features for our banking platforms, and maintain the high standards of security and reliability that MidFirst Bank is known for.

This guide is scoped to a Software Engineer candidate at MidFirst Bank.

Focus areas

  • SQL
  • Data Querying
  • Take-home Technical Assessment

The MidFirst Bank interview process

MidFirst Bank candidates report 3 rounds over 3-5 weeks. The stages below are what candidates describe, not a published process.

Initial Screening

A preliminary assessment to gauge your background and alignment with the team's needs.

What to demonstrate

  • A preliminary assessment to gauge your background and alignment with the team's needs
  • Depth in SQL

How to prepare

  • Be able to walk your CV end to end in two minutes, and say why this company specifically.
  • Have your salary expectations, notice period and location constraints ready, and ask for the rest of the loop in writing.

Technical Assessment

A take-home test to demonstrate your coding and database skills in a real-world context.

What to demonstrate

  • A take-home test to demonstrate your coding and database skills in a real-world context
  • Depth in SQL

How to prepare

  • Answer aloud and timed: How do you ensure data integrity when working with relational databases?
  • Answer aloud and timed: What are the trade-offs between different data structures in the context of high-volume banking transactions?

Final Conversation

A deep-dive discussion with the hiring manager about your technical approach and past projects.

What to demonstrate

  • A deep-dive discussion with the hiring manager about your technical approach and past projects
  • Depth in SQL

How to prepare

  • Answer aloud and timed: Describe a time you had to refactor legacy code to improve maintainability.
  • Answer aloud and timed: Explain the process you use to break down a large technical requirement into manageable tasks.

Where candidates lose points

Prioritize clarity in your code

Even in a take-home test, clean, well-commented code is far better than "clever" code that is hard to read.

Prepare your stories

Use the STAR method (Situation, Task, Action, Result) to structure your answers to behavioral questions. This ensures you are providing concise, evidence-based responses.

Understand the domain

Spend time learning about the challenges currently facing the banking industry, such as security and digital transformation.

Ask thoughtful questions

Your questions for the interviewers are just as important as theirs for you. Ask about team culture, technical debt, or how the team balances new features with system maintenance.

Questions & practice

Explain the process you use to break down a large technical requirement into manageable tasks.

Medium · Problem-Solving & Coding

Approach

  1. Restate the input: its shape, its size, and what is guaranteed about it.
  2. Name the brute-force solution and its complexity before improving on it.
  3. Choose the data structure from the access pattern, not from familiarity.
  4. State the target complexity and say which constraint rules the naive version out.

Follow-up

  • How does this change if the input no longer fits in memory?
  • What is the worst case, and how likely is it on real data?

What is your strategy for unit testing and ensuring code quality in a fast-paced environment?

Medium · Problem-Solving & Coding

Approach

  1. Restate the input: its shape, its size, and what is guaranteed about it.
  2. Name the brute-force solution and its complexity before improving on it.
  3. Choose the data structure from the access pattern, not from familiarity.
  4. State the target complexity and say which constraint rules the naive version out.

Follow-up

  • How does this change if the input no longer fits in memory?
  • What is the worst case, and how likely is it on real data?

Can you explain a challenging technical problem you solved and the specific steps you took?

Medium · Problem-Solving & Coding

Approach

  1. Restate the input: its shape, its size, and what is guaranteed about it.
  2. Name the brute-force solution and its complexity before improving on it.
  3. Choose the data structure from the access pattern, not from familiarity.
  4. State the target complexity and say which constraint rules the naive version out.

Follow-up

  • How does this change if the input no longer fits in memory?
  • What is the worst case, and how likely is it on real data?

How do you optimize a complex SQL query to improve application performance?

Medium · Technical & Domain Knowledge

Approach

  1. Name the grain you start from and join outward from it.
  2. Check whether any join is one-to-many before aggregating, or the sums inflate.
  3. Say which index the query would use, and what makes it unusable.
  4. Handle the rows that do not match: that is usually the actual question.

Follow-up

  • How does the query change if that join becomes one-to-many?
  • What happens to this when the table is ten times larger?

Hold a per-tenant active cap against concurrent creates

Hard · write skew · isolation levels · constraints

A tenant on the standard plan may hold at most 50 resources with status='active'. The create handler runs SELECT count(*) FROM resource WHERE tenant_id = $1 AND status = 'active', compares to 50, then inserts. Two creates arrive 3 ms apart on different instances and the tenant lands at 51. Name the anomaly, say whether PostgreSQL 16 READ COMMITTED or REPEATABLE READ prevents it and why, then give an implementation that holds the cap at READ COMMITTED with the exact statements. Finally, say what changes when the cap is 'at most one running export per tenant' on job_run.

Approach

  1. Name it: write skew. The two transactions read an overlapping set and write disjoint rows, so there is no row-level conflict for the engine to detect and each commit is individually legal.
  2. Rule out the levels precisely. READ COMMITTED takes a fresh snapshot per statement and takes no lock on the counted rows, so both see 49. PostgreSQL's REPEATABLE READ is snapshot isolation: it removes non-repeatable reads and phantoms within the snapshot but still admits write skew, because the anomaly is not a re-read of a changed row, it is a read of a set that a concurrent transaction invalidates. Only SERIALIZABLE closes it, by tracking the read dependency and aborting one transaction with SQLSTATE 40001 — a guarantee that exists only if the application re-runs the whole transaction from the read.
  3. Convert the set predicate into a single-row conflict: keep tenant.active_resource_count and run UPDATE tenant SET active_resource_count = active_resource_count + 1 WHERE tenant_id = $1 AND active_resource_count < 50 in the same transaction as the INSERT. Zero affected rows is the cap, returned as 409. The row lock serialises the decision at any isolation level, and contention is bounded to one tenant's row — which is also the fair-scheduling unit, unlike a global counter that would convoy every tenant behind one row.
  4. State the cost you just took on: a counter is a second source of truth that can drift, so every path that changes status must adjust it inside the same transaction, and a periodic reconciliation has to exist, with resource_revision as the authority for what the count should have been.

Follow-up

  • A resource moves from archived back to active. Which statements change, and what breaks if the counter update and the status change land in different transactions?
  • The cap becomes plan-dependent and a plan can change mid-month. Where does the number 50 live, and who reads it?

How do you ensure data integrity when working with relational databases?

Medium · Technical & Domain Knowledge

Approach

  1. Clarify what is being asked and what a complete answer contains.
  2. State your assumptions explicitly before working the problem.
  3. Say what you would check first and why it is the highest-information step.
  4. Work from the requirement backwards to the design.

Follow-up

  • What assumption would you test first?
  • How would you know your answer was wrong?

What are the trade-offs between different data structures in the context of high-volume banking transactions?

Medium · Technical & Domain Knowledge

Approach

  1. Clarify what is being asked and what a complete answer contains.
  2. State your assumptions explicitly before working the problem.
  3. Say what you would check first and why it is the highest-information step.
  4. Work from the requirement backwards to the design.

Follow-up

  • What assumption would you test first?
  • How would you know your answer was wrong?

Given a specific scenario, how would you architect a solution that balances speed with security?

Medium · Problem-Solving & Coding

Approach

  1. Fix the scope first: who calls this, how often, and what they do when it fails.
  2. Name the read and write paths separately; they rarely have the same bottleneck.
  3. Choose a partition key and say what query it makes expensive.
  4. State the consistency you need, and where you are willing to be stale.

Follow-up

  • What breaks first when traffic grows ten times?
  • How does this behave when that dependency is down for an hour?

Walk me through your approach to debugging a production-level issue in your preferred language.

Medium · Technical & Domain Knowledge

Approach

  1. Establish what changed and when, before forming any theory.
  2. Pick a bisection that eliminates candidates whichever way it turns out.
  3. Check the instrumentation before believing the symptom.
  4. Separate the trigger from the cause; the deploy is rarely the bug.

Follow-up

  • What would you look at first, and what would it rule out?
  • How would you tell a cause from a coincidence here?

Suggested practice checklist

Built from the rounds and topics MidFirst Bank candidates report.

Day 1 — Map the MidFirst Bank loop

  • Write out the reported sequence: Initial Screening, Technical Assessment, Final Conversation.
  • For each round, write one sentence on what it is judging, from the description above, and mark the one you are least ready for.

Deliverable: A one-page map of the 3 reported rounds, with the weakest marked.

Day 2 — Work SQL

  • Spend the session on SQL, which MidFirst Bank candidates report being tested on.
  • Write one worked example in SQL and time yourself on it.

Deliverable: One timed worked example in SQL.

Day 3 — Work Data Querying

  • Spend the session on Data Querying, which MidFirst Bank candidates report being tested on.
  • Write one worked example in Data Querying and time yourself on it.

Deliverable: One timed worked example in Data Querying.

Day 4 — Work Take-home Technical Assessment

  • Spend the session on Take-home Technical Assessment, which MidFirst Bank candidates report being tested on.
  • Write one worked example in Take-home Technical Assessment and time yourself on it.

Deliverable: One timed worked example in Take-home Technical Assessment.

Day 5 — Answer out loud: Technical & Domain Knowledge

  • Answer aloud, timed: How do you optimize a complex SQL query to improve application performance?
  • Answer aloud, timed: Walk me through your approach to debugging a production-level issue in your preferred language.

Deliverable: Spoken answers to 2 reported Technical & Domain Knowledge question(s), under time.

Day 6 — Answer out loud: Problem-Solving & Coding

  • Answer aloud, timed: Explain the process you use to break down a large technical requirement into manageable tasks.
  • Answer aloud, timed: Given a specific scenario, how would you architect a solution that balances speed with security?

Deliverable: Spoken answers to 2 reported Problem-Solving & Coding question(s), under time.

Day 7 — Dry run for MidFirst Bank

  • Run one full mock under time, then write down the two questions you most want to ask your interviewers.

Deliverable: A completed timed mock and two questions to ask.

Behavioural preparation

Behavioural rounds judge the decision you made and what it cost.

Describe a time you had to refactor legacy code to improve maintainability.

Medium · Technical & Domain Knowledge

Approach

  1. Pick a story where you made the decision, not one where you watched it.
  2. State the situation in two sentences and spend the rest on the reasoning.
  3. Give the blast radius: what could have broken, and what you measured.
  4. Name the disagreement and how you resolved it with evidence.

Follow-up

  • What would you do differently if you ran that again?
  • How did you know your change caused the improvement?

How do you handle edge cases when designing an API or a data transformation script?

Medium · Problem-Solving & Coding

Approach

  1. Pick a story where you made the decision, not one where you watched it.
  2. State the situation in two sentences and spend the rest on the reasoning.
  3. Give the blast radius: what could have broken, and what you measured.
  4. Name the disagreement and how you resolved it with evidence.

Follow-up

  • What would you do differently if you ran that again?
  • How did you know your change caused the improvement?

Estimate work you have never done and defend the range

Hard · estimation · backfills · expand-contract

You are asked to estimate a change you have never attempted: add a column to a 100-million-row table, populate it, move reads across, and drop the old shape. Give a range with the assumptions that generate it, including batch size, the signal your backfill throttles on, and wall-clock hours, and name the three unknowns that would move the number most. Then describe a real estimate you gave under comparable ignorance: how you expressed its uncertainty, what you committed to, and how wrong you turned out to be.

Approach

  1. Decompose into independently deployable steps before estimating anything: add the column nullable, write both shapes, backfill in batches, verify, move reads, stop writing the old shape, drop it. That is four deploys spread over days, and the calendar estimate is dominated by them rather than by the loop's runtime.
  2. Do the arithmetic aloud for the part that has arithmetic in it: batch size times number of batches times per-batch duration, at a write rate the primary can absorb alongside roughly 1.2k writes per second of production traffic. The loop is throttled by replication lag and lock waits, not by how fast it can issue statements.
  3. Price the schema step by its lock rather than its statement duration. In PostgreSQL an ALTER TABLE taking ACCESS EXCLUSIVE waits for every open transaction on that table while later queries queue behind it, so a millisecond change issued during a thirty-second analytics query stalls that table for thirty seconds. Adding a nullable column with a non-volatile default avoids a rewrite from version 11; a new index wants CREATE INDEX CONCURRENTLY, which cannot run inside a transaction block and leaves an invalid index behind if it fails.
  4. Express the answer as a range whose endpoints each trace to a stated assumption, then name the cheapest experiment that collapses it, which is almost always running one real batch against the real table and multiplying.

Follow-up

  • How do you verify the backfill genuinely finished, given rows written by production traffic while it ran?
  • Where does the backfill resume from after a worker is killed mid-batch, and what makes that resume point trustworthy?