4 ms·
One company sent me (before the interview) a small technical assignment. After I had submitted the code, an interview was scheduled. The entire interview was an
by nimrody 7y ago
One company sent me (before the interview) a small technical assignment. After I had submitted the code, an interview was scheduled. The entire interview was an extended code review -- talking about trade-offs, about other potential solutions, etc.
I felt this was much better in that it was less stressful, yet allowed me to demonstrate both knowledge and design skills.
Another company did something similar but more thorough: They invite candidates for a full day of work where they try to solve a small problem. Then the code is reviewed and evaluated together. They also start the day with a 1-hour overview of their current architecture and you get to ask questions and talk about alternatives. I think this gives both sides a better chance of finding the right fit.
I realize this is not always reasonable.
- rhizome 7y agoI've been thinking for a while that companies should create their hiring tests from bugs and/or feature requests that came from their actual software in the past. Then they can gauge the quality of the employee for their purposes by comparing the candidate's solution(s) to those the actual employees wrote.
- nimrody 7y agoBugs I have seen in actual code are divided into two types: those that are due to the way code inter-operates with other code (sort of integration bugs) and tricky bugs (usually edge cases) in some highly dense code. The first type requires the candidate to learn a lot about the existing code base. The second requires more mental work but is atypical of real work. Implementing features sounds like a good idea. Perhaps create a small well defined system which is a simplification of the real world system and let the candidate implement some additional features.