|
|
|
|
|
|
by drdrey
3104 days ago
|
|
|
Thanks for the detailed feedback! Here is what I mean by "necessarily contrived IO": in a more realistic setting, we might have to answer a question like "what host returns the most 500s?" coming in an email or on a support channel. Or one I actually had to answer a couple weeks ago: "what are our most frequently firing alerts?" That is all of the problem statement right there, not a detailed description of the formatting of the input and the output. Just a user with a question, so you have some work to do to understand what is being asked and how you can find the most time-effective way to answer it. I might have follow up questions like "over what time period? For a particular service or all services of team X? Just in prod or in all environments?", etc. The user also didn't ask for a specific format, I just need to get an intelligible answer with reasonable effort. So based on the context, maybe bash makes sense to answer a one-off question rapidly. In the context of a customer facing app, maybe introducing some abstraction makes sense (again, context). This is whst I would consider a more realistic "on the job" setting, you have to understand users and make trade offs and understand constraints and it's all a little bit fuzzy. In contrast, an online judge necessarily imposes more rigid constraints because of the automated verification -- I don't really see a way around it. |
|
|
> an online judge necessarily imposes more rigid constraints because of the automated verification
The platform is evolving to not be as rigid anymore as well. For example, we have a product (in a closed beta) which assess candidates on complete projects (eg: build a nodejs app that defines this api and behavior), and testing and scoring is based on unit test cases.
This way, you are testing for more real-world usecases, and also allowing the flexibility beyond straight IO.