The reported questions are fundamentals-first. Candidates describe Java as the usual primary language and list OOP, the collections framework, linked lists, and the Singleton and MVC patterns among the frequent topics. One report warns that candidates stumble by chasing advanced frameworks while neglecting collections and data structures. So the first half of your preparation should be the standard library and core data structures, explained from the inside: how a HashMap stores entries, why a hand-written linked list is rarely the right production choice, when a Singleton is a liability.
The second theme is your own project work. Candidates report a walk-through of a recent project's architecture, questions on performance bottlenecks and on debugging under pressure, and a question on designing a system from scratch. Reports stress explaining why you made a decision, not only how. That means each project you bring needs its rejected alternatives, its measured results and a clear statement of what you personally did. Reports suggest having at least three such stories ready and framing them as Situation, Task, Action, Result.
The third theme is working style. Reported behavioral questions cover your motivation for applying, managing several tasks at once, and how you give and receive technical feedback, and the last stage is described as a management-led fit discussion. Reports list cloud infrastructure, CI/CD pipelines and database optimisation as nice-to-have, so keep one example touching each if you have it, and use the SQL practice drills in the plan if database tuning is your weak spot.
Initial Technical Screen
reportedCandidates describe the first stage as a technical screen aimed at your coding skills. Reports add that data structures and basic algorithms usually underpin the technical rounds, and that Java is the typical primary language. Treat it as a fundamentals check: ask a clarifying question before you start, say your reasoning aloud while you work, and be exact about how the standard library behaves.
What to demonstrate
- Coding ability in your primary language, which candidates report is typically Java
- Command of data structures and basic algorithms
- How clearly you explain your logic while you solve
How to prepare
- Implement a singly linked list by hand with insert, delete, reverse and cycle detection, then say what each operation costs
- Explain HashMap internals (buckets, collisions, resizing) and when ArrayList beats LinkedList
- Give one example from code you wrote for each of encapsulation, inheritance, polymorphism and abstraction
- Practise restating an ambiguous prompt and asking one clarifying question before you write anything
Deeper Technical Evaluation
reportedCandidates describe the second stage as a more in-depth technical evaluation. The evaluation areas they list for the loop include core Java knowledge, how you structure applications and the trade-offs behind those choices, and the project you currently work on. Singleton and MVC are named as frequent pattern topics. Prepare to go one level below the definition and justify each choice.
What to demonstrate
- Depth of technical knowledge beyond textbook definitions
- Ability to defend a design choice against an alternative
- How you describe your own contribution to a project
How to prepare
- Write a thread-safe Singleton three ways (enum, holder class, double-checked locking with volatile) and say when you would avoid the pattern
- Compare Singleton and MVC with at least one other pattern you have used, naming the problem each one solves
- Draw the architecture of your latest project and annotate each component with the alternative you rejected
- Rehearse the design-from-scratch answer: requirements, data model, components, then trade-offs
Management/Cultural Fit Discussion
reportedCandidates describe the final stage as a management-led discussion about fit with the team and company culture. Reports advise reflecting on your professional experience for it. Expect to talk about motivation, how you juggle work, how you give and take feedback, and the stories behind your projects. Prepare concrete episodes rather than statements of values.
What to demonstrate
- Fit with the team, as the stage is described
- Communication of your experience and contribution
- Motivation for the role and awareness of the team you would join
How to prepare
- Write out three project stories in Situation, Task, Action, Result form, each with a measurable result
- Prepare a specific answer to why you want this Software Engineer role, drawn from the reported responsibilities
- Prepare an example of prioritising competing tasks and one of feedback that changed your work
- Write two or three questions about the team's responsibilities, since reports recommend asking them
PracHub editorial advice for the preparation topics above.
Reciting the OOP definitions without any code of your own
Prepare one short example from a project for each of encapsulation, inheritance, polymorphism and abstraction. Add one case where inheritance was the wrong choice and composition fixed it. Reports say to explain with concrete examples, not memorised definitions.
Naming collection classes but not how they work or why the linked list is a poor default
Be able to say how HashMap handles collisions and resizing, why ArrayList is usually faster than LinkedList despite O(1) insertion at a known node, and when a linked structure is justified, for example LinkedHashMap for an LRU cache. Hand-write the linked list operations including empty and single-node cases.
Walking through a project architecture as a list of tools with no decisions
For each component you mention, state the alternative you rejected and the reason. Reports stress the why behind technical decisions. Rehearse the walk-through aloud and add what you personally built.
Answering Singleton with unsafe lazy initialisation, or reducing MVC to its acronym
Know that a lazily created Singleton needs synchronisation, and write the enum, holder-class and volatile double-checked versions. Describe MVC as model, view and controller responsibilities with a flow of a request through them, and name one downside of Singleton such as hidden global state in tests.
A motivation or feedback answer that would fit any employer
Tie motivation to reported details of the role: Java, ownership from requirements to deployment, the data and software mix. For feedback, bring a real review episode with an outcome. Research the team and prepare questions about its responsibilities.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
How do you implement and manage a Linked List in a production environment?
How do you implement and manage a Linked List in a production environment?
Approach
- Separate building from using: in production code I would normally use java.util.LinkedList or ArrayDeque rather than write my own, and I would say why, since ArrayList or ArrayDeque usually beat a linked list on cache locality and per-node memory.
- If asked to implement one, describe a doubly linked list with head and tail sentinel nodes and a size counter: addFirst, addLast and removing a known node are O(1); search and get(i) are O(n). Sentinels remove the null checks for empty-list and head/tail edge cases.
- Name the edge cases explicitly: empty list, single element, removing the head or tail, duplicate values, and null elements. When unlinking, clear the removed node's next/prev and item references so stale nodes do not keep objects alive.
- Show where a linked list earns its place: an LRU cache pairs a HashMap from key to node with a doubly linked list, giving O(1) get and put by moving a node to the front and evicting from the tail.
- Address concurrency: LinkedList is not thread-safe; for shared use I would pick ConcurrentLinkedDeque (lock-free) or LinkedBlockingQueue for producer-consumer work, or guard a custom list with a lock and document the invariant it protects.
Follow-up
- Reverse a singly linked list in place, iteratively and then recursively. What is the space cost of each?
- How do you detect a cycle and find the node where it starts?
- Why might an ArrayList outperform a LinkedList even for frequent inserts near the end?
How do you approach designing a system from scratch?
How do you approach designing a system from scratch?
Approach
- Start with requirements: functional (the core operations and users) and non-functional (latency, availability, consistency, data retention). Ask for scale numbers and do a quick estimate of requests per second and storage growth.
- Define the API and the data model next, then choose storage from the access pattern: a relational database for transactions and joins, a key-value or document store for simple high-volume lookups.
- Sketch the high-level design: load balancer, stateless application servers, cache, database with replicas, and a message queue for slow or retryable work. Explain the job each component does.
- Deep-dive on the likely bottleneck: caching strategy and invalidation, read replicas and replication lag, partitioning by a key and the queries it makes expensive, idempotent writes for retries.
- Close with failure modes and operations: what happens when a dependency is down, timeouts and retries with backoff, monitoring and alerts, and the trade-offs you accepted.
Follow-up
- Would you choose SQL or NoSQL for this system, and why?
- How do you keep the cache consistent with the database?
- What changes if traffic grows ten times overnight?
How do you manage your responsibilities when working on multiple concurrent tasks?
How do you manage your responsibilities when working on multiple concurrent tasks?
Approach
- Treat this as a process question and give a concrete method: list everything in flight, rank by impact and deadline (an urgent-versus-important split works), and decide what not to do this week.
- Make the work visible: keep tasks in a tracker, limit how many you have in progress at once, and break large tasks into pieces that can be finished and handed off.
- Communicate collisions early: when two deadlines conflict, I bring the trade-off to the people who set them instead of quietly missing one.
- Protect deep work: batch reviews and messages, block focus time for coding, and plan for production interrupts rather than treating them as surprises.
- Back it with one real example and its outcome; saying you simply multitask or work longer hours is the answer to avoid.
Follow-up
- Two stakeholders both say their task is the top priority. What do you do?
- Tell me about a time you had to drop or delay something. How did you handle it?
- How do you handle an urgent production issue in the middle of a planned feature?
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.
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?
Write the update path that detects a concurrent edit
resource carries version INT NOT NULL DEFAULT 1. resource_revision holds revision_id, resource_id, version, actor_user_id, change_kind, patch JSONB, request_id, created_at with UNIQUE (resource_id, version). outbox_event holds aggregate_type, aggregate_id, aggregate_version, event_type, payload, status. A PUT carries the version the client read. Write the exact statements for the single transaction that applies the edit, records the revision and enqueues 'resource.updated', and give the handler's branch on zero affected rows. Then say what PostgreSQL 16 does under READ COMMITTED when two of these updates hit one row at once.
Approach
- One transaction, three writes, no network call inside it: UPDATE resource SET title = $3, version = version + 1, updated_at = now() WHERE resource_id = $1 AND tenant_id = $4 AND version = $2; then INSERT the resource_revision row at version $2 + 1; then INSERT the outbox_event row at the same aggregate_version. The event goes to a table rather than a broker because no transaction spans both.
- Branch on the affected-row count before doing anything else. Zero has three causes — stale version, wrong tenant, row gone — so re-read once and map to 409 carrying the current version, or 404 for an id outside the caller's tenant, which also stops the endpoint confirming that another tenant's id exists.
- State the engine behaviour instead of assuming it. Under READ COMMITTED the second UPDATE blocks on the row lock, and when the first commits PostgreSQL re-evaluates the WHERE clause against the newly committed row, so the version predicate now fails and the statement reports zero rows. Under REPEATABLE READ the identical collision raises SQLSTATE 40001 instead, so the handler must fold both shapes into one conflict response.
- Keep UNIQUE (resource_id, version) even though the predicate already serialises writers. It is what makes a lost update unwritable if any other path ever reaches the revision table, and it converts a logic bug into 23505 rather than into a silently missing history row.
Follow-up
- A client sends the version it read ten minutes ago and the resource has moved three versions. What is in your 409 so it can resolve the conflict without a full re-fetch?
- Two editors, two disjoint fields, no overlap. Does your answer still refuse the second write, and should it?
Explain the core principles of OOPs and how you implement them in your projects.
Explain the core principles of OOPs and how you implement them in your projects.
Approach
- Name the four principles and give a one-line Java mechanism for each: encapsulation (private fields, behaviour exposed through methods that guard invariants), abstraction (interfaces and abstract classes that hide implementation), inheritance (extends for is-a reuse), polymorphism (one interface reference, many implementations).
- Split polymorphism precisely: overloading is resolved at compile time from the argument types, overriding is resolved at runtime by dynamic dispatch on the object's actual class. Mention that static and private methods are not overridden.
- Ground each principle in your own code: for example, I hid a payment client behind an interface so I could swap vendors and mock it in tests, and I kept a balance field private so every change went through a validating method.
- Show judgement, not definitions: prefer composition over deep inheritance trees, and keep subclasses substitutable for their parent (Liskov), since a subclass that throws on an inherited method breaks callers.
- Cover one contract that ties OOP to Java collections: if you override equals you must override hashCode consistently, or HashMap and HashSet lookups fail.
Follow-up
- When would you choose an abstract class over an interface, given that Java 8+ interfaces can have default methods?
- Give an example where inheritance caused a problem in your code and how composition would fix it.
- Can you override a static method? What happens if you declare one with the same signature in a subclass?
Describe the internal working of Java Collections.
Describe the internal working of Java Collections.
Approach
- Start from the hierarchy: Collection splits into List, Set and Queue; Map is a separate root. Then pick the implementations that matter and explain each by its backing structure and complexity.
- ArrayList is a resizable Object[]: get(i) is O(1), add at the end is amortised O(1) because the array grows by about 1.5x when full, and insert or remove in the middle is O(n) from shifting. LinkedList is a doubly linked list: O(1) at the ends, O(n) for get(i).
- HashMap: an array of buckets whose size is a power of two; the index is (n - 1) & hash after spreading the high bits (h ^ h >>> 16). Default capacity 16 and load factor 0.75; past the threshold the table doubles and entries are redistributed. Since Java 8 a bucket of 8+ entries becomes a red-black tree once the table has at least 64 slots, so worst-case lookup drops from O(n) to O(log n).
- Round out the family: HashSet is backed by a HashMap; LinkedHashMap adds a doubly linked list for insertion or access order (the basis of a simple LRU via removeEldestEntry); TreeMap is a red-black tree with O(log n) operations and sorted keys.
- Cover iteration and concurrency: ArrayList and HashMap iterators are fail-fast through a modCount check and throw ConcurrentModificationException on structural change (use Iterator.remove instead); for threads use ConcurrentHashMap (CAS plus per-bin locking, no null keys or values) or CopyOnWriteArrayList for read-heavy lists.
Follow-up
- What happens if you mutate a key's fields after putting it in a HashMap?
- Why does HashMap keep its capacity a power of two?
- How does ConcurrentHashMap differ from Collections.synchronizedMap in locking and iteration behaviour?
Explain the difference between various Design Patterns, with a specific focus on Singleton and MVC.
Explain the difference between various Design Patterns, with a specific focus on Singleton and MVC.
Approach
- Frame the families first: creational (Singleton, Factory, Builder), structural (Adapter, Decorator, Facade) and behavioural (Observer, Strategy, Command). Note that MVC is an architectural pattern built from smaller ones, such as Observer between model and view and Strategy in the controller.
- Singleton: private constructor plus a static accessor. Walk through the thread-safe options: eager static field, synchronized getInstance (simple but locks every call), double-checked locking (needs a volatile field), the initialization-on-demand holder class, and an enum singleton, which also survives serialization and reflection attacks.
- Give Singleton's costs honestly: it is global mutable state, hides dependencies and makes unit tests harder. A dependency-injection container managing one instance per container is often the cleaner way to get the same effect.
- MVC: the Model holds data and business rules, the View renders it, the Controller takes input, updates the model and picks the view. The benefit is separation: views change without touching business logic, and models are testable without a UI.
- Tie each pattern to a real use: I used a Builder for an object with many optional fields, Strategy to swap pricing rules, and the MVC split in a web app's controller and template layers.
Follow-up
- Write a thread-safe lazy Singleton. Why does double-checked locking need volatile?
- How can a Singleton be broken through reflection or serialization, and how do you prevent it?
- How do MVP and MVVM differ from MVC?
Walk me through the architecture of a project you recently completed at your current company.
Walk me through the architecture of a project you recently completed at your current company.
Approach
- Open with the problem and its constraints in a few sentences: who used the system, the data and request volumes, and the requirement that shaped the design (latency, consistency, cost or a deadline).
- Draw the components and follow one request end to end: client, entry point or load balancer, services, data stores, caches, queues and external integrations. Say which pieces you owned and which the team owned.
- Pick one or two decisions and give the why: the alternatives you considered (for example, a relational database versus a document store, or synchronous calls versus a queue) and the trade-off that decided it.
- Describe a bottleneck or failure you hit, how you measured it and what you changed, with a number before and after if you have one.
- Close with what you would change now and what limits the design at higher scale; it shows you understand the system rather than only having worked in it.
Follow-up
- What breaks first if traffic grows ten times?
- How did you keep data consistent between the services and stores in that design?
- How was it deployed and monitored, and how did you find out when something went wrong?
Describe a situation where you had to debug a complex issue under pressure.
Describe a situation where you had to debug a complex issue under pressure.
Approach
- Structure the story as situation, task, action, result, and spend most of it on the actions: the user impact, how you found out, and what was at stake.
- Show that you limited the damage before chasing the root cause: rollback, a feature flag, failover or a temporary rate limit, and why that was the right first move.
- Walk through the diagnosis in order: what changed (deploy, config, data, traffic), the logs, metrics and traces you read, reproducing it outside production, and narrowing by bisection (for example git bisect across commits). For a Java service, name the tool you used: a thread dump for a hang or deadlock, a heap dump and GC logs for memory growth.
- Separate trigger from cause: state the hypothesis you tested, the evidence that confirmed it and the one you ruled out.
- Finish with prevention: the regression test, alert or guard you added, and how you kept stakeholders updated while it was ongoing.
Follow-up
- How did you confirm the fix worked and was not a coincidence?
- What would you do differently if the same incident happened today?
- How did you communicate status while the issue was still open?
The plan follows the reported loop: fundamentals for the technical screen, project and design depth for the second stage, and stories for the fit discussion. The last day runs all three back to back.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Map the loop and find your gaps
- Write the three reported stages and the topics candidates attach to them, then rate yourself from 1 to 5 on Java OOP, collections, linked lists, design patterns, project architecture and behavioral stories
- Choose three recent projects that could carry a deep-dive and note for each the stack, your contribution and one measurable result
Deliverable: A one-page rating sheet of six topics with the two weakest circled, plus a list of three projects with stack, contribution and result.
02Java OOP and collections from the inside
- Write the four OOP principles each with a short Java example from your own code, and one case where composition beat inheritance
- Write a one-page note on HashMap (buckets, hashCode and equals, collisions, resize at the load factor, treeified bins), ArrayList growth, ArrayDeque versus LinkedList, TreeMap and PriorityQueue, with the cost of each core operation
- Say each answer aloud without notes
Deliverable: A four-example OOP sheet, a one-page collections note, and a spoken answer to the OOP question and the collections question.
Practice prompt ↗Practice prompt ↗03Linked lists and design patterns
- Implement a singly linked list in Java with insert, delete by value, reverse and cycle detection (fast and slow pointers), and test the empty and single-node cases
- Write three thread-safe Singleton versions (enum, holder class, double-checked locking with volatile) and note when each is a poor fit
- Write an MVC request flow for an application you know, and compare it to Singleton in what problem each solves
Deliverable: A tested linked list class, three Singleton implementations, and a written MVC flow with a pattern comparison.
Practice prompt ↗Practice prompt ↗04Project architecture and designing from scratch
- Draw your best project's architecture and annotate each component with the rejected alternative and the reason
- Apply the same structure to a new system you pick: requirements, data model, main components, then two trade-offs you would defend
- Note any cloud, CI/CD or database element in your project, since reports list them as nice-to-have
Deliverable: An annotated architecture diagram, a one-page from-scratch design, and a spoken walk-through of each.
Practice prompt ↗Practice prompt ↗05Performance, debugging and database tuning
- Write your performance story in the structure from the guidance: symptom with a number, tool, hypothesis, single change, before and after, guard
- Write your debugging-under-pressure story as a timeline: what changed, how you narrowed it, what you fixed, what you changed afterwards
- Work through the two SQL practice drills in PracHub's practice set on index use and concurrent edits
Deliverable: Two written stories with numbers and a timeline, plus solutions to both SQL practice drills.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗06Motivation, multitasking and feedback
- Write a motivation answer tied to the reported role details and one fact you found about the team
- Write an example of prioritising several concurrent tasks, naming how you decided the order and what you told stakeholders
- Write your feedback process for giving and receiving, with one STAR story including a disagreement
- Prepare two or three questions about the team's responsibilities
Deliverable: Three written answers, one STAR story and a list of questions to ask.
Practice prompt ↗Practice prompt ↗Practice prompt ↗07Full run through the three stages
- Run a technical screen: implement the linked list operations and explain collections aloud, timed
- Run a deeper technical stage: defend your architecture diagram and the Singleton and MVC answers against an alternative
- Run a fit conversation: motivation, multitasking, feedback and one project story, then record yourself and note filler and vague claims
Deliverable: One recorded mock of all three stages with a list of the three answers to tighten.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
Reported behavioral questions cover your motivation for the role, managing several tasks, and your process for technical feedback, and the final stage is described as a management-led fit discussion. Candidate reports also say to frame stories as Situation, Task, Action, Result and to explain the reasoning behind each decision. For a Software Engineer role that owns features from requirements to deployment, choose stories where you made the decision and can name the result.
How do you handle performance bottlenecks in your code?
How do you handle performance bottlenecks in your code?
Approach
- Open with a measured symptom, not a tip list. Name the metric (p95 latency, batch runtime, heap growth, throughput) and how you observed it: a profiler or Java Flight Recorder, thread dumps, GC logs, a slow query log or EXPLAIN. A story that starts with "I guessed" has no credibility.
- Walk the sequence in order: reproduce under realistic load, profile to find the hot path, form one hypothesis, change one thing, re-measure on the same workload. Say why you did not tune before measuring.
- Name the real cause class and fix. Examples a Java engineer can defend: an N+1 query replaced by a join or batch fetch, a missing index, a list.contains call inside a loop replaced by a HashSet, string concatenation in a loop replaced by StringBuilder, allocation pressure from boxing, or lock contention on a shared object. Use only the one that actually happened.
- Close with the cost and the guard: what the fix traded (extra memory for a cache, staleness, more code), the before and after numbers, and the benchmark or alert you added so it cannot silently regress.
Follow-up
- How did you know that was the bottleneck and not a symptom of something else?
- What did the optimisation cost you in complexity or memory?
- How would you find the cause if it only appeared in production?
What motivated you to apply for a Software Engineer role at Affine?
What motivated you to apply for a Software Engineer role at Affine?
Approach
- Build the answer in three parts: what you do now and enjoy, what this Software Engineer role involves, and why the gap between them appeals. Candidates describe the role as hands-on, sitting between data engineering and software development, with ownership from requirements to deployment, so connect to those facts.
- Back each claim with evidence from your record, such as a feature you owned end to end, or a time you gave estimates to a product manager and met them. Mention only what you can support in follow-up questions.
- Research the specific team or product area before the interview and refer to it by name. If you do not know it yet, say so and ask about the team's responsibilities at the end instead of inventing enthusiasm.
- Stay forward-looking about your current employer: frame what you want more of, never what you dislike. A short first-person version: I have spent two years building Java services, I want more work where data and software meet, and I want to own features from requirements to release.
- Avoid an answer that fits any company. If you could swap in another name and nothing changes, add a detail about the role or the stack.
Follow-up
- What would you want to work on in your first few months?
- What other options are you considering, and what sets this one apart?
- What do you still want to learn about the team?
Describe your preferred process for receiving and giving technical feedback.
Describe your preferred process for receiving and giving technical feedback.
Approach
- Split the answer into receiving and giving, and describe a process for each rather than a value. Giving: review small changes, explain the reason behind each comment, label blocking issues versus optional ones, offer an alternative, and ask a question before asserting a defect. Receiving: restate the point to confirm you understood, ask for an example if unclear, separate the code from yourself, then act and report back.
- Anchor it with one STAR story: a review comment or design critique you got or gave, what you changed or argued, and what improved (a bug caught, a pattern adopted, a simpler design).
- Include the disagreement path. When you disagree, bring evidence such as a benchmark, a failing test or the requirement, and if you are still stuck, agree who decides and then commit to the decision.
- Tie it to the work candidates describe for this role: code reviews and design sessions with peers, plus giving product managers honest estimates and requirement questions, which is feedback in the other direction.
- The mistake that sinks it is "I welcome feedback" with no example, or a story where you simply obeyed or ignored the comment.
Follow-up
- Tell me about feedback you disagreed with and what you did.
- How do you give feedback to someone more senior than you?
- What do you do when two reviewers give contradictory comments?
- 01
What motivated you to apply for a Software Engineer role at Affine?
- 02
How do you manage your responsibilities when working on multiple concurrent tasks?
- 03
Describe your preferred process for receiving and giving technical feedback.
- 04
How do you handle performance bottlenecks in your code?
- 05
Describe a situation where you had to debug a complex issue under pressure.
- 06
Tell me about a time you explained a technical trade-off to a product manager.
How difficult are the technical rounds?
Candidates describe the difficulty as average but thorough. They also say that explaining your logic matters as much as reaching a correct answer, so practise narrating your reasoning on fundamentals such as collections, linked lists and OOP.
Affine Software Engineer candidate reports ↗Should I ask questions during the interview?
Reports recommend it. Good topics are the responsibilities of the team you would join and how the role splits between feature work, code review and troubleshooting. Research the team beforehand so the questions are specific.
Affine Software Engineer candidate reports ↗What is the typical timeline?
Candidates report three rounds over about 3-5 weeks, with some describing an online application, an HR screen, then the technical rounds. If you hear nothing within the timeframe you were given, follow up with your recruiter.
Affine Software Engineer candidate reports ↗Which language and topics should I prioritise?
Reports name Java as the usual primary language, with OOP, the collections framework, linked lists and the Singleton and MVC patterns as frequent topics. Start there, then prepare your project architecture and performance and debugging stories.
PracHub Software Engineer practice ↗Do I need cloud, CI/CD or database experience?
Reports list cloud infrastructure, CI/CD pipelines and database optimisation as nice-to-have rather than required. If you have used any, prepare one concrete example; if not, be honest and explain how you would learn it, which reports also advise.
Affine Software Engineer candidate reports ↗How should I handle a technology I have not used?
Say so plainly, then describe how you would get productive: what you already know that transfers, what you would read or build first, and who you would ask. Reports advise honesty over bluffing.
PracHub Software Engineer practice ↗Sources & methodology 3 sources ↗
No official company page is cited. Rounds and questions come from candidate reports and PracHub editorial material; each source shows the date it was read.
- 01Affine Software Engineer candidate reports ↗
Company-reported rounds, questions and FAQ.
Candidate reports · Accessed 2026-09-22 - 02PracHub Software Engineer practice ↗
PracHub practice material, not company-reported.
PracHub page · Accessed 2026-09-22 - 03PracHub preparation framework ↗
PracHub preparation guidance.
PracHub page · Accessed 2026-09-22
Explore related engineering environments and compare the preparation focus.
Confluent Software Engineer Interview Guide
Concurrency exercises for Confluent candidates: check-then-act races, deadlock from inconsistent lock ordering, and why two individually atomic operations do not compose into an atomic update.
GitHub Software Engineer Interview Questions & Guide 2026
Testing exercises for GitHub software engineer prep: choosing boundary cases over repetition, isolating tests from shared clock and ordering, and treating an intermittent failure as a defect rather than noise.
Zulily Software Engineer Interview Guide
What Zulily asks Software Engineer candidates, from reported rounds and questions.
Zoom Communications Software Engineer Interview Guide
What Zoom Communications asks Software Engineer candidates, from reported rounds and questions.