|
|
|
|
|
by ChefboyOG
1910 days ago
|
|
Oddly, the last technical interview process I went through was the best and in some ways, the most old fashioned. There were three "rounds": 1. Phone screen with actual lead developer. There were some quiz-y questions here, which I'd previously thought of as a silly outdated approach, but it honestly was a low stress filter for basic technical knowledge. 2. 90 minute pairing exercise with the same lead developer. We built a small example app together. Resources were sent over ahead of time so my environment was good to go, and the expectation was set from the start that the goal was to assess how I thought and approached code, not to see how far I could get in 90 minutes. 3. 4 hour "on site" where I talked to each developer on the team I'd be joining. No technical exercises. Each person came with their own questions, and expected me to ask mine. What I took away from the experience was that companies are seriously overthinking and over-engineering the process. There isn't a magic heuristic you're going to discover that will identify "10x engineers." You can vet if someone is technically competent enough for the role, approaches software in a way that gels with your org, and if they have any red flags in fairly straightforward fashion that doesn't require enormous amounts of prep for them or your team. |
|