At CharlieHR we have two parts: 1.a remote tech test. Limited to two hours (though not timed - honour system only). Any language, any libraries. 2. in house p

At CharlieHR we have two parts: 1.a remote tech test. Limited to two hours (though not timed - honour system only). Any language, any libraries. 2. in house pairing exercise. This is 90 minutes pairing with me implementing a simple thing. Any language, and libraries, all the online docs you want. They do most of the coding and should talk a lot about what we’re doing. The important thing is the nature of the tasks. We use the same two every time and their characteristics are: * not logic problems * not algorithms or data structure problems * a simple task (like – but not – telling if a given noughts and crosses grid has been won by either side) * CLEAR requirements: there is no mystery as to how they should work, and there is no logical leap required at any point * related to what we build at CharlieHR I’ve found the pairing interview to be very good for cutting through the bullshit and really getting a handle on their thinking and ability. Can they interrogate requirements and turn them into working code? It’s interesting because in theory a junior dev and a senior dev could both do very well on these problems, but it is usually evident when someone is senior thanks to the level of additional insight they provide into different ways of approaching the problem.