I wouldn't want to penalize kids who are really relatively inexperienced for not coming up with the fastest solutions on a test. Even if they're in 11th grade and have a couple of years under their belts, they likely haven't been in real situations where run time is important. If I were to want a specific run time on a test I'd say something like "for full credit make sure your solution runs in O(blah) time." If I give an open ended solutions and I don't specify any restrictions on run time, storage limitations, or data set size I tell the kids that I won't penalize them for efficiency unless it's so grossly horrible. For example, if they were to write a sort in their code (and I wouldn't really ask this but it makes for an easy example), I wouldn't penalize a kid for coding an N^2 sort even if we covered nlogn unless I talk about a large data set size. On the other hand if they sorted by say an N^3 solution or worse, they would lose some points. In any event, if you're requiring certain run times you have to be careful that you're not just getting kids to memorize and spit back what the teacher expects. Also remember that there are plenty of times where a simpler, slower algorithm is both clearer and more than sufficient and that complex fast code that doesn't work isn't nearly as good as simple code that does. To encourage creativity, give multi level assignments. Create lessons where you can have them develop a solution, see that it's too slow, and then refine it. I do that with finding the mode of a data set (https://cestlaz.github.io/posts/2014-11-17-hidden-complexity.html). You can also create assignments that encourage this and make test data sets and situations that force kids to work on time efficiency issues.