# Alternative Ways to Tech Interview

> A new interview method that compensates for the problems of existing developer hiring methods

A new interview method that compensates for the problems of existing developer hiring methods

> [!warning] As I look at it now (2026-02-04), a lot of this is outdated. A method that does not really fit <agentic engineering>. (Update <ToDo>)

## Drawbacks of the Existing Method

The conventional way of hiring developers does not seem appropriate for several reasons.

- Traditional <coding tests> have various problems, such as low job relevance and reduced discriminative power because "coding test-focused training" has become so widespread. But it also does not seem like a good idea to hire a developer without any opportunity to observe them coding.
- In a situation where everyone does [AI-assisted programming](https://wiki.g15e.com/pages/AI-aided%20programming.txt) in practice and uses [ChatGPT](https://wiki.g15e.com/pages/ChatGPT.txt) and the like, it does not seem appropriate to block that off and conduct hiring interviews. (See: [Generative AI and programmers' capabilities](https://wiki.g15e.com/en/pages/Generative%20AI%20and%20competency%20of%20programmers.txt))
- In actual work, nobody develops quietly alone in a little room. There are colleagues in the next seat (or in the Slack channel), and at any time people talk to each other and solve problems together. If all you do is watch a candidate code quietly by themselves, you cannot sufficiently observe things like how they communicate. (See: [Contextual inquiry](https://wiki.g15e.com/pages/Contextual%20inquiry.txt))

## Additional Hopes

Separate from the problems listed above, I also had the following hopes.

- It would be nice if the interview process itself were a beneficial experience for the candidate, regardless of whether they pass or fail.
- The interview process is a place to evaluate the candidate, but at the same time it is also a place where the candidate evaluates the company. It would be nice if the candidate were also given ample opportunity to observe and evaluate the interviewer (a colleague they would work with if hired).
- It would be nice if it were a method that did not require asking the candidate to set aside additional time, such as "submit an assignment before the interview." (I tried that before, and it was hard on the candidate, and it also took me far too much time to evaluate, so it was hard on me too.)

## A Proposed Improvement

Based on those concerns, I came up with a method like this.

- Present a short piece of code (around 30 lines?) together with the current problem situation, then tell the candidate to solve the problem by any means necessary (recommend using ChatGPT). Let them know that the interviewer will play the role of a senior helping them, so they should actively ask for help at any time.

For example, I would present the candidate with a situation like the following.

- We added a simple search API. The feature works normally, but when many users arrive at the same time, response delays occur.
- Even when response delays occur, CPU usage remains close to 0%.
- Read the code below, infer the cause of the problem above, and solve it.
- Besides that, there are various other potential improvements in the code. Improve as much as possible.
- Solve the problem by any means necessary, including asking [ChatGPT](https://wiki.g15e.com/pages/ChatGPT.txt), web searching, or asking the colleague in the next seat (the interviewer).

And then show the code.

```typescript
import Koa from 'koa'
import Router from 'koa-router'
import { readdirSync, readFileSync } from 'fs'

const router = new Router().post('/search', async ({ request, response }) => {
  const c = request.query.category as 'books' | 'movies' | 'music'
  const q = request.query.term as string

  try {
    response.body = { files: searchFilesInCategory(c, q) }
  } catch (error) {
    response.body = { error: String(error) }
  }
})

function searchFilesInCategory(category: 'books' | 'movies' | 'music', keyword: string): string[] {
  const files = readdirSync(`./data/${category}`)
  return files.filter(x => readFileSync(`./data/${category}/${x}`, 'utf-8').includes(keyword.toLowerCase()))
}

new Koa().use(router.routes()).listen(80)
```

Ask the candidate to share their screen, then help them through the process of solving the problem while observing that process.

Technically, you can look at aspects like the following. Unlike algorithm problem-solving, this lets you test knowledge that is closely tied to practical work.

- From the description of the problem situation, do they correctly infer that synchronous I/O is the problem?
- Do they properly convert synchronous I/O code to asynchronous I/O code?
	- Simple problem: do they change `readdirSync()` to `readdir()` and add `await`? Do they fix `function` to `async function`? Do they change the return type from `string[]` to `Promise<string[]>`?
	- Slightly more complex problem: while changing `readFileSync()` contained inside `files.filter()` to `await readFile()`, do they appropriately replace `Array.prototype.filter()` with a `for-loop` or a `map()` that returns a `Promise`, and do they use `Promise.all()`?
	- Even more complex problem: do they check whether it is important for the order of `files` to be guaranteed? Do they mention the need for throttling?
- In a situation with no tests, do they do [Hyperaware editing](https://wiki.g15e.com/pages/Hyperaware%20editing.txt)? (Working Effectively With Legacy Code)
- Do they ask enough necessary questions, or do they just start changing things recklessly? For example: do they ask whether there was a specific reason for using `POST` rather than `GET` before changing it?
- Do they recognize that making the search request with `POST` instead of `GET` is a problem?
- In the <URL>, do they change the verb `/search` to a noun such as `/files`?
- Do they notice the inconsistency where only `music` is singular and the rest are plural?
- Do they distinguish between static checking and runtime validation? Do they mention that validation is necessary for `request.query.category` and `request.query.term`?
- Do they discover the possibility of a file path injection attack?
- Do they point out the problem of sending an HTTP 200 response in error situations?
- Do they fix inconsistent variable names (for example, q and term)?
- Do they catch small bits of duplicated code?
- Do they ask why it is binding to port 80?
- Do they point out the problem that `String.prototype.toLowerCase()` is done for the user-entered search term but not for the file contents?
- By observing the speed at which they read and understand code, and small details of how they use the keyboard (for example, cursor movement, whether they use the editor's refactoring features such as "rename," etc.), you can observe whether the candidate is someone who codes steadily on a regular basis.
- Are they curious about what problems still remain?

You can also obtain various kinds of information while observing the candidate use [generative AI](https://wiki.g15e.com/pages/Generative%20AI.txt).

- If you observe what they ask generative AI, you can concretely understand how the candidate is perceiving the current situation. An effect similar to [Think aloud](https://wiki.g15e.com/pages/Think%20aloud.txt).
- You can observe how clearly they convey what they want to the generative AI, and whether they properly understand the AI's answers. You can observe one facet of their written communication ability.
- You can have specific conversations by asking which of the generative AI's suggestions they accept or doubt, and why they think that way.
- You can observe how comfortably they use generative AI.

Finally, you can get the experience of having a conversation with the candidate around a realistic problem situation.

- Rather than vague talk like, "If it were a situation like this, how would you usually handle it?" you can have a conversation much closer to a real situation, like, "Right, so on line 6, how do you think it would be good to validate the query string?"
- It has the advantage of moving closer to a mode of helping solve the problem from the standpoint of the candidate's colleague, rather than a mode of trying to catch the candidate's weaknesses.

I have tried using this method while helping with hiring interviews at a few companies, and I like it.