# Tech management
The technical interview
There are a lot of people online who believe you should be doing some obscure tests or trials to figure out how people will work under pressure, how they learn, or what their mentality is. I don't believe in proxies. Make the test first and foremost as similar to the work they will be doing when you hire them. Use the same coding language, use the same frameworks, and if you can - even use the same codebase.
In an ideal world the test may be that you take your existing codebase, introduce 30+ bugs, then give them an hour or so to solve the bugs.
If that's not an option, another good test is to get them to set up a small project that uses the same tech/frameworks (or at least a small subset). If this is the test, then they will likely need more than one hour.
There are so many benefits to this approach. If you do hire this person, they already have a good idea of your code and frameworks. For the candidate they can decide if that's something they feel is exciting.
The cultural interview
The motivation for the cultural interview is as much for your existing employees as the candidate. You need buy-in from the team that this is a person they want to work with.
If the team do not approve of the hire, then it's extrememly unlikely that the candidate will last (most of the time for no fault of their own).
The mentality of the worker is very important, but also context dependent. If you have a remote team, you need to hire people who are built for remote. If you have a fast paced & constantly changing codebase, you need to hire people who thrive in the mess. Alternatively if the work is discrete and fine grained, hire detail oriented engineers.
You don't need to do some esoteric technical test to figure out their mentality. Just ask them. Ask them of their past experience, what they liked and didn't like. Propose certain scenarios that you foresee happening if you hire them and see if they would enjoy working in those scenarios.
Some mindsets that I have found useful so far:
- If hiring at very early stage, optimise for curiousity and hard work. Hire the type of people who switch off at the end of the day by working on some obscure side project. People who can't get enough of learning a new language or framework.
- If hiring remote, do not hire unless they are a Manager of One.
- Eric's Guide to Hiring Software Developers
- Favorite Interview Questions
- Culture Fit Interview Questions
- Good Remote Work Literature?
# One on ones
- Track and Facilitate Your Engineers’ Flow States
- Square’s Growth Framework for Engineers and Engineering Managers
- Mozilla Career Track
- A Senior Engineer's CheckList
# Exit interviews
- Start with comments of gratitude for what they have done.
- Do you mind if we go over some questions?
- What contributions are you most pleased about?
- How did you find the team?
- How did you find the working structure?
- What was the worst part about working here?
- How do you think we could have used your skills better?
- What are your thoughts on the company?
- Anything else you'd like to add?
- Next steps: disabling access to accounts, handing over any equipment.
- One job, many roles. The different skills needed to be a successful CTO
- No Kings: How Do You Make Good Decisions Efficiently in a Flat Organization? https://hn.premii.com/#/comments/20155636