# Technical interviewing

Beyond the in-person interviews endemic to most coding jobs, there is also a nasty set of interviews tied to technical understanding.

Ironically, a technical interview does *not* test one's capacity for [software development](computers-software.md). Instead, it's a rigor of 30-60 minutes to solve a coding question that is supposed to demonstrate how well you understand [data structures](data-structures.md) and [algorithms](computers-programming-algorithms.md).

Thus, since it's standard practice in most companies to use a technical interview for software developers, practicing for a coding interview is vital for getting a job, even if it has little to do with the job itself.

## Technical Interviews

Technical interviews may feel like a competition against the system, but your *real* competition is the other candidates looking for the job.

There are multiple places to test your skills (e.g., [LeetCode](https://leetcode.com/), [freeCodeCamp](https://www.freecodecamp.org/learn/coding-interview-prep/)), so there's no shortage of free material for it.

There are *way* too many questions to practice in advance, so instead it's better to visit questions from companies you're planning to interview at instead.

- If the company hasn't been clear on what questions they'll likely use, try to find an analogous company (e.g., if it's a large cloud storage service, try to use the interview questions from Dropbox).

Focus heavily on *topics* more than *answers*. You can usually find how a concept connects, then find an answer from existing knowledge you already have.

One of the downsides of the technical interview is that you usually get to choose your [language](computers-languages.md).

- This sounds like a good thing, but the engineer interviewing you may *not* be familiar with a particular language, and won't be able to help you if you get stuck somewhere.
- The easy solution to this is research beforehand online about what languages that engineer *does* know, and only use those.

During the interview, think out loud. It demonstrates that you actually *are* thinking of an answer, and the interviewer gets to see your flow of logic. Often, they may even help you along.

- They're testing your competence at solving problems, *not* technically whether you can solve the problem they're giving you.

## System Design Interviews

System design interviews are another unique aspect of the tech industry, though they're not as ubiquitous as coding challenges.

They'll test your skills at understanding [how programs and systems are designed](computers-software.md), and there's really no way to prepare directly for them. All you can do is [understand the core mechanics of how a computer system works](https://trendless.tech/primitives/), and then answer the questions they give.

Even when you have *tons* of experience designing systems, the interview is testing your ability to articulate how those systems work in [plain language](language.md). It helps to watch videos and read books on those subjects, even with tons of hands-on experience.

Ask questions about things you don't understand. You do *not* fully understand their system, and it shows you have [humility to accept that fact](https://trendless.tech/understanding/).

Try to stay on-topic with high-level concepts, then drill into the details as needed.

- It's not uncommon for technically-savvy people to get *very* entrenched in the details and lose track of how much time they're discussing a smaller portion of the greater whole.