--- title: Five interview answers that sound correct and cost the offer description: A hiring-side perspective on five common technical interview answers that sound correct but signal mid-level thinking. For each question — covering Swift... canonical: https://daily.dev/posts/five-interview-answers-that-sound-correct-and-cost-the-offer-dcu6qdrx6 twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Five interview answers that sound correct and cost the offer | daily.dev og:description: A hiring-side perspective on five common technical interview answers that sound correct but signal mid-level thinking. For each question — covering Swift... og:url: https://daily.dev/posts/five-interview-answers-that-sound-correct-and-cost-the-offer-dcu6qdrx6 og:image: https://api.daily.dev/og/posts/DCu6QdRX6.png og:image:alt: Five interview answers that sound correct and cost the offer og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Five interview answers that sound correct and cost the offer **[Medium](https://daily.dev/sources/medium_js)** · 8 min read · 0 upvotes · 0 comments ## Summary A hiring-side perspective on five common technical interview answers that sound correct but signal mid-level thinking. For each question — covering Swift memory management, actors, offline sync design, architecture decisions, and project walkthroughs — the post contrasts what most candidates say with what a senior engineer says. The core pattern: mid-level answers state facts, senior answers articulate trade-offs, rejected alternatives, and the cost of decisions. The post ends with a soft pitch for a paid iOS interview guide. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### When should I use weak self in a Swift closure to avoid a retain cycle? Only when the closure is retained by self, directly or transitively, forming a cycle. If self stores the closure, weak self breaks that cycle. If the closure is passed somewhere with a shorter lifetime, such as an animation block or DispatchQueue call, there is no cycle, and weak self instead decides whether work should still run after self is gone. In a Task, self is retained until completion, so weak self there is about whether the work is still valid across suspension points, not about leaks. _Reasoning through ownership instead of reflexively adding weak self is exactly the kind of judgment daily.dev readers refine by following real Swift discussions._ ### Are Swift actors thread-safe against logic races, not just data races? No. Actors serialize access to their state, eliminating data races, but they are reentrant: at every await inside an actor method, the actor can start serving other callers. A state check made before a suspension point may no longer hold after it, so a cache check before an await can still cause duplicate work, or an invariant checked before suspension can be broken after. The fix is re-checking state after every await or structuring the critical section so no suspension occurs between the check and the commitment. _Understanding where actor reentrancy bites helps developers debug concurrency issues that daily.dev's Swift community discusses often._ ### How should I design offline sync and conflict resolution for a note-taking app? Treat the local database as the source of truth for the UI and the server as the source of truth across devices, writing every mutation locally first, queuing it, then replaying it. Detect conflicts using per-record versioning, such as a server change token or last-modified counters, rather than timestamps, since device clocks are unreliable. Resolve with field-level merge where possible, otherwise last-writer-wins while preserving the losing version as a recoverable copy, explicitly trading away real-time collaboration since that would require CRDTs or operational transforms. _Weighing conflict resolution trade-offs like these is easier when developers can follow ongoing offline-sync design discussions on daily.dev._ ## Similar posts on daily.dev - [Medium](https://daily.dev/posts/medium-wl3wlzchk) · Medium · 0 upvotes · 0 comments - [How To Prepare for Big Tech Interviews as an iOS Engineer](https://daily.dev/posts/how-to-prepare-for-big-tech-interviews-as-an-ios-engineer-r3cas78d8) · The New Stack · 0 upvotes · 0 comments - [The Android interview question that has no right answer](https://daily.dev/posts/the-android-interview-question-that-has-no-right-answer-yfxh2ceud) · Medium · 0 upvotes · 0 comments - [35 Senior .NET Developer Interview Questions That Actually Get Asked…](https://daily.dev/posts/35-senior-net-developer-interview-questions-that-actually-get-asked--6vcn580bl) · Code with Mukesh · 22 upvotes · 3 comments - [Hire based on the conversation about code, not the code itself](https://daily.dev/posts/hire-based-on-the-conversation-about-code-not-the-code-itself-opdszahpm) · Lobsters · 1 upvotes · 0 comments --- Tags: [#career](https://daily.dev/tags/career), [#architecture](https://daily.dev/tags/architecture), [#ios](https://daily.dev/tags/ios), [#swift](https://daily.dev/tags/swift) [View this post on daily.dev](https://daily.dev/posts/five-interview-answers-that-sound-correct-and-cost-the-offer-dcu6qdrx6) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Five interview answers that sound correct and cost the offer","url":"https://daily.dev/posts/five-interview-answers-that-sound-correct-and-cost-the-offer-dcu6qdrx6","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/five-interview-answers-that-sound-correct-and-cost-the-offer-dcu6qdrx6"},"datePublished":"2026-07-19T19:33:05.803Z","dateModified":"2026-09-14T07:37:49.676Z","description":"A hiring-side perspective on five common technical interview answers that sound correct but signal mid-level thinking. For each question — covering Swift...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/6293e81c8b93aa8a4b99d25e0e8f786b?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/6293e81c8b93aa8a4b99d25e0e8f786b?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Medium","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Medium","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/medium","url":"https://daily.dev/sources/medium_js"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/five-interview-answers-that-sound-correct-and-cost-the-offer-dcu6qdrx6","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"career,architecture,ios,swift","timeRequired":"PT8M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Medium","item":"https://daily.dev/sources/medium_js"},{"@type":"ListItem","position":3,"name":"Five interview answers that sound correct and cost the offer"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/five-interview-answers-that-sound-correct-and-cost-the-offer-dcu6qdrx6#faq","mainEntity":[{"@type":"Question","name":"When should I use weak self in a Swift closure to avoid a retain cycle?","acceptedAnswer":{"@type":"Answer","text":"Only when the closure is retained by self, directly or transitively, forming a cycle. If self stores the closure, weak self breaks that cycle. If the closure is passed somewhere with a shorter lifetime, such as an animation block or DispatchQueue call, there is no cycle, and weak self instead decides whether work should still run after self is gone. In a Task, self is retained until completion, so weak self there is about whether the work is still valid across suspension points, not about leaks. Reasoning through ownership instead of reflexively adding weak self is exactly the kind of judgment daily.dev readers refine by following real Swift discussions."}},{"@type":"Question","name":"Are Swift actors thread-safe against logic races, not just data races?","acceptedAnswer":{"@type":"Answer","text":"No. Actors serialize access to their state, eliminating data races, but they are reentrant: at every await inside an actor method, the actor can start serving other callers. A state check made before a suspension point may no longer hold after it, so a cache check before an await can still cause duplicate work, or an invariant checked before suspension can be broken after. The fix is re-checking state after every await or structuring the critical section so no suspension occurs between the check and the commitment. Understanding where actor reentrancy bites helps developers debug concurrency issues that daily.dev's Swift community discusses often."}},{"@type":"Question","name":"How should I design offline sync and conflict resolution for a note-taking app?","acceptedAnswer":{"@type":"Answer","text":"Treat the local database as the source of truth for the UI and the server as the source of truth across devices, writing every mutation locally first, queuing it, then replaying it. Detect conflicts using per-record versioning, such as a server change token or last-modified counters, rather than timestamps, since device clocks are unreliable. Resolve with field-level merge where possible, otherwise last-writer-wins while preserving the losing version as a recoverable copy, explicitly trading away real-time collaboration since that would require CRDTs or operational transforms. Weighing conflict resolution trade-offs like these is easier when developers can follow ongoing offline-sync design discussions on daily.dev."}}]} ```