| In my experiences working with developers, there’s only a few issues that have made an employee difficult to work with. Most of it is around personality, motivation, and communication. It’s rare that I have a difficult time working with someone because they lack certain skills (but do have the motivation to learn them), and for all of the devs I’ve gotten to know and work with over the years, I feel like a detailed review of their previous work experience would have told us enough about their skills. Good things to check for: how open minded are they?
- Do they stubbornly stick with a certain way of doing things?
- How readily will they apply someone else’s feedback?
- Do they insist on doing things their way?
- Do they think all code written by others is crap?
- How much do they bristle at someone else’s code style vs working with it? How well can they communicate with non-technical people?
- How do they talk about their interactions with product managers/marketing/sales/customer service/etc?
- Do they blame any issues on customers or colleagues being "idiots"? Can they talk through a past problem they solved?
Can they talk through the whole context of a problem they solved?
- do they understand the customer problem they were solving and why it was important?
- can they speak to multiple approaches that were considered and what their drawbacks were?
- A great one is, did they go down a wrong path and learn something? - Some other things to assess are - do they focus on the right problems to solve? Do they have a history of building systems that are more complicated than they need to be? Do they over-optimize areas where it’s not necessary or do they have a sense of where potential bottlenecks might lie; how to find them; when the right time is to worry about them? If they can talk through a past problem they solved in detail, that’s a super great sign. The more detail they can get into and help you understand, the better. If they just start gushing technical details, they’re either nervous, or they had a very siloed role in developing the solution. I personally prefer engineers who can get invested in the context of a problem. When it comes to coding in an interview I’ve found that very simple coding problems can surface all the info I need about their coding proficiency.
- if the problem is simple, they’ll be able to just “stream” the code from their head on either a whiteboard or a machine.
- experienced developers will even manage to talk through edge cases and workarounds
- if they struggle with this challenge, then they’re not going to do better with a more complicated problem.
- for experienced devs I’ll want to see that they’re proficient with the syntax of at least one language (if they don’t remember a specific method name, that’s ok - problems that can be solved by a google search shouldn’t be held against them) - springing a complex coding question in front of them and expecting a perfect solution on the spot is a lot to ask for. “Real” solutions to complex problems will be debated and built upon by multiple people. If you go through this exercise, focus on how they tackle the discussion itself. - I avoid brain teasers and puzzles. There’s plenty of good developers who can solve a real-world problem well but suck at solving technical brain teasers. - In any interview, its important to take notice of how nervous the interviewee is. Some people may be able to handle interviews better than others. When you’re nitpicking their answers later on, keep this in mind. Some candidates might blank out on an otherwise simple problem; some might ramble on and seem disorganized. I’ve seen too many candidates get turned down because of a few specific details they mishandled due to nerves. |