Okay. Now you're sitting with an interviewer to talk about your home asssigment. Turns out there were some changes in a system and you program needs to evolve accordingly: actual format is protobuff struct and API is asynchronous — you send a bunch of tasks, server queues them up and gives you ids, after some time, results are pushed to a client as they come up. You must store data in SQLite and account for HTTP or REST errors (retry logic, etc.).

Your one liner is neat and all, but now you have to do 2-3 hours of initial work + w/ever time it takes for adjustments in 2 hours scheduled for an interview.

You could've thought out this toy architecture up front with initial simple implementations or at least discuss what they expect you to provide, but instead you wrote a shell script for some nefarious reason, even though you saw obvious disconnect between estimated time and time you actually spent.

Nah, i'd hire the guy with the 1 liner over the guy with the robust architecture any day. A robust architecture is great and all, but I think it should be built after a need for it has been proven.

When I was a junior developer, I was just trying to get code to work. When I learned design patterns, and had some bad experiences, then I started architect "robust" architectures for everything. After perhaps 6 or 7 years of doing this, I started to question my insanity. Sure there were several instances where I was like "Damn, really glad I built it like that" but there were an equal amount where it just ended up turning a simple problem into a complex problem. There's no good excuse for that.

So now, I go high school simple first, and college hard later. If it means I have to do some rework, fine. I'm okay with a little rework, because in the end it aggregates to a simpler platform that took less time to build.

Agreed, the thoughts of an experienced developer. Some related methodologies/acronyms: Lean development, MVP, KISS

This is ridiculous. There are so many changes in requirements there (asynchronous with push results being the biggest), that everyone is going to have to throw away what they wrote an start over.

Anything beyond 10-20 lines for the solution to this problem is pointless levels of abstraction and would be a huge red flag.

I wonder how many responses fail the assignment for making assumptions like this (that 'numbers' means 'integers').

    $ cat file
    1
    1.2
    3
     4.5

    $ egrep --only-matching '^[0-9]+' file
    1
    1
    3

Surely still demonstrates ability, but an automated testing suite is going to throw it out.

Sure, but imagine all you knew was C++, which is true for many people. Several hundred lines of code right there. I'm a hiring manager, given questions like this and seen that exact result. Remember that many people cannot solve fizzbuzz.

You need a library for HTTP calls and that's it. Pick your favorite one and write the code.

Never had a problem with that. It's well known that C++ can't do anything on it's own.

Then your choice is whether you want to hire people who only know C++. For some jobs, you don't. But if you do, you need to have multiple tests and choose one based on the candidate's skills.

We have an in office test--the dev sits down at a laptop with internet access, gets clear instructions and scaffolding code. We know that the tasks take n minutes because we see the time that candidates take.

if the numbers are preceded by a space or another symbol your regular expression fails to parse them. You should be more cautious in your assignments.