1. Codility (to my knowledge) skews more short coding challenges, whereas ours are more practical project-based assessments. We're trying to assess "can you build" versus testing computer science concepts
2. A few things have worked for us. One big thing is to position our candidates as fully capable of receiving full-time offers, but that if they move quicker (via one interview then an internship offer) you can sign with them quicker than they would finish up their full-time interviews, or else they may miss out on great talent. The other, is this "try before you buy" mentality around lowering the risk for full-time hiring. They already do it with students, why can't they do it with non-students?
1. Codility (to my knowledge) skews more short coding challenges, whereas ours are more practical project-based assessments. We're trying to assess "can you build" versus testing computer science concepts 2. A few things have worked for us. One big thing is to position our candidates as fully capable of receiving full-time offers, but that if they move quicker (via one interview then an internship offer) you can sign with them quicker than they would finish up their full-time interviews, or else they may miss out on great talent. The other, is this "try before you buy" mentality around lowering the risk for full-time hiring. They already do it with students, why can't they do it with non-students?