# maeil-mail: a daily technical interview question by email

> maeil-mail is a Korean service that sends one technical interview question with a written answer by email every morning at seven, and the maeil-mail-fe repository is its TypeScript front end. The interesting part for a developer is the monorepo layout, and the interesting part for a reader is how small and deliberately narrow the whole thing is.

**maeil-mail/maeil-mail-fe** — 📮 기술 면접 질문을 매일매일 메일로 보내드릴게요!

- Repository: https://github.com/maeil-mail/maeil-mail-fe
- Website: https://maeil-mail.kr
- Stars: 525 · Forks: 21
- Language: TypeScript
- License: not declared
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/maeil-mail-maeil-mail-fe

## What the service actually does each morning

The service description is one sentence: a technical interview question and answer is sent every morning at seven, at random. The README asks the question directly, what service is this, and answers it plainly.

The framing is a subscription newsletter. You register an email address, and every weekday morning a question arrives with a well-organised answer attached. The stated design goal is that checking mail during the commute, at the start of the day and at the end of it, adds up to natural growth, and the README asks the reader to spend five minutes a day on it.

What the service is not is also stated. It was built with no purpose of generating revenue, and the creator says the goal was to make a service that gets used in the world. That framing matters for how you should read the repository, because it tells you what to expect from a codebase that is the public front end of a small subscription site rather than a product with a feature roadmap.

The site is at maeil-mail.kr, and the README links to it repeatedly as the way in, including a link with a GitHub source parameter so the traffic is attributed. The screenshots in the README show the web interface: a question, an answer, and the registration flow.

The repository itself is named maeil-mail-fe, which is the conventional abbreviation for front end, and it holds the client side of that site. The last push to the repository was on 2026-09-04, there are no GitHub releases, and the licence field records nothing.

## The problem the README argues is worth solving

The section on what problem is being solved is the part of the README that explains the design, and it is worth reading because it is a small, clean argument.

The opening question is how everyone prepares for interviews. The follow-up widens it: even when you are not preparing for an interview, how do you go about learning concepts and theory? The README's answer is that building a solid grasp of concepts matters a great deal for developers, and the reason given is specific: the more complex an implementation, the more essential it is to know the underlying concept.

Then comes the problem. Studying concepts takes far more effort than people expect. The example is a commute, where a developer wants to study for even a short while, and to do that they would have to search for a well-organised GitHub repository or blog post on the concept themselves. And finding a repository or a blog is not the same as being able to study, because you then have to find a specific article where the concept is actually explained.

The cost of that, on top of an already busy schedule, is what the service calls irrational. The answer is to remove the searching: register an email, and the question and a well-organised answer arrive at seven. Five minutes a day, no hunting.

Two design decisions fall out of that argument. The daily cadence rather than a weekly digest, because a commute is short and a week is not. And the email rather than the web, because email is something a developer already checks several times a day, which means the study slot does not need to be scheduled.

## The monorepo layout, and what each part of it does

The repository is a Turbo and pnpm monorepo, and the top level shows the standard shape of one.

At the root there is a package.json named maeil-monorepo, marked private, with the package manager pinned to pnpm@9.5.0 and a single build script that delegates to turbo build. There is a pnpm-workspace.yaml and a pnpm-lock.yaml, a turbo.json holding the task graph, a tsconfig.base.json holding the shared TypeScript configuration, and a .vscode/ directory. Linting and formatting are configured in the repository too, with .eslintrc.json for ESLint, .prettierrc for Prettier, an .npmrc, and an .nvmrc pinning the Node version.

The source lives in two directories. apps/ holds the deployable applications, and packages/ holds the shared libraries that the applications consume. That split is the whole point of the layout: the interview question content, the mail delivery logic, and the web front end can be separated so that a change to a shared component does not have to be redeployed everywhere.

The dependency set in the root package.json is small and mostly tooling. The TypeScript ESLint plugin and parser at 7.18.0, ESLint at version 8, Prettier at 3.3.3, turbo at 2.4.4, and TypeScript at version 5. The only script is build, and it is a turbo build, which means the task graph in turbo.json decides the order and the caching.

The primary language recorded for the repository is TypeScript, and the fact that the root manifest has no runtime dependencies and no framework in it is a strong hint about the shape of the apps/ directory. The front end of a content site is likely to be a static or server-rendered bundle rather than a heavy client-side application, and the content itself is the product.

## The one build command, and what Turbo adds

The build is a single command, and the reason it is short is that the work is in the configuration rather than in the script.

```json
  "scripts": {
    "build": "turbo build"
  },
```

Turbo is the task runner that sits in front of the individual package builds. It reads the task definitions in turbo.json and the workspace layout in pnpm-workspace.yaml, works out which packages depend on which, runs the builds in the right order, and caches the outputs so that a package whose inputs have not changed is not rebuilt.

For a repository of this shape, that caching is the practical point. If the content of the question bank changes, only the package that owns the content needs rebuilding, and the front end bundle that embeds it is rebuilt because its dependency changed. If a shared type definition changes, everything downstream rebuilds. Without a task graph, a monorepo of several packages with a shared dependency chain either rebuilds everything on every change or relies on a developer remembering to order the builds correctly by hand.

The pnpm side matters too, and the version is pinned in the package.json rather than left to a global install. pnpm@9.5.0 is declared in the packageManager field, which means a developer running a version-aware pnpm will use that version, and the pnpm-lock.yaml records the exact resolution for every dependency in the workspace. The .npmrc file is there for registry configuration, and the .nvmrc pins the Node version for the same reason.

So the front end is reproducible in a way that a single-package repository with a global npm install is not, and that matters more here than it might elsewhere, because a question bank is content that changes frequently and a broken build during a content update is the kind of thing that stops a small project from being updated.

## Why a daily email and not a question bank

The most interesting design question about the service is not technical, and the README's own framing gives the answer.

A question bank is the obvious alternative, and it is what most interview preparation resources are. A bank is searchable, browsable, and you can pick the topic you are weak on. The daily push gives you none of that. You get one question a day, chosen at random, and you cannot pick.

The trade is deliberate and it goes both ways. What you give up is control over what you study and when. What you get is that the decision has already been made for you, and that the cost of a study session drops to the act of opening an email, which is a cost low enough to survive a busy week. A question bank that you are supposed to visit has a failure mode where you stop visiting; an email that arrives has a much lower one.

Random selection also does something that a bank cannot. It exposes the gaps in your knowledge that you would not have chosen to look at. A developer who thinks they know about a topic will happily drill that topic and never notice that the adjacent area is empty, whereas a random draw surfaces the edges.

The service is built around a single daily email with a written answer, and the README is clear that the answer is meant to be well organised, since the whole value proposition is that you do not have to go and find the explanation yourself. That is the same requirement stated at the start, that you should not have to hunt through repositories and blogs for the article where a concept is actually explained, applied to a single question at a time.

## Where this project is the wrong choice

Three cases point elsewhere. The first is someone who wants a searchable question bank. The service is a push, not a pull, and the repository describes a daily random question with an answer. If your need is to look up a specific topic, or to work through a syllabus, a daily email at seven is a poor fit no matter how good the questions are.

The second is a reader who does not work in Korean. The repository and the service are Korean-language, and the repository gives no indication of a translation or a language setting. The code is TypeScript and the structure is conventional, so the front end is not the barrier, but the content is the product, and the content is in one language. For a reader working in English, the alternative is to assemble the same habit from an English-language source, which means doing the searching that the service exists to avoid.

The third is a team that needs an assessment tool. There is no scoring, no tracking of which concepts you have covered, no spaced repetition, and no way to see your own history in the service. If you are trying to measure readiness for a role, this gives you a question a day and no signal about the answers.

The alternative worth weighing is a spaced repetition system, such as Anki with a deck of interview questions, or a maintained open question list on a repository you can filter. The difference in approach is the same one the service argues about, but running the other way. A repetition system lets you schedule the questions you have already seen and rate your own recall, which is a stronger learning mechanism than reading an answer, and it costs you the setup and the discipline. The daily email inverts that: it removes setup and discipline entirely and replaces them with a small, repeatable exposure. Which one works depends on whether your failure mode is not knowing what to study or not studying.

## Conclusion

maeil-mail fits a developer who wants a short daily prompt to review a concept rather than a structured study plan, and who is comfortable reading in Korean. It does not fit a team looking for a question bank to search, a curriculum to follow, or an assessment tool, because the service is a daily push with no such structure, and it does not fit a reader who needs the content in another language. Before you sign up, read the service on maeil-mail.kr first and check the question style against what you actually need, because the value of a daily email depends entirely on whether its difficulty and coverage suit you.

## FAQ

### What is the maeil-mail service?

It is a subscription service that sends a technical interview question together with a well-organised answer by email every morning at seven, with the question chosen at random. The README states it was created with no aim of generating revenue, and that the goal was to build a service that people would actually use.

### What problem does maeil-mail say it solves?

The README argues that learning concepts takes more effort than people expect, because studying on a commute means searching for a suitable repository or blog post and then finding a specific article that explains the concept. Registering an email removes that search, leaving five minutes a day of reading.

### What is in the maeil-mail-fe repository?

It is the front end of the service, built as a TypeScript monorepo. The top level holds an apps/ directory for the deployable applications and a packages/ directory for shared libraries, with pnpm workspaces, a turbo.json task graph, a shared tsconfig.base.json and ESLint, Prettier, .npmrc and .nvmrc configuration.

### How do you build the maeil-mail front end?

The root package.json declares a single build script that runs turbo build, with the package manager pinned to pnpm@9.5.0. Turbo reads the task graph in turbo.json and the workspace definition in pnpm-workspace.yaml, orders the package builds by dependency and caches the outputs so unchanged packages are not rebuilt.

### Can I use maeil-mail to study a specific topic on demand?

Not on the evidence in the repository. The README describes a daily push at seven with a random question and a well-organised answer, with no search, filtering or browsing described, and no tracking of which concepts a reader has already covered.

## Sources

- [Issues](https://github.com/maeil-mail/maeil-mail-fe/issues)
- [maeil-mail/maeil-mail-fe on GitHub](https://github.com/maeil-mail/maeil-mail-fe)
- [Project website](https://maeil-mail.kr)
- [README](https://github.com/maeil-mail/maeil-mail-fe/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/maeil-mail-maeil-mail-fe