The Software Engineer role at Wells Fargo covers backend microservices, web applications and data-processing pipelines in a regulated banking environment. Reported initiatives include modernizing legacy banking platforms, building payment systems, moving applications to cloud-native architectures on Azure and implementing payment standards such as ISO20022. Engineers work alongside product managers, scrum masters, business analysts and security specialists, and they also do code reviews, write unit and integration tests, maintain CI/CD pipelines and support production.
The must-have skills listed for the role are Java with Spring Boot or a full-stack JavaScript/TypeScript setup (Angular or React), relational databases (SQL, Oracle, PostgreSQL) and Git. The nice-to-haves are Azure, Docker, Kubernetes, message brokers such as Kafka and ActiveMQ, and CI/CD tooling. This explains why the reported questions go into Java garbage collection and JVM memory areas, the equals/hashCode contract behind a HashMap, the Spring Boot lifecycle and dependency injection, ACID and normalization, and asynchronous service communication through Kafka.
Candidates describe the live interviews as weighted more toward conceptual technical discussion and project walkthroughs than toward competitive-programming puzzles. They also say interviewers often give hints when a candidate gets stuck. Prepare to explain how something works and why you chose it, not only to produce an answer. Some candidates also report being interviewed by engineers outside their own stack, so your fundamentals should hold up without the vocabulary of your usual framework.
Separately, some candidates report a cohort-based hiring process for certain roles, especially campus and contract positions, with group presentations and breakout rooms before individual interviews on the same day. Candidates do not tie this to a particular stage of the six, so ask your recruiter whether your role uses it.
Online Application
reportedCandidates describe this stage simply as submitting the application. Treat the resume as material for every later round, because candidates report that interviewers question past projects in depth: the architecture, the technologies, the challenges and the business impact. List the must-have skills you actually have (Java/Spring Boot or a JavaScript/TypeScript framework, a relational database, Git), and name any nice-to-haves you have used for real: Azure, Docker, Kubernetes, Kafka, ActiveMQ, CI/CD. Some locations reportedly give weight to academic record, so keep your transcript details accurate and ready.
What to demonstrate
- Whether the resume shows the must-have stack for the role: Java with Spring Boot or a modern JavaScript/TypeScript framework, a relational database, and Git
- Whether every listed project is one you can explain in terms of architecture, technology choices, the hardest problem and the outcome, since later rounds reportedly probe projects in depth
- Whether nice-to-have tools such as Azure, Kafka or Kubernetes appear only where you used them, rather than as keywords you cannot discuss
How to prepare
- Map each resume bullet to a skill from the role's must-have or nice-to-have list, and cut any bullet you could not defend through two follow-up questions
- For each project on the resume, write three lines: the architecture in one sentence, the hardest technical problem, and a measurable result
- If you mention cloud migration, messaging or CI/CD, write down the specific service, broker or pipeline you worked with, because those topics come up in reported design and fundamentals questions
Automated Assessment
reportedCandidates report that the automated assessment runs on HackerRank. Candidates report that some teams read assessment submissions manually in later rounds to judge coding style and attention to detail. So passing the tests is only part of the job: the code should also read cleanly and handle edge cases. The reported coding questions include counting palindromic subsequences, implementing an LRU cache, counting inversions with merge sort, building a queue from two stacks, and explaining HashMap collision handling. These questions are not tied to the assessment itself, but they show which categories to drill before it.
What to demonstrate
- Whether the submission passes hidden cases such as empty input, a single element, all-equal elements and the largest allowed values
- Whether the chosen approach fits the stated input bounds, for example O(n log n) inversion counting instead of the O(n^2) pair check on large arrays
- Whether the code is readable enough to hold up if a later interviewer opens it: clear names, short comments at the non-obvious steps, no dead code
How to prepare
- Practise in HackerRank's editor with the language you will use, including reading input from stdin and printing exact output formats
- Drill the reported coding categories: an LRU cache with a hash map and a doubly linked list (O(1) get/put), inversion counting during merge sort (O(n log n)), a two-stack queue (amortised O(1)), and interval DP for counting palindromic subsequences (O(n^2))
- Before each submission, reread the loop bounds and base cases, then add a one-line comment above every step a reviewer would have to reverse-engineer
Recruiter Screening Call
reportedCandidates describe the recruiter screen as a call to align on role expectations, location preferences and basic qualifications. Use it to learn two things that shape the rest of your preparation. The first is which stack the team works in (Java/Spring Boot backend, Angular or React front-end, or data pipelines). The second is what the later rounds cover. Candidate reports describe a hybrid work arrangement, so settle location and in-office expectations on this call rather than at offer time.
What to demonstrate
- Whether your location and work-arrangement expectations match the role's
- Whether your stack, degree and experience line up with the basic qualifications in the posting
- Whether you can summarise your most relevant project clearly and briefly to a non-engineer
How to prepare
- Prepare a short walkthrough of one project that names the stack, your specific role and one measurable result, in terms a non-engineer can follow
- Have your answer on location and hybrid schedule ready, and ask which office and in-office pattern the team uses
- Ask which technologies the team uses and what the next rounds cover, then weight the plan below toward that answer
Core Interview Phases
reportedCandidates describe this stage as technical and behavioral interviews that often lead into a Superday. Candidates do not tie specific questions to this stage, but the reported questions by category show what the technical conversations can draw on. Reported core Java and OOP questions include the four OOP principles applied to a real project, threads versus asynchronous code and race conditions, garbage collection and JVM memory areas, the Spring Boot lifecycle and dependency injection, and REST versus SOAP. Reported database questions include complex joins and window functions over transaction history, ACID, normalization trade-offs, ETL data quality and encryption at rest. Candidates also report being questioned in depth on past projects, and SQL and database concepts are reported as tested across almost all technical rounds.
What to demonstrate
- Whether you explain mechanics as well as definitions, for example how a HashMap chains colliding keys and why equals and hashCode must agree for a custom key
- Whether your SQL is correct and explainable: join types, where a window function is evaluated relative to WHERE, and which index would serve the query
- Whether your account of a past project holds up when pushed a level deeper, on the decision you made and the alternative you rejected
- Whether you use a hint to move forward, since candidates report that interviewers often give one
How to prepare
- For each core Java topic (GC and memory areas, HashMap internals, thread safety, Spring dependency injection), write a short explanation that includes one example of it going wrong, such as a mutable HashMap key or a check-then-act race
- Write one transaction-history query that uses a join, a subquery and a window function, then explain the order in which it is evaluated
- Rehearse your main project to two levels of follow-up: what you built, and why you chose it over the obvious alternative
- Practise saying out loud what you are stuck on, so that a hint can land on the specific gap
Superday Interviews
reportedCandidates describe the Superday as back-to-back technical and behavioral panels with several team members. Because the panels run back to back, the main risks are consistency and stamina: the same project facts told to several interviewers in a row, and technical answers that still go past the happy path late in the day. Reported design questions, not tied to a specific round, include real-time transaction processing, a rate limiter for public banking APIs, asynchronous microservice communication through Kafka or Redis, data consistency across databases in a payment system, and migrating an on-premises application to Azure. Reported behavioral questions, also not tied to a specific round, include resolving a technical conflict, working to a tight deadline with unclear requirements, and taking code-review feedback.
What to demonstrate
- Whether technical answers go past the happy path, for example duplicate requests and partial failure across services in a payment flow
- Whether your stories stay consistent across several panels on the same day: team size, timeline and your own role
- Whether behavioral answers have a clear situation, your own actions and a result, told as a conversation rather than recited
How to prepare
- Rehearse one payment design end to end: idempotency keys on the write API, an outbox or saga instead of a distributed transaction, and reconciliation for the cases that still slip through
- Design a rate limiter for a public API: token bucket versus sliding window, where the counters live, the key (client, account or IP), and what the caller receives when limited
- Fix the facts of each story on one page before the day, and check every retelling against that page
- Run a mock block of back-to-back sessions so you know how your answers hold up in the third hour, not only the first
Final Offer Phase
reportedCandidates describe the final stage as waiting for the offer, and they report administrative delays here, including HR and compensation approvals that can stretch the overall timeline. Candidate reports describe negotiation as possible but structured, with compensation set by role level and location. So confirm the level and location before you discuss numbers. Use the wait to keep practising rather than pausing, in case the process adds another conversation.
What to demonstrate
- Whether level, location and hybrid schedule are confirmed before you compare or negotiate numbers
- Whether your follow-ups are polite and spaced out, rather than read as pressure during a delay candidates report as common
- Whether any competing offers or market data you cite are specific and verifiable
How to prepare
- Ask the recruiter which level the offer is at and which location it assumes, and write both down
- Prepare the data you would negotiate with, such as a competing offer or a level-matched market figure, and know which part of the package you care about most
- Set a follow-up cadence with the recruiter, and keep your coding and SQL practice going until the offer is signed
5 candidate reports. Individual accounts describe a particular role and hiring cycle.
Wells Fargo Financial Analyst interview: three structured superday sessions
The process felt organized and standardized, especially at the superday. I completed HireVue and, about a week later, attended an in-person final round with three interviews of roughly 30 minutes each. Two were technical and one was behavioral. Everything ran smoothly, with a familiar rhythm across interviewers. The technical sessions covered accounting and ratios, including debt and equity conce…
Read full experienceWells Fargo Financial Analyst interview: HireVue to superday
After I applied, the process began with a virtual question screen that felt more like a proctored exam than a conversation. I was asked why I wanted the role and then answered many behavioral prompts. It was awkward more than difficult, and I wished it felt more human. That led into HireVue again before anything live. The early video rounds were not very technical; they were mostly open ended and…
Read full experienceWells Fargo Software Engineer Interview Experience: Broad assessment and a condescending later call
After the recruiter stage, I took a HackerRank-style online assessment that combined multiple choice and coding. It focused on DSA and practical problem-solving. Some versions also included aptitude and general computer-science questions. The platform questions did not always match what I expected, but I pushed through and moved to live rounds after passing. The technical interviews felt more lik…
Read full experienceWells Fargo Senior Software Engineer Interview Experience — From Kafka System Design to an AI Grilling with the Hiring Manager
View report detailsWells Fargo Credit Risk Modeler Interview Experience — HR Screen, Technical Interview, 48-Hour Take-home Case Study, and Behavioral Fit
Position: Credit Risk Modeler (Associate Level) Location: Charlotte, NC (Hybrid) Rounds: HR Screening → Technical Interview → Case Study → Behavioral Fit Interview Process Recap ① HR Phone Screen (30min) Brief self-introduction, "Why Wells Fargo?" Confirmed my understanding of Credit Risk Modeling (PD/LGD/EAD basics). Asked one behavioral question: "Describe a time you worked with incomplete data…
Read full experiencePracHub editorial advice for the preparation topics above.
Treating the HackerRank assessment as pass/fail and submitting code that passes the samples but misses edge cases or cannot be read
Candidates report that some teams read assessment submissions manually in later rounds. Before you submit, trace the empty input, a single element and duplicates, check the loop bounds, and add a one-line comment at each non-obvious step. If you run out of time, a correct and clearly commented slower solution is safer than a clever one that fails hidden cases.
Answering core Java and Spring questions with textbook definitions instead of mechanisms
Reported questions ask how things work: HashMap collision handling, garbage collection and JVM memory areas, the Spring Boot lifecycle, how dependency injection improves testability, and preventing race conditions. For each, be ready with the mechanism and one failure. For example, a key whose hashCode changes after insertion can no longer be found. Since Java 8, a crowded bucket becomes a tree once it passes a threshold. A check-then-act on shared state needs one atomic operation or a lock. Constructor injection lets a test pass in a fake.
Designing a payment or transaction system as boxes and arrows, with no plan for retries, partial failure or cross-database consistency
Reported design questions ask directly about data consistency across databases in a payment system and about real-time transaction processing. State the failure first. A client retries after a timeout, and one service commits while another does not. Then give the mechanism: an idempotency key on the payment API, an outbox or saga with compensating steps instead of a distributed transaction across services, and reconciliation for what still slips through. Say which step you would not retry automatically.
Preparing algorithms and neglecting SQL, then stumbling on a multi-join window-function query or an ACID question
SQL and database concepts are reported as tested across almost all technical rounds. Practise writing a transaction-history query with joins, a subquery and a window function by hand. Know that window functions are evaluated after WHERE and GROUP BY, so filtering on one needs a subquery. Be able to explain each ACID property with a concrete failure it prevents, and when denormalizing is worth the integrity cost.
Telling project and behavioral stories that sound recited, or that change between Superday panels
Superday panels run back to back, and candidates report being questioned in depth on past projects. Write down the facts that must not change between tellings: team size, timeline, your own role and the measured result. Prepare four or five STAR stories you can adapt, and tell them as a conversation. Stop to check whether the interviewer wants more depth on the technical side or the people side.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Explain the difference between a stack and a queue, and implement a qu…
Explain the difference between a stack and a queue, and implement a queue using two stacks.
Approach
- Walk one small example through your approach before writing the whole thing.
- State the target complexity and say which constraint rules the naive version out.
- Name the brute-force solution and its complexity before improving on it.
Follow-up
- How does this change if the input no longer fits in memory?
- Which test case would catch an off-by-one here?
Write a function to count all the palindromic subsequences in a given …
Write a function to count all the palindromic subsequences in a given string.
Approach
- Name the brute-force solution and its complexity before improving on it.
- State the target complexity and say which constraint rules the naive version out.
- Restate the input: its shape, its size, and what is guaranteed about it.
Follow-up
- What is the worst case, and how likely is it on real data?
- Which test case would catch an off-by-one here?
Design and implement a Least Recently Used (LRU) Cache.
Design and implement a Least Recently Used (LRU) Cache.
Approach
- State the target complexity and say which constraint rules the naive version out.
- Choose the data structure from the access pattern, not from familiarity.
- Name the brute-force solution and its complexity before improving on it.
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 does a hashmap handle collisions internally, and what is the signi…
How does a hashmap handle collisions internally, and what is the significance of the equals and hashCode methods in a custom class key?
Approach
- Walk one small example through your approach before writing the whole thing.
- Restate the input: its shape, its size, and what is guaranteed about it.
- Choose the data structure from the access pattern, not from familiarity.
Follow-up
- How does this change if the input no longer fits in memory?
- Which test case would catch an off-by-one here?
Merge partitioned event streams into one ordered feed with bounded lateness
The read-model service consumes 64 log partitions carrying about 4,000 events per second in total. Each partition is ordered within itself, but partitions drift by up to 30 seconds, and the activity feed must present a tenant's events in occurred_at order. Produce the merge. State its complexity, the buffer it requires in events and in bytes, what happens when one partition is idle, and what you do with an event that arrives after you have already emitted its position. Payloads average 1 KB.
Approach
- Merge with a min-heap over the 64 partition heads keyed on (occurred_at, event_id): O(log P) per event and O(n log P) overall. The tie-break on event_id is what makes the output deterministic when two partitions carry the same millisecond, which matters because the feed is paginated and a non-deterministic order reorders pages under the reader.
- Emitting the heap head is only correct once every partition has produced everything up to that timestamp, so the emit condition is a watermark: the minimum across partitions of the highest occurred_at seen, less the allowed lateness. Events are held until the watermark passes them, which is what turns individually ordered streams into a jointly ordered one.
- Size the buffer from the lateness rather than guessing: 4,000 events per second times 30 seconds is 120,000 buffered events, and at 1 KB each about 120 MB of heap. That number is the real price of the ordering guarantee and belongs in front of whoever asked for it.
- Handle the idle partition explicitly, because it fails the feed rather than corrupting it: a partition with no traffic never advances its own maximum, so the watermark freezes and output stops entirely. Either every partition emits a periodic idle marker carrying the broker's current time, or the watermark falls back to wall clock for a partition silent beyond a threshold.
- Choose the late-event policy from what the projection is keyed on. The projection upserts on (aggregate_id, aggregate_version) and discards a version it has already applied, so a late event is safe to apply out of order and correctness never depended on the merge at all. Apply it, recompute the affected feed page, and count lateness so the 30-second budget can be re-derived from data rather than folklore.
- Say what the merge does not buy: ordering is guaranteed within one aggregate by the log's partitioning, and no watermark makes the cross-aggregate order authoritative. Two events from different aggregates in the same millisecond have no true order, so the feed's order is a presentation choice that must be stable rather than correct.
Worked solution 35 min
- Write the heap comparator on (occurred_at, event_id) and the per-partition head refill.
- Write the watermark computation and the emit-loop condition, then list which buffered events are held at a chosen instant.
- Compute the buffer at 4,000 events per second, 30 seconds and 1 KB per event, and state what fraction of a worker's heap that represents.
- Add the idle-partition marker and trace the watermark with one silent partition, both with and without the marker.
- Write the late-event path and name the key that makes applying it safe.
Follow-up
- The lateness budget is raised to five minutes. What is the new buffer, and what besides memory changes?
- The consumer restarts. Where does it resume from, and what does the feed look like for the first 30 seconds?
- One partition is ten minutes behind because its producer is slow. Do you stall the feed or emit without it?
Explain why the owner filter ignores the listing index
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.
- Answer the two negatives explicitly. owner_user_id alone is not a left prefix of the new index, so it degrades to a full scan of the index at best. Ordered by updated_at, the query still seeks on the (tenant, owner) pair but must sort, because only created_at is ordered within that pair.
- Measure both sides with EXPLAIN (ANALYZE, BUFFERS) and compare estimated against actual rows at the lowest node — a 2M-versus-200 misestimate there is usually what chose the plan, and adding an index will not fix a statistics problem.
Worked solution 25 min
- Load 2M resource rows across 5k owners in one tenant, run the query under EXPLAIN (ANALYZE, BUFFERS), and record the node reading the most rows plus the Sort Method line.
- Create (tenant_id, owner_user_id, created_at DESC) concurrently and re-run, confirming the Sort node is gone and actual rows fall to about 20.
- Run the two negative cases and capture the plan for each.
- Re-run the original tenant listing query to confirm the new index has not displaced the index that query depends on.
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?
- How do you roll this index out on a table taking 1.2k writes/second, and what does it cost on every insert from then on?
Find version gaps and relay lag with window functions
outbox_event holds event_id, aggregate_type, aggregate_id, aggregate_version, event_type, payload, status ('pending','published','dead'), attempts, created_at, published_at. A projection is missing rows and you must decide whether the relay skipped events or the consumer dropped them. Write three queries over the last seven days: one listing every aggregate_id whose published aggregate_version sequence has a hole, one giving per-day counts with a running total, and one returning the newest published event per aggregate. For each, say where the window function is evaluated relative to WHERE and LIMIT. PostgreSQL 16.
Approach
- Gaps: compute lead(aggregate_version) OVER (PARTITION BY aggregate_id ORDER BY aggregate_version) in a subquery, then filter next_version <> aggregate_version + 1 in the outer query. Window functions are evaluated after WHERE, GROUP BY and HAVING and before the outer ORDER BY and LIMIT, so the predicate cannot sit in the same WHERE clause and PostgreSQL 16 has no QUALIFY.
- Say what the seven-day filter does to the answer: it truncates every partition, so the first row per aggregate has no predecessor inside the window and a hole spanning the boundary is invisible. Widen the window, or join to resource.version as the authority for the true maximum.
- Running total: SELECT date_trunc('day', created_at) AS d, count() AS n, sum(count()) OVER (ORDER BY date_trunc('day', created_at) ROWS UNBOUNDED PRECEDING). An aggregate inside a window call is legal because grouping runs before windowing. The grouping key is unique per row here so ROWS and RANGE agree, but write the frame anyway — over ungrouped rows with tied timestamps the default RANGE frame pulls in every peer row and the total jumps.
- Newest per aggregate: DISTINCT ON (aggregate_id) ... ORDER BY aggregate_id, aggregate_version DESC is the cheap PostgreSQL-only form when an index matches that order; row_number() OVER (PARTITION BY aggregate_id ORDER BY aggregate_version DESC) = 1 is the portable form and needs a subquery for the same evaluation-order reason as the gap query.
- Interpret rather than report: no gaps plus a normal p95 of published_at - created_at points at the consumer; gaps or a fat lag tail point at the relay; rows still 'pending' with attempts > 0 point at neither, because they never left the database.
- Be explicit that the partial index on (created_at, event_id) WHERE status = 'pending' does not serve any of these — they read published rows. Name the index a recurring monitor would need, and say why a query run twice a year may not deserve one.
Follow-up
- Relay failover redelivers events. Does a duplicate break the gap query, and how would you detect one from this table alone?
- Turn the gap check into a continuous monitor rather than a query someone runs after an incident. What does it watch?
- The consumer claims it never received event 4,812,006. What do you look at, in what order?
Walk through the high-level architecture of a distributed system that …
Walk through the high-level architecture of a distributed system that requires real-time transaction processing.
Approach
- Name the read and write paths separately; they rarely have the same bottleneck.
- Name the failure you are designing for, then the recovery path.
- Choose a partition key and say what query it makes expensive.
Follow-up
- What breaks first when traffic grows ten times?
- How does this behave when that dependency is down for an hour?
How would you design a rate limiter to protect public-facing banking A…
How would you design a rate limiter to protect public-facing banking APIs?
Approach
- Fix the scope first: who calls this, how often, and what they do when it fails.
- State the consistency you need, and where you are willing to be stale.
- Choose a partition key and say what query it makes expensive.
Follow-up
- What would you drop to keep the system up under load?
- What breaks first when traffic grows ten times?
What is the difference between multi-threading and asynchronous progra…
What is the difference between multi-threading and asynchronous programming, and how do you prevent race conditions?
Approach
- State your assumptions explicitly before working the problem.
- Clarify what is being asked and what a complete answer contains.
- Say what you would check first and why it is the highest-information step.
Follow-up
- What assumption would you test first?
- How would you know your answer was wrong?
Choose what to break when replication lag reaches forty seconds
Reads are served from two replicas: 14k requests/second, about 85% absorbed by cache, so roughly 2.1k reads/second reach the database. Writes go to the primary at 1.2k/second. A tenant's backfill drives replication lag from under 100 ms to 40 seconds and it is still climbing. Sessions that have just written are pinned to the primary. Decide, endpoint class by endpoint class, whether to serve stale, fail, or route to the primary, and justify each choice with the load it adds to the primary. Then state what you would have built beforehand.
Approach
- Establish blast radius before cause, because mitigation and diagnosis have different deadlines. The decisive arithmetic is what happens if the database reads move to the primary: 2.1k reads/second on top of 1.2k writes/second roughly triples its operation count, on the node already absorbing the backfill that caused this. Reads and writes are not equal in cost, so treat that as an argument against a blanket move rather than as a capacity model - but it is enough to rule out routing everything to the primary.
- Classify endpoints by what staleness costs, not by how important they feel. Reads whose staleness is invisible - listings, search, counters - stay on the replica and return the watermark so the client can tell. Reads that immediately follow that same session's write keep their primary pin, which is a small bounded slice of traffic rather than the whole 2.1k/second. Reads that feed a decision with a side effect - authorisation, quota, the read half of a read-modify-write - must not be stale at all, because a 40-second-old permission row is the stale-permission failure wearing a different costume; those go to the primary or fail.
- Shed instead of queueing. If the must-be-fresh class alone exceeds the primary's headroom, refuse its lowest-value slice with 503 and a retry-after. A request queued behind a saturated primary holds a connection for a client that has already given up, and the retry storm that follows is what turns degradation into an outage. Bound the connection pool per role so the read fallback cannot consume the write path's connections - that bulkhead is the single decision that determines whether writes survive the next ten minutes.
- Attack the cause in parallel, since it is the one thing that can be stopped. The backfill is the load generator. A backfill that reads replication lag as its throttle signal and pauses above a threshold would have made this a non-event, with batch sizes small enough that each batch's write volume is a fraction of what a replica can apply per second. That is most of the answer to what should have existed beforehand.
- Name the mechanism you would prefer over session pinning. Capture the write position at commit and require the read path to be at or past it: compare the primary's pg_current_wal_lsn() at commit time against the replica's pg_last_wal_replay_lsn(), and fall back to the primary only for the specific request that is ahead of the replica. Session pinning is the cheap approximation and it over-pins - every read in the window goes to the primary whether or not it needed to, which is a share of the cost being paid right now.
Worked solution 35 min
- List the endpoints in three buckets - staleness invisible, staleness visible to the writer only, staleness unsafe - and attach the share of the 2.1k reads/second each bucket carries.
- Compute the primary's operation count under each routing option and mark which options are arithmetically available.
- Write the pin rule and its window, then the shed rule: which slice, what status code, what retry-after.
- Write the backfill's throttle predicate against a measured lag value, including its pause threshold and resume condition.
Follow-up
- Lag returns to normal in nine minutes. Which mitigation do you remove first, and which one stays permanently?
- A user reports their change did not save, and the write committed. Trace the path that produces that report and name the signal that would have shown it before the report arrived.
- The replica is 40 seconds behind but otherwise healthy. Do you take it out of rotation? What does that do to the other replica's lag?
Read latency spikes on a sixty-second sawtooth
The cached listing read path serves about 14k reads/second at an 85% hit rate. p99 sits at 35 ms for 57 seconds, jumps to 900 ms for 3, and repeats. During each spike the primary shows several hundred identical listing queries starting within the same millisecond, all carrying one large tenant's id. Cache entries use a 60-second TTL. Give the mechanism, the ordered checks, the fix, and the correctness hazard your fix must not introduce.
Approach
- Match the period to a configured number before theorising about load. A spike every 60 seconds against a 60-second TTL is an entry expiring, and you confirm it by correlating spike timestamps with the entry's write time rather than with the traffic curve. If the period had matched a cron or a GC interval instead, this is a different investigation.
- Establish the concurrency of the miss. Several hundred identical queries in one millisecond means the miss path has no coalescing: every request that arrives between expiry and repopulation recomputes. The herd size is that key's arrival rate times its recompute time, so at 1.2k reads/second for the hot key and a 250 ms recompute you expect about 300 concurrent misses, which matches what is observed.
- Add single-flight on the miss path so one caller per key recomputes under a short-lived lock while the rest wait for its result. Prefer stale-while-revalidate where the read tolerates it: return the expired value immediately and refresh asynchronously, which removes the latency spike rather than serialising it into a queue of waiters.
- De-synchronise the keys. Write TTLs with jitter, for example 60 seconds plus or minus 10%, so a deploy or a mass invalidation does not align every key on the same second and turn a per-key herd into a fleet-wide one.
- Name the hazard the fix must not introduce. Serving a stale listing is acceptable only because the API reports the projection watermark, and a reader that loaded the old value before a write can repopulate the entry after the invalidation, so the bounded TTL is what actually caps staleness rather than the delete. Keep read-after-write pinned to the primary for the writing session regardless.
- Verify on miss concurrency, not hit rate. The hit rate barely moves, because the herd is one miss multiplied; the number that must change is distinct origin queries per key per minute.
Follow-up
- The same sawtooth appears on a key that is invalidated on write rather than expired. Is that the same bug?
- How does your answer change if the recompute takes 4 seconds instead of 250 ms?
- What exactly does a client see during a stale-while-revalidate window, and how does the watermark let them tell?
For someone who has spent the last few years shipping features and reading other people's code, and who has not solved a timed problem from a blank file in a long time. Five days rebuild the primitives and the patterns that sit on them, working from invariants rather than remembered solutions, and the last two attach that back to the rest of the loop.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Assessment-style coding: reported data-structure problems
- Implement an LRU cache with a hash map plus a doubly linked list, and test eviction order, updating an existing key, and capacity 1
- Implement a queue with two stacks and explain why each element moves at most once, which makes the operations amortised O(1)
- Count inversions in an array during merge sort in O(n log n), and check the result against a brute-force O(n^2) count on random inputs
Deliverable: Three working solutions with complexity notes, and a list of the edge cases each one was tested against.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Worked solution ↗02DP and hashing, written as a HackerRank submission
- Count all palindromic subsequences of a string with interval DP in O(n^2), after asking whether identical subsequences at different positions count separately
- Write a short explanation of HashMap collision handling (bucket chaining, treeified buckets, resizing) and the equals/hashCode contract for a custom key, including what breaks if the key is mutated after insertion
- Solve two problems in HackerRank's editor, reading stdin and matching the exact output format, and comment each non-obvious step before submitting
Deliverable: A tested palindromic-subsequence solution, a HashMap explanation you could give out loud, and two submissions a reviewer could read cold.
Practice prompt ↗Practice prompt ↗03Core Java, OOP and Spring Boot fundamentals
- Explain the four OOP principles, each tied to a class or module from a real project, and write a thread-safe singleton, stating why the approach you chose is safe
- Explain garbage collection (GC roots, reachability, generations) and the JVM memory areas, then contrast multithreading with asynchronous code and name one race condition and its fix
- Build a small Spring Boot service with POST, PUT and GET endpoints and constructor injection, and write one test that swaps in a fake dependency
- Practise the Java Streams and Kafka consumer/partition topics from the question bank
Deliverable: A working Spring Boot service with a test that uses a fake dependency, plus short explanations of GC, concurrency and the four OOP principles.
Practice prompt ↗Practice prompt ↗04SQL and databases
- Write a transaction-history query with multiple joins, a subquery and a window function, then state where the window function is evaluated relative to WHERE and LIMIT
- Work through the worked SQL exercise on composite indexes and sort elimination, then do the window-function drill on version gaps and running totals
- Explain ACID with one concrete failure per property, and normalization versus denormalization with a case where each is the right call
- Describe an ETL pipeline with data-quality checks, and how you would protect sensitive customer data with encryption at rest and access controls
Deliverable: Two hand-written SQL queries with their evaluation order explained, and one-paragraph answers on ACID, normalization and pipeline governance.
Practice prompt ↗Practice prompt ↗Worked solution ↗05System design for payments and banking APIs
- Design a payment system that stays consistent through failover: an idempotent write API, an outbox or saga across services, and reconciliation
- Design a rate limiter for public-facing banking APIs, choosing the algorithm, the counter store, the limiting key and the rejected-request response
- Explain asynchronous service communication through Kafka: partitions, consumer groups, at-least-once delivery and how the receiver deduplicates
- Work the worked design exercise on replication lag, then sketch cursor pagination for a large dataset
Deliverable: Two design sketches (payments, rate limiter), each listing the failure it handles and the trade-off it accepts.
Practice prompt ↗Practice prompt ↗06Cloud migration, security and production debugging
- Outline a phased migration of an on-premises application to Azure: run old and new paths side by side, compare their outputs, keep a rollback path, and secure the data while it moves
- Explain TLS at the level of the handshake, certificates and what it does and does not protect, and explain CI/CD in terms of the risk it removes from deployment
- Work the debugging drill on the sixty-second latency sawtooth, then write the ordered checks you would run for a slow production response
- Optionally, work the coding exercise on merging partitioned event streams to practise ordering reasoning in messaging systems
Deliverable: A one-page migration plan with a rollback step, and a written ordered checklist for diagnosing slow production responses.
Practice prompt ↗Practice prompt ↗07Behavioral stories and a Superday rehearsal
- Write four or five STAR stories covering a technical conflict, a challenging project and how you measured success, a tight deadline with unclear requirements, code-review feedback, and getting unblocked without help from your tech lead
- Prepare a specific answer to why you want to work at Wells Fargo rather than a technology-first company, tied to the kind of work described for the role
- Run a mock day of back-to-back sessions (one coding, one design, one behavioral) and check that your project facts stay the same across all three
- Write down the facts that must not change between tellings: team size, timeline, your role, the result
Deliverable: A one-page story sheet with fixed facts per story, and notes from a mock back-to-back session.
Practice prompt ↗Practice prompt ↗Worked solution ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
Candidates report behavioral questions on conflict, challenging projects, unclear deadlines, code-review feedback and why they chose Wells Fargo. Candidate reports recommend the STAR format with four or five stories you can adapt. Candidates also report being questioned closely on past projects, so give every story specific actions you took yourself, a result you can measure, and facts that stay the same across back-to-back panels. Tell each story as a conversation, not a recital.
Describe a challenging project you worked on. What was your role, and …
Describe a challenging project you worked on. What was your role, and how did you measure success?
Approach
- Name the disagreement and how you resolved it with evidence.
- Close with what you would do differently, concretely.
- Pick a story where you made the decision, not one where you watched it.
Follow-up
- How did you know your change caused the improvement?
- What would you do differently if you ran that again?
How do you handle constructive feedback from a peer or a manager durin…
How do you handle constructive feedback from a peer or a manager during a code review?
Approach
- State the situation in two sentences and spend the rest on the reasoning.
- Close with what you would do differently, concretely.
- Give the blast radius: what could have broken, and what you measured.
Follow-up
- How did you know your change caused the improvement?
- What did you decide not to do, and why?
Tell callers you do not own that their integration breaks
A field in a write endpoint's response must change shape. You own the endpoint; you do not own the four internal callers or the outbound webhook consumers who read it. Describe a deprecation you were responsible for: what you shipped first, how you established who was actually reading the field, the window you gave and what set its length, what you did about the consumer who never moved, and how you decided removal was safe. Name the signal you used, not the announcement you sent.
Approach
- Establish the reader set empirically rather than from a wiki of owners: per-field usage counters keyed by principal, or access logs attributed to a consumer. State the blind spot of whichever you pick, since a consumer that reads the field only on a monthly job will not appear in a week of logs.
- Ship additive first. Populate the new field alongside the old one so no reader is forced to move, which is also what keeps a rolling deploy safe, because old and new instances answer the same requests at the same time and a rollback must still find the old shape present.
- Set the window from the slowest legitimate consumer's release cadence, not from your calendar, and decide separately what to do for a consumer with no release process at all, such as an external webhook endpoint you can only email.
- Convert silence into evidence before you rely on it: a short, low-traffic removal window that makes a still-dependent consumer fail visibly and loudly while you are watching, rather than at three in the morning after you have moved on.
- State the removal criterion as a measurement with a duration attached, such as observed reads at zero across a full billing cycle, and keep the change reversible for one release after removal.
Follow-up
- How would you detect a consumer that reads the field only during a monthly export?
- One caller refuses to move and has a commercial relationship behind it. What changes in your plan and what does not?
- After removal, what makes the change irreversible, and how long before you cross that line?
- 01
Tell me about a time you had to resolve a technical conflict within your engineering team.
- 02
Describe a challenging project you worked on. What was your role, and how did you measure success?
- 03
Why do you want to work at Wells Fargo instead of a traditional technology-first company?
- 04
Give an example of a time you had to work under tight deadlines with ambiguous requirements. How did you prioritize your tasks?
- 05
How do you handle constructive feedback from a peer or a manager during a code review?
- 06
How do you balance the need for rapid feature delivery with strict security and compliance standards?
Is this an official Wells Fargo interview guide?
No. It is independent research and practice material for the Software Engineer role at Wells Fargo. The rounds and questions reflect what candidates have reported, not a process Wells Fargo has published, and they change over time. Confirm the current format and scope with your recruiter.
PracHub interview research ↗How technical is the Wells Fargo Software Engineer interview?
Candidates report questions on computer science fundamentals, OOP and core Java, database design and SQL, and practical system architecture. They say the coding assessment runs on HackerRank, while the live interviews lean more toward conceptual discussion and project walkthroughs than toward competitive-programming puzzles. Prepare to explain how things work and why you chose them.
PracHub interview research ↗What is the typical timeline from the online assessment to an offer?
Candidates report roughly four to six weeks across six stages, with some reports ranging from three weeks to two months. The early stages (the HackerRank assessment and the recruiter call) tend to move quickly. Scheduling the Superday and the final HR and compensation approvals are where candidates report delays.
PracHub interview research ↗Does Wells Fargo offer remote work options for Software Engineers?
Candidate reports describe a hybrid arrangement, with engineering teams working part of the week from an assigned office. Arrangements can vary by team and location, so settle the office and in-office schedule with your recruiter at the screening stage.
PracHub interview research ↗How should I prepare for the behavioral portion of the interview?
Prepare four or five STAR stories you can adapt, covering teamwork, conflict resolution, unclear requirements, code-review feedback and delivering results. For each story, write down the facts that must not change (team size, timeline, your role, the measured result) so the story holds up across back-to-back panels. Tell each story as a conversation rather than a script.
PracHub interview research ↗Which language and technologies should I prepare in?
The role's must-have skills are Java with Spring Boot or a full-stack JavaScript/TypeScript setup (Angular or React), relational databases and Git. The nice-to-haves are Azure, Docker, Kubernetes, Kafka, ActiveMQ and CI/CD. The reported fundamentals questions are Java-heavy (garbage collection, HashMap internals, Spring dependency injection), so if you are a backend candidate, prepare in Java unless your recruiter says otherwise.
PracHub Software Engineer practice ↗What is the Superday?
Candidates describe it as a block of back-to-back technical and behavioral panels with several team members, and say the core interview stage often leads into it. Prepare for stamina and consistency: your project facts should match across every panel. Ask your recruiter how many panels your Superday includes and what each one covers.
PracHub Software Engineer practice ↗What if I get stuck during a live technical question?
Candidates report that interviewers often give hints and care more about your problem-solving process than a flawless answer. Say exactly what you are stuck on, state the part you are confident about, and build on the hint instead of starting over.
PracHub Software Engineer practice ↗Sources & methodology 3 sources ↗
Official role evidence, timestamped platform data and clearly labeled preparation advice.
- 01PracHub interview research ↗
PracHub editorial research into this company and role, maintained with this guide. Candidate-reported, not an employer publication.
platform · Accessed 2026-09-24 - 02PracHub Software Engineer practice ↗
Cross-company practice questions for this role.
platform · Accessed 2026-09-24 - 03PracHub interview preparation framework ↗
The framework the preparation plan follows.
platform · Accessed 2026-09-24