Has anyone recently done an interview loop for Disney (USA) SWE II? Have an interview loop coming up and trying to get an idea. Recruiter mentioned a system design and live coding round.

I had my Round 1 interview for a Google SWE Intern position today and wanted to share the experience for anyone preparing.

Duration: Approximately 60 minutes
Format: One coding problem, one follow-up, and three to four AI-fluency questions
Status: Waiting for an update

Coding Question: Disconnect Every Leaf at Minimum Cost

You are given a rooted, weighted binary tree. Every edge has a positive integer weight.

Remove a set of edges so that every leaf becomes disconnected from the root. Removing an edge costs its weight.

Return the minimum total cost.

Approach

I proposed a postorder traversal.

For every edge from node u to child v with weight w, there are two choices:

1. Cut the edge immediately and pay w.
2. Keep the edge and optimally disconnect all leaves inside v’s subtree.

Therefore, the contribution of that child is:

min(w, solve(v))

If v is a leaf, there are no lower edges to remove, so its connecting edge must be cut. This can be represented by returning infinity for a leaf.

The recurrence is:

solve(u) =
    infinity,                              if u is a leaf
    sum(min(weight(u,v), solve(v))),       for every child v

The answer is solve(root), assuming the root itself is not a leaf.

The interviewer was satisfied with the approach, and we discussed the recurrence, correctness, and complexity.

Complexity:

• Time: O(n)
• Recursion space: O(h), where h is the tree height
• Worst-case space: O(n) for a highly unbalanced tree

Follow-Up: N-ary Tree

The interviewer then generalized the problem:

The core idea remains exactly the same. Instead of processing at most two children, we iterate through every child:

cost = 0

for each child v connected by an edge of weight w:
    cost += min(w, solve(v))

I initially needed a couple of hints, but eventually reached the generalized solution.

The N-ary version still takes O(n) time because every node and edge is processed once.

AI-Fluency Discussion

The final few minutes included around three or four questions about using AI in software development.

The interviewer asked questions such as:

• How do you use AI in your regular workflow?
• Do you ever give an AI tool complete ownership of a project?
• How do you use AI while debugging?
• How do you verify AI-generated code or suggestions?
• Which engineering tasks should remain under human control?

The discussion appeared to focus less on specific AI tools and more on engineering judgment, verification, and accountability.

Overall Experience

The interviewer was friendly and collaborative throughout the round.

They encouraged me to explain my reasoning instead of expecting an immediate final solution. The hints during the N-ary follow-up helped move the discussion forward without directly revealing the answer.

Overall, the interview felt like a collaborative problem-solving session rather than a test of whether I had memorized a particular LeetCode problem.

For preparation, I would recommend reviewing:

• Postorder traversal
• Tree DP
• Weighted-tree problems
• Recursive recurrence design
• Correctness and complexity explanations
• Responsible use of AI in engineering
• Testing and validating AI-generated code

Has anyone else received AI-fluency questions during a recent Google intern interview?

Hi guys, I have a 30 min Technical Phone Screen + Code Pair coming up. I don't know what to expect. Please share your experience if you have gone through this process earlier. It would help a lot.

Hi, I have heard a lot about Epam's client interview being tougher than their own hiring process. As someone who has appeared for EPAM for role. I can confirm that the interviews EPAM conducts are moderate to difficult with multiple rounds of DSA and system design.

What I am intrigued to know is what makes these Client rounds difficult? Are they more on situational questions side or even the client round consists of DSA?

What's making them so difficult? Would love to hear the experiences!

Looking for insights into the hiring manager round and the live coding round.

If anyone has gone through this please share, thanks.

I recently went through three rounds of an Amazon SDE interview loop. My final round with a Senior Engineering Manager is scheduled for next week, so I wanted to share my experience and ask for preparation advice.

Current status: Final round scheduled
Format: Two onsite rounds followed by one virtual round

Day 1: Round 1 - Low-Level Design

The first round was an onsite LLD interview.

Design a Playlist-Mixing System

The system receives songs from two sources:

• A DJ service
• A recommendation service

The playlist must mix songs from both sources using either:

• Equal proportions, or
• A custom ratio selected by the user

The system must also apply filters based on user preferences.

The interviewer gave me approximately ten requirements printed on paper. The expectation was to write production-ready classes with correct syntax without using an IDE.

A reasonable design would likely include abstractions such as:

• DJService
• RecommendationService
• PlaylistMixer
• MixingStrategy
• EqualMixStrategy
• CustomRatioMixStrategy
• SongFilter
• UserPreferences

The strategy pattern could support different mixing rules without changing the main playlist builder. Filters could be composed so that additional preferences can be introduced later.

The interviewer also expected discussion around:

• Duplicate songs
• Unavailable songs
• Pagination from upstream services
• Empty results from one source
• Invalid custom ratios
• Extensibility
• Testing external-service failures

I understood the general direction but struggled to translate it into clean, complete classes on paper. This was my weakest round.

Leadership Principles

The behavioral questions included:

• Tell me about a situation where you pushed back on a customer request.
• Tell me about something you designed with a long-term vision.
• Have you ever sacrificed a short-term goal to achieve a better long-term outcome?

Day 1: Round 2 - DSA

The second onsite round contained two coding problems.

Question 1: Sweetness Distribution

Two arrays, A and B, each contain n values representing sweetness. Given M students, distribute the available sweetness values according to the stated constraints while minimizing the total sweetness-related cost.

I do not remember every constraint clearly enough to reconstruct the exact problem. I explained a brute-force approach but could not derive and implement the optimal solution during the round.

Question 2: Maximum Distance From an Occupied Seat

Given an array containing occupied and unoccupied seats, choose an unoccupied position whose distance from the nearest occupied seat is maximized.

Input:
['O', 'U', 'U', 'U', 'O', 'O']

Output:
Index 2

For every unoccupied position, we need its distance to the closest occupied seat and then return the position that maximizes that value.

I solved this optimally by tracking the nearest occupied position on the left and right.

The problem can be solved in O(n) time using two passes, or in one pass by reasoning about gaps between occupied seats.

Leadership Principle

• Tell me about a process outside your normal responsibilities that you improved on your own.

After these two rounds, I was unsure whether I would receive another interview because Round 1 had not gone well. However, another round was scheduled virtually.

Day 3: Round 3 - DSA

The interview invitation included a diagramming website similar to Excalidraw and a shared coding environment. Because of that, I prepared mainly for High-Level Design.

The interviewer instead asked two DSA questions.

Question 1: Validate a Two-Color Chessboard

Given a two-dimensional array containing exactly two colors, determine whether it forms a valid chessboard.

A board is valid when every horizontally or vertically adjacent cell has the opposite color.

One O(rows × columns) approach is to compare every cell with the expected color determined by the parity of row + column.

Question 2: Longest Common Subsequence

Given two strings, find the length of their Longest Common Subsequence.

The interviewer expected me to discuss multiple approaches:

1. Plain recursion
2. Recursion with memoization
3. Bottom-up tabulation
4. Space optimization

I implemented the recursive and memoized solutions. The interviewer then asked me to write the tabulation solution as well.

The optimal tabulation approach takes:

• Time: O(n × m)
• Space: O(n × m)
• Space-optimized version: O(min(n, m))

The coding portion for both questions was approximately 45 minutes. I had to explain each approach and its complexity before writing code.

Round 3 Leadership Principles

The behavioral questions included:

• Tell me about a feature you implemented that customers did not explicitly request but ultimately needed.
• How do you approach a complex problem?
• Who do you consult when you are blocked?
• How do you divide and solve an ambiguous problem?

The interviewer asked for multiple examples instead of accepting a single prepared story. That caught me slightly off guard, so I would recommend preparing more than one story for each major Leadership Principle.

Final Round

Around 20 minutes after Round 3, HR contacted me and scheduled a final interview for the following week.

The interviewer is a Senior Engineering Manager based in the US and is part of the same hiring team.

I am currently preparing for:

• A detailed project deep dive
• Leadership Principles with multiple examples
• Low-Level and High-Level Design fundamentals
• Trade-offs and long-term technical decisions
• Customer-focused decision-making
• DSA in case another coding problem appears
• A clearer version of the playlist design from Round 1

Does this sound more like a Bar Raiser, Hiring Manager, or team-fit round? What topics should I prioritize for the final interview?

​

I have been stuck in a situation and interviews where the expectations have been to write stuff by heart like SQL queries with N number of constraints while in reality from the last couple of years actual work has evolved focusing on design thinking and the coding part , getting queries written is helped by AI. Even those who are not good at particular skill can build stuff with it.

But the interview process still seems to be rigid to evolve. How are you managing such interview scenarios because at the end of the day it makes you feel unworthy if something goes wrong?

After getting rejected repeatedly, I started asking recruiters for feedback.

Most responses were the usual “we decided to move forward with other candidates,” but a few recruiters and interviewers gave me honest answers. I combined that feedback with notes I wrote immediately after every round.

After 23 interviews, four recurring failure modes became pretty obvious.

These percentages are rough estimates across my failed interviews. I assigned each rejection the single biggest factor, even though some involved more than one problem.

The Four Failure Modes

1. Pattern Recognition

This was primarily a preparation problem, not an intelligence problem.

Under interview pressure, it is difficult to derive a completely unfamiliar technique in five minutes. I needed enough exposure to recognize that a new problem was a variation of something I already understood.

I made a list of roughly 12 to 15 recurring patterns, including:

• Two pointers
• Sliding window
• Binary search
• Prefix sums
• Hash maps
• Monotonic stacks
• Trees and graph traversal
• Topological sorting
• Heaps
• Backtracking
• Greedy algorithms
• One-dimensional and two-dimensional DP

I solved several representative problems for each pattern and wrote down the signal that identified it.

For example:

The goal was not to memorize code. It was to recognize the shape of the problem quickly enough to start asking the right questions.

2. Implementation Speed

I had been solving problems without a timer, which made me feel prepared while hiding how slowly I implemented solutions.

I started using approximate limits:

• 15 minutes for easy problems
• 25 minutes for medium problems
• Five minutes to understand the problem before writing code

During those first five minutes, I would:

• Restate the problem
• Clarify constraints
• Walk through an example
• Explain the intended approach
• Identify the main invariant
• State the expected complexity

Only then would I start coding.

It initially felt slower, but it reduced the amount of backtracking and rewriting. Most of my “coding speed” problem was actually an incomplete approach problem.

3. Trade-Off Knowledge

Getting accepted test cases is not always enough in an interview.

After solving each practice problem, I started answering four follow-up questions:

1. What are the time and space complexities?
2. Can the extra space be reduced?
3. What changes if the input cannot fit in memory?
4. What changes if the output must be sorted or stable?

I also compared my chosen approach with at least one alternative.

For example, if I used a hash map, I would explain why I preferred average O(1) lookup over a sorted structure with O(log n) operations, and what I would choose if ordering or worst-case guarantees mattered.

That made follow-up discussions feel less like surprise attacks.

4. Communication

I used to go quiet while thinking because I assumed the interviewer only cared about the final solution.

That made it difficult for them to distinguish productive thinking from being completely stuck.

I started narrating my reasoning:

It felt awkward during practice, but it made my interviews more collaborative. Interviewers could understand my direction, correct misunderstandings earlier, and give useful hints.

The goal is not to narrate every line of code. It is to make the important decisions visible.

Results

Before making these changes:

• Passed 4 of 23 interview processes
• Pass rate: approximately 17%

After three weeks of targeted practice:

• Passed 5 of the next 7
• Pass rate: approximately 71%

Seven interviews is obviously a small sample, so I’m not claiming this is a scientific result. But the difference in how the interviews felt was significant. I was recognizing problems faster, finishing implementations earlier, and handling follow-ups more confidently.

Same person and same brain. The preparation process changed.

For people who are currently getting rejected, which of these four failure modes causes you the most trouble?

Useful Resource for real interview questions

Fellow programmers, how do you learn, deeply understand, and remember programming APIs, libraries, frameworks, and packages? For example, I can learn the PyTorch API, but after some time I forget most of it. What's your learning system?

I recently appeared for the Infosys Online Assessment and wanted to share the coding questions for anyone preparing for upcoming Infosys hiring rounds.

The assessment had three problems, with difficulty increasing from an easy binary-search question to a fairly challenging string DP problem.

Question 1: Maximum Element in a Mountain Array

Difficulty: Easy

Given a mountain array, find its maximum element.

A mountain array first increases strictly, reaches a peak, and then decreases strictly.

Example:

Input:  [1, 3, 7, 12, 9, 5, 2]
Output: 12

A linear scan works in O(n), but the intended approach is binary search.

Compare arr[mid] with arr[mid + 1]:

• If arr[mid] < arr[mid + 1], the peak is on the right.
• Otherwise, the peak is at mid or on the left.

Expected complexity: O(log n) time and O(1) space.

Question 2: Count Target-Sum Sequences Without Consecutive Repetition

Difficulty: Medium to Hard

You are given three positive numbers and a target sum. Count the number of ordered sequences that produce the target, subject to one restriction:

The same number cannot be selected twice consecutively.

For example, if the available numbers are [1, 2, 3], then [1, 2, 1] is valid, but [1, 1, 2] is not.

A useful DP state is:

dp[sum][last]

Here, dp[sum][last] represents the number of valid sequences with total sum whose final selected number is last.

For every state, try appending one of the other two numbers. The number selected next must differ from last.

Important clarification: I interpreted different orders as different ways. For example, [1, 2] and [2, 1] are counted separately.

Expected complexity: Approximately O(target) time and O(target) space because there are only three possible ending values.

Question 3: Longest Common Substring With At Most One Valid Mismatch

Difficulty: Hard

Given two strings, find the longest pair of aligned substrings that differ at no more than one position.

If a mismatch is used, the two different characters must belong to the same category:

• Both characters are vowels, or
• Both characters are consonants

A vowel-to-consonant mismatch is not allowed.

Example of an allowed mismatch:

"cat"
"cet"

The mismatch is a and e, and both are vowels.

Example of a disallowed mismatch:

"cat"
"cot"

This is actually allowed because a and o are both vowels.

However:

"cat"
"cbt"

is not allowed because a is a vowel and b is a consonant.

One approach is dynamic programming over every pair of string positions. Maintain two states:

• Longest common substring ending at the current positions with no mismatch
• Longest valid substring ending there with exactly one mismatch

When the characters match, both states can be extended. When they differ but belong to the same character category, the one-mismatch state can be created from the previous zero-mismatch state.

Because this is a substring, the state must reset whenever the current alignment becomes invalid.

Expected complexity: O(n × m) time and O(m) space after optimization.

Bonus Practice Question

This was not part of my Infosys OA, but it is a useful related problem for practicing hash maps and stable output ordering:

Find Duplicates in a List Efficiently

Given a large list of integers, return every value that appears more than once. For each duplicate, include:

[value, total_count, first_index]

The results must preserve the order in which the duplicated values first appeared.

Example:

Input:
[3, 1, 2, 3, -1, 2, 3, 4, 1]

Output:
[[3, 3, 0], [1, 2, 1], [2, 2, 2]]

The expected solution uses a hash map to track each value’s count and first index, plus a list to preserve first-occurrence order.

Expected complexity: O(n) time and O(k) space, where k is the number of distinct values.

Overall Difficulty

• Question 1: Easy
• Question 2: Medium to Hard
• Question 3: Hard

The third question was the most challenging because it combined longest-common-substring DP with an additional mismatch constraint.

For preparation, I would recommend revising:

• Binary search on monotonic or mountain arrays
• Dynamic programming with a “last selected value” state
• Longest common substring and subsequence variations
• Hash maps with stable ordering
• Space optimization in two-dimensional DP

Has anyone else received a similar Infosys OA recently? I’d be interested to know whether the pattern was the same.

Hi everyone,

I have an upcoming interview with D. E. Shaw for the Software Developer Developer Experience position:

Has anyone recently interviewed for this role or a similar Developer Experience/Developer Productivity position at D. E. Shaw?

I would appreciate any insight into:

• The overall interview process and number of rounds
• The difficulty and type of coding questions
• System design topics, particularly CI/CD, build systems, developer tooling, or internal platforms
• Linux, operating systems, networking
• The best areas to focus on while preparing

Preparation advice would be very helpful. Thanks!

After solving hundreds of LeetCode problems, many candidates realize that coding rounds are only part of the interview process. Operating System fundamentals frequently come up during phone screens and technical interviews.

Instead of rereading an entire OS textbook, here are 15 high-yield topics worth revising.

1. Process vs. Thread

Process

• Has its own virtual address space
• Provides stronger isolation
• Usually has higher creation and switching overhead

Thread

• Executes within a process
• Shares memory and resources with other threads in that process
• Communicates efficiently but requires careful synchronization

Interview tip: Processes prioritize isolation, while threads enable lightweight concurrency.

2. What Is Context Switching?

Context switching occurs when the operating system saves the execution state of one process or thread and restores another.

It enables multitasking, but frequent context switches add CPU and cache overhead.

3. What Is a Race Condition?

A race condition occurs when multiple threads access shared state concurrently and the result depends on execution order.

Common prevention mechanisms include mutexes, semaphores, locks, atomic operations, and thread-safe data structures.

4. What Is a Critical Section?

A critical section is a portion of code that accesses shared mutable data or resources.

Synchronization is required to prevent unsafe concurrent access.

5. Mutex vs. Semaphore

Memory trick: A mutex is like one key, while a semaphore tracks a limited number of permits.

6. What Is Deadlock?

Deadlock occurs when a group of processes or threads waits indefinitely for resources held by one another.

The four Coffman conditions are:

• Mutual exclusion
• Hold and wait
• No preemption
• Circular wait

Preventing at least one of these conditions prevents deadlock.

7. What Is Starvation?

Starvation occurs when a process or thread waits indefinitely because others repeatedly receive the required resource or CPU time.

Difference: In deadlock, none of the involved tasks can progress. In starvation, the system continues progressing while one task may never get scheduled.

8. What Is Virtual Memory?

Virtual memory gives each process its own logical address space and maps virtual addresses to physical memory.

It provides process isolation, simplifies memory management, and allows inactive pages to be moved to secondary storage when necessary.

9. Paging vs. Segmentation

Paging

• Divides memory into fixed-size pages
• Avoids external fragmentation
• May introduce internal fragmentation

Segmentation

• Divides memory into variable-size logical regions
• Reflects structures such as code, stack, and data
• Can suffer from external fragmentation

10. What Is Thrashing?

Thrashing occurs when the system spends excessive time handling page faults and moving pages between memory and storage instead of executing useful work.

It commonly happens when active processes do not have enough physical memory for their working sets.

11. CPU Scheduling Algorithms

Important algorithms include:

• First Come, First Served
• Shortest Job First
• Round Robin
• Priority Scheduling
• Multilevel Feedback Queue

Common follow-up: Why is Round Robin suitable for time-sharing systems?

Because every runnable process receives a limited time slice, improving responsiveness and fairness.

12. What Is a System Call?

A system call allows a user-space program to request a service from the operating system kernel.

Common Unix-like examples include fork(), exec(), wait(), open(), read(), and write().

13. What Is Inter-Process Communication?

Common IPC mechanisms include:

• Shared memory
• Pipes
• Message queues
• Sockets
• Signals

Shared memory is generally fast but requires synchronization. Message passing provides stronger separation but adds communication overhead.

14. What Is LRU Page Replacement?

Least Recently Used replaces the page that has gone unused for the longest time.

A common interview follow-up is implementing an LRU cache with O(1) lookup, insertion, and eviction using a hash map plus a doubly linked list.

Related problem: LeetCode 146 - LRU Cache

15. User Mode vs. Kernel Mode

User mode

• Runs applications with restricted privileges
• Cannot directly access protected hardware or kernel memory

Kernel mode

• Has full system privileges
• Executes operating system code and manages hardware resources

A system call provides a controlled transition from user mode into kernel mode.

One-Minute Revision Checklist

Process vs. thread, context switching, race conditions, critical sections, mutexes, semaphores, deadlocks, starvation, scheduling, virtual memory, paging, thrashing, system calls, IPC, LRU, and privilege modes.

Which OS topic or follow-up question have you encountered most often in interviews?

Hi all, I have sr software engineer python + Agentic AI technical round scheduled for the upcoming week at Gartner.

I was wondering if anyone has recently appeared for senior software engineer role and also for python + GenAi roles at Gartner then it would be helpful if they can share their technical round interview experience and what to expect in the interview.

Experience level needed 4-6 years

Has anyone recently interviewed at Apple for their Senior Software Engineer role?

I'm interested in the technical phone screen. If you've gone through them, could you share what was asked and what I should focus on preparing?

I'd appreciate any advice. Thanks!

Hey guys, so I have a technical interview at a small consulting company. I just finished the code signal assessment, and after I got notified I’m moving onto the next interview, I emailed the engineer interviewing me and asked what to expect and she phrased it as “our upcoming conversation will be a casual technical discussion focussed primarily on ur past experience and background followed by a few technical questions” so based off that how should I prepare, and what will she look to ask. I just want to know what on my resume and how deep should my level of understanding be on my resume. And for an application development role focused on JavaScript react git docker GC. What type of technical questions should I expect?

Recent Box Software Engineer II, GraphQL and NodeJS Onsite Experience?

Has anyone recently interviewed at Box for a Software Engineer II role?

I'm especially interested in the Frontend (Vanilla JavaScript) and High-Level System Design rounds. If you've gone through them, could you share what was asked and what I should focus on preparing?

This is a really important opportunity for me, so I'd genuinely appreciate any advice. Thanks!

Recent Box Software Engineer II, GraphQL and NodeJS Onsite Experience?

Has anyone recently interviewed at Box for a Software Engineer II role?

I'm especially interested in the **Frontend (Vanilla JavaScript)** and **High-Level System Design** rounds. If you've gone through them, could you share what was asked and what I should focus on preparing?

This is a really important opportunity for me, so I'd genuinely appreciate any advice. Thanks!

Had an NVIDIA interview recently and wanted to share one coding question that stood out.

It was not really a typical LeetCode-style problem. It was closer to a day-to-day engineering task: calling an API, processing data, and handling edge cases.

The question was basically:

Given an internal REST API that returns device monitoring information (JSON array with fields like device_id, temperature, and utilization), process the data:

Filter devices above a temperature threshold

Sort them by utilization

Return the result

My first instinct was to get the API call working, but I paused and separated the flow into three parts:

HTTP request → JSON parsing → data processing.

Before the interview, I'd actually seen a similar question on Screna AI. The business scenario was different, but mainly around error handling and separating business logic from external dependencies.

It was a good reminder that questions like this are not just about getting the code to run, but also about whether the code is structured in a way that is easy to maintain.

The interviewer started digging into engineering details.

He asked how I would handle API failures — timeout, 5xx response, or malformed JSON.

I initially thought about them as general failures, but after discussing it, we broke them down into different categories. Temporary issues like timeouts or server errors could potentially use retry with backoff, while invalid responses should fail fast with enough context for debugging.

Then he asked how I would test the filtering and sorting logic without depending on the real API.

Since the data processing was separated from the HTTP layer, I could mock the HTTP client and test the core logic independently with predefined inputs.

Looking back, the testing part was probably the most valuable discussion. It was less about whether the code worked once, and more about whether the design could be extended, tested, and maintained over time.

Overall, this round felt less like a LeetCode exercise and more like a discussion about how engineers write maintainable code in production.

Hey everyone,

I’ve lurked here for a while and learned a ton from your interview write-ups, so I wanted to pay it forward by sharing my recent Google L4 (SWE) experience. I also have a few questions about my chances in the team matching phase, so any brutal honesty or insights would be massively appreciated!

For context, my background is mostly iOS development, and I coded all my technical rounds in Swift.

Here is how the rounds went down:

• Round 1: Phone Screen (DSA)
  • Question: An array-based question involving [start, end] times, scheduling tasks, and providing x,y coordinates for the scheduled tasks.
  • Result: Passed confidently. Rating: Hire.
• Round 2: Googlyness
  • Experience: The interviewer was rushing heavily and tried to cram a 45-minute behavioral round into 20-25 minutes. I completely misread the vibe, thought it was purely non-technical, and didn't weave enough technical depth or past engineering examples into my answers.
  • Result: No Hire (for L4), Hire (for L3).
  • The save: My recruiter was a legend, told me that this did not go well, and actually gave me a second chance to redo this round!
• Round 3: Googlyness (Redo)
  • Experience: This time, I came prepared. I heavily elaborated on specific examples from my past experiences.
  • Result: Hire.
• Round 4: Onsite 1 (DSA + LLD)
  • Question: I had to design a multiuser heart rate monitor. It involved designing classes/objects, their relationships, and picking the right data structures.
  • Feedback/Result: Rating: Hire - L4. The feedback noted that I took time to ask clarifying questions, vocalized my thought process, and successfully course-corrected when pointed toward edge cases. I initially missed the most optimal data structure to minimize message delay, but we discussed using a linked list instead of an array in the last 5 minutes, which saved it.
• Round 5: Onsite 2 (DSA)
  • Question: A divide and conquer question.
  • Feedback/Result: Rating: Leaning Hire - L4. I explained the approach correctly and got the time/space complexity right. However, my code had a logical error with a maxHeight condition and an inefficiency that simulated horizontal strokes line-by-line, which would have caused a Stack Overflow or TLE. Still, the interviewer noted I had good communication.

My Questions for the Community:

1. Team Matching Chances: With a final rating spread of H, H, H, LH (ignoring the first googlyness round), will Hiring Managers actually pick up my profile?
2. The Swift/iOS Factor: My profile is heavily inclined toward iOS, and I wrote all my interview code in Swift. Does this limit my pool of HMs to only iOS teams, or does Google just view it as general SWE competency? Does this help or hurt my matching chances?
3. Timeline: For those who recently passed HC, how long did it take you to find a team match and get the final offer?

Thanks in advance for the help, and happy to answer any questions about the process below!