Internship Guidance, ByteDance Three‑Round Interview Experience, MySQL Replication Mechanics, and I/O Model Overview

Internship Guidance and Interview Tips

Many recent graduates wonder whether they can secure an internship during the summer before starting a master's program; the author explains that most companies treat them as fresh graduates, making it difficult to obtain a long‑term internship unless they have personal connections.

Even when an internship is possible, the author suggests three key practices to increase the chance of conversion to a full‑time role: proactively communicate with the leader, aim to exceed expectations (e.g., performance tuning), and actively participate in system maintenance and bug fixing to become familiar with the project.

The article also clarifies the differences between first, second, and third technical interview rounds in large tech firms, noting that the first two rounds focus on extensive technical questions while the third round emphasizes project depth and fewer generic questions.

ByteDance Three‑Round Backend Interview Experience

The author shares a specific ByteDance backend interview where the third round focused on probing the candidate’s project thinking, asked a few standard questions, and concluded with an HR interview after about half an hour.

Choosing Primary Keys

Primary key fields must be unique and non‑null.

Prefer fields with an incremental trend to avoid page split issues.

Avoid using business data (e.g., member card numbers) as primary keys because they may become duplicated or reused.

Auto‑increment fields work for single‑machine setups, but distributed environments require distributed ID solutions to prevent collisions.

MySQL Master‑Slave Replication Mechanism

MySQL replication relies on the binary log (binlog) that records all changes. The replication process is asynchronous: the master writes the binlog, commits the transaction, and returns to the client without waiting for slaves.

Write Binlog : Master writes binlog, commits transaction, updates local storage.

Sync Binlog : Binlog is transferred to all slaves, each slave writes it to a relay log.

Replay Binlog : Slaves read the relay log and apply changes to their storage engines.

Detailed steps: the master writes binlog and commits, then returns success; the slave creates an I/O thread to fetch the binlog and store it in the relay log; a separate thread replays the relay log to achieve data consistency.

Replication Models

Synchronous Replication : Master waits for all slaves to acknowledge before returning to the client (rarely used due to performance and availability issues).

Asynchronous Replication (default): Master does not wait for slaves; data loss can occur if the master crashes.

Semi‑Synchronous Replication : Master waits for at least one slave to acknowledge, balancing safety and performance.

Binlog Formats

MySQL supports three binlog formats:

STATEMENT : Records each SQL statement (logical log). Issues arise with nondeterministic functions like UUID() or NOW() .

ROW : Records the actual row changes (physical log). Avoids nondeterministic issues but can generate large logs for bulk updates.

MIXED : Automatically switches between STATEMENT and ROW based on the operation.

I/O Models Overview

Blocking I/O blocks the thread until the kernel prepares data and copies it to user space.

Non‑Blocking I/O returns immediately if data is not ready; the application must poll until the kernel signals readiness, after which a synchronous copy still occurs.

I/O Multiplexing (e.g., select , poll ) allows a single thread to monitor multiple sockets, blocking only on the event‑notification step, improving CPU utilization.

Asynchronous I/O eliminates both waiting steps: the kernel prepares data and copies it to user space without the application blocking, typically using aio_read .

The article uses dining‑hall analogies to illustrate the differences among blocking, non‑blocking, multiplexed, and asynchronous I/O models.