HackTheRounds Interview Experiences

Yuno Backend Engineer Interview Experience (2026) - Go, AWS, Rejected

A three round backend process covering API aggregation, Go concurrency, ACID, SOLID, Docker, AWS deployment strategies, and live coding.

By HackTheRounds Team · 2026-05-01

Background

I reached Yuno's backend engineer process through a referral in May 2026. Three rounds covered practical coding, Go concurrency, databases, deployment, software design principles, and behavioral judgment. I completed the loop but was rejected.

This was not a process where studying algorithms alone would be enough. The first assessment included an API-processing task, and later conversations expected working knowledge of Go services and production delivery.

Round 1: Online Assessment

The assessment contained a basic data-structures problem and a practical API problem. The second task required calling an endpoint, collecting results across the available response data, aggregating them, sorting them, and returning the top N.

I treated the API portion as a small production pipeline. First, define how pagination terminates and what happens on a partial failure. Second, normalize records before aggregation so missing or malformed fields do not silently change ordering. Third, make the ranking deterministic with a secondary key for ties.

Sorting the full result is simple and often acceptable, but it costs O(m log m) for m records. When N is much smaller than m, a min-heap of size N reduces the ranking work to O(m log N) . The tradeoff is extra implementation complexity. I would start with the clearest correct approach, state the expected data size, and optimize only when the constraint justifies it.

Round 2: Go, Concurrency, and Databases

The next interview compared Node.js and Go. I explained that Node's event loop is effective for I/O-heavy services with a JavaScript ecosystem, while Go offers lightweight goroutines, straightforward parallelism, static binaries, and a strong standard library for services. The right choice depends on workload, team experience, latency requirements, and operational constraints.

The Go discussion went deeper than saying goroutines are lightweight threads. We covered the runtime scheduler's many-to-many model, how goroutines are multiplexed onto operating-system threads, and why blocking behavior and scheduler overhead still matter. I was asked about defer , including cleanup uses and ordering, plus when to protect shared state with a mutex and when to coordinate ownership through channels.

My rule of thumb was not “channels are always more idiomatic.” A mutex is direct when several goroutines need short, well-defined access to shared memory. Channels fit workflows where values or responsibility move between independent workers. Either design can fail if cancellation, buffer capacity, lock ordering, or shutdown behavior is ignored.

Database questions covered ACID. I connected each property to observable service behavior: atomicity prevents partial transactions, consistency preserves declared invariants, isolation controls interference between concurrent operations, and durability protects committed data after failure. I also discussed a previous project and the constraints behind its design.

Round 3: Design, Deployment, and Behavioral Questions

The last round ranged across SOLID principles, Docker, AWS, release strategies, and Go types. Instead of reciting the five SOLID names, I used small examples showing why a boundary existed and what kind of change it isolated.

For infrastructure, I compared EC2's low-level host control with ECS orchestration of container workloads. The interviewer also asked about blue-green and canary deployments. Blue-green switches traffic between two complete environments and offers a direct rollback, but temporarily duplicates capacity. Canary delivery exposes a small traffic slice first, which limits blast radius and provides real production signals, though it requires reliable metrics and careful cohort handling.

The live coding task was a palindrome checker in Go. A byte-based two-pointer solution works for restricted ASCII input. For general text, converting to runes avoids splitting multibyte characters. I clarified whether punctuation and case should be normalized before writing code.

Behavioral questions included how I assessed my seniority and why I wanted to leave my current role. I described seniority through scope, ownership, decision quality, and the ability to improve a team—not merely years worked.

How I Would Improve the Solutions

For the assessment, I would isolate HTTP retries and pagination from ranking logic so both pieces can be tested without a live service. I would bound concurrency rather than launch one request per page, propagate cancellation, and decide explicitly whether a partial result is acceptable. For the Go service discussions, I would add race-detector tests and define shutdown ownership before choosing channels or locks. For deployments, I would name the health signals and automatic rollback threshold. These details turn a catalog of technologies into an operational answer.

Result

I was rejected after the third round. I do not know the internal reason, so I would not attribute it to headcount or a single answer.

Preparation Takeaways

  1. Practice consuming paginated APIs, handling failures, and ranking large result sets.
  2. Know the Go scheduler, `defer`, mutexes, channels, cancellation, and Unicode strings beyond surface definitions.
  3. Explain ACID with service-level consequences.
  4. Be ready to compare ECS and EC2 using operational requirements.
  5. Connect deployment strategies to rollback, observability, capacity, and blast radius.
  6. Prepare examples of design principles that improved real code.
  7. Clarify input rules before implementing even a simple coding problem.