An initial tweak of the grouping exercise requirements, based on team feedback

[sbatistoni-zl]

We can go a lot further here, possibly redesigning the exercise entirely, but for now I think this will take care of some common issues we're seeing, namely:

• Submissions made in a language other than Ruby are frequently harder to assess, even though the rubric says they're fine.
• Because the instructions are so sparse, there's wide variability in what people do and don't include, as far as documentation and tests goes. The new wording strongly encourages them to consider those things, whilst still leaving them to decide what they "normally provide".

[jxdx]

Looks good! I ran it through AI, any better?

General Instructions:

• Do not fork this repository when submitting your solution.
• Your solution must be written in Ruby.
• Ensure that you have the legal rights to use any code you include in your submission.
• Your submission should be complete—it should include tests, documentation, and any other artifacts you would typically provide in a production-ready pull request.
• Our interviewers will need to run your code, so carefully consider dependencies and provide clear setup instructions.
• If you have any questions or need clarifications, don’t hesitate to reach out.

[KieranCormack-Zipline]

Two things come to mind.

1. Do we have a time limit on this? Or a time recommendation?
2. When it comes to documentaiton I think a very important skill is documenting deficiencies or areas of improvement. I know there are non-performant ways to solve this problem. If they get a solution that is non-performant but they talk about how it might be improved I feel like that goes a long way and can be a great starting point for the techincal interview.

[jxdx]

Very true! Most people have full time jobs and I believe we advise them not to spend more than a couple of hours on this. Calling out short comings goes along way for me as well.