I don't work at a FAANG, so no leet code or tests. We also don't have the best pay. Not horrid, but probably 2/3s what a FAANG engineer makes. In addition, I don't work at a company known for software development. Our primary business is networks and connectivity.

That all said, it can be a pain to find candidates. Our functional programming tech stack is pretty niche to make matters worse just for perspective.

Interviews are typically:

• Video conference screening by the hiring manager (30min).
• Video conference technical screening by someone like me (1h)
• In person technical screening/personality check panel interview (4-5 people asking questions for 1-2h with 2h split between 2 groups), followed by a VP interview (30min-1h), and a final interview with the hiring manager (30min). About 2.5-3.5h hours. 2h panel is usually only for higher level positions, 1h is more typical. We try to time it to take them to lunch if they want to go.

Technical interviews are mostly just talking shop. I have a list of topics and sample questions, but just as conversation starters:

• Networking tech: what are sockets, DNS, HTTP(s), describe what a browser is doing in as much detail as possible when you go to a website.
• Code quality questions: what is linting, static code analysis, formatting, etc. Ask about their editor setup to get realtime feedback from these tools.
• Repo maintenance questions: monorepo, tsconfigs (typescript shop), transpiling, bundling.
• Testing: unit, integration, perf, property-based.
• Security: encryption, sanitizing data, OAuth
• Language question: What are generics, dynamic vs static types, generators, async/multiprocess/threads, stack vs heap, recursion/tail recursion, immutable/stateless, OO vs imperative vs functional. Big-O. Lazy evaluation/monads for those claiming FP experience.
• API: Rest, HTTP methods as verbs and resources as nouns, query/path/body params (when isn't body allowed), cookies, web sockets, GraphQL, HTTP response codes. OpenAPI/Swagger.
• CI/CD: Tools they know, pipelines they've built.
• Cloud: AWS questions, distributed system: redundancy/high availability/scaling, micro service, API gateway. Disaster recovery. K8s/docker. Database: SQL/noSQL, primary keys, indexes, ORMs, joins, map/reduce, etc. Linux: Probe some common commands or tasks until I find their upper limit. Data: Relational, normal vs non-normal form, one to one/one to many/many to many/DAGs (directed acyclic graphs).

What I'm looking for is someone who understands the technology they work with. Great candidates will relate the question to their experience, not give a text book response. I'll drill into more nuanced questions if I suspect someone just power studied and doesn't understand the tech.

For a junior, 10-20% familiarity with the questions is typical. For my level, 70% is ideal. I also don't ask all of them. If you have 5 years experience with databases I may spend 1-2min with some harder concepts to test the claim and move on.

The more you talk about your knowledge that's applicable to the role, the more likely my questions will be geared towards your experience.

Personal projects and a public repo will vastly boost your preinterview appearance. I will look at your code, your commit history, tooling you use, etc. This usually tells me more than any interview. I'm not looking for the perfect repo with 100% code coverage, greats docs and comments, etc. I'm looking to see how the code evolved from inception.

I look for contributions to other projects big and small. It tells me you had a problem or needed a feature and had the problem solving skills to make it happen. A big +1.

We also offer APIs which customers integrate against. We don't want our customers to have to reach out. So in that specific domain I'll ask about what can be done to avoid those calls. Great docs, FAQ, tutorials, code examples, reference implementations of a client using our APIs, tutorials to build those reference implementations step by step, etc.

Our entire back end has a simulator implementation. Clients get the source. They can test against it locally, look at the source to see what its doing, etc.

We try to provide really good error messages. If a client sends a bad request, we send back exactly where it failed to parse. Clients, through the simulator implementation, can look at the exact parser we use to work it out.

Linux experience is a huge plus. Public dotfiles gives me good insight ahead of the interview.

Personal projects don't need to be all code. I've hired bootcamp programmers who were previously a musician, a baker, and a carpenter. Attention to detail, problem solving, and passion towards achieving a goal are great personality traits.

I ask some pointed questions about AI. I love GPT, but more as a search engine replacement and not an answer book. I have a couple juniors who are really smart, but rely on it way to much. Its output never fits our style guidelines so it stands out. Its vastly hampered their ability to read code. They've improved with some interventions, but I try to sus out how dependant a candidate is on it.

Hopefully some of this word soup is of assistance!