It's basically impossible these days to find an office where someone who needs quiet to concentrate can get work done effectively.

Whereas in an office where quiet is the norm, you can always go to the kitchen if you really want to chat.

I'm a kick-ass get-things-done full-stack web engineer. I've never had to deal with one of these sorts of problems in my day to day work; and if I did, I'd just find an existing, tested, stable library that already handled them.

A company that needs someone to solve these sorts of problems doesn't want me on their team in the first place, nor would I thrive there. A company that just needs to build damn good web apps is losing out by using these sorts of questions in their interviews.

The best interview challenge I've had (actually, it was a take-home, with discussion in the interview proper) was about designing code for re-use and extension. It was a great indicator of the company's practical and mature approach to engineering, and of what they really wanted this hire to accomplish.

The syntax is rich but concise. It doesn't require compilation of binaries. It does OOP pretty well. It does procedural pretty well. It does web pretty well. It does throwaway command line scripts pretty well. It does performance well enough for the things I do with it. It's portable.

Python isn't perfect, but 99.99% of the time it gets out of my way. I must, can, and do work with other languages. I constantly find them frustrating me in small ways. Python generally doesn't do that.

If you're a startup trying to find product-market fit before you run out of funding, better to ship a few bugs every week (in features that have an 80% chance of not existing or being rewritten anyway within a few years) than nothing at all for months.

Also, I'll note that three of the above employees were sourced via referral from either other employees or friends of execs.

- a guy with an alcohol problem who would disappear for a week at a time or come in to work sloshed

- a junior developer who had major problems with authority, mixed with bizarre paranoia. He refused to take direction from his team lead and had to be let go after he started accusing anyone and everyone of trying to undermine him.

- a guy so obsessed with doing everything perfectly that it took him a year to produce what other engineers could accomplish in a month. Granted, his work has been running for 3 years now without a single bug, but even taking that into account he still wasn't cost effective to have on the team

- a developer who refused to take ownership of his projects and insisted that everything expected of him be specified down to the pixel (might work at a large corporation, but not a startup - we don't have time to hand-hold like that)

- a guy who was hired as a junior mobile engineer and then began throwing fits when we denied him the authority to change the priorities of the entire web and mobile product team

Takeaways:

It's fairly easy to assess who is and is not capable of developing basic CRUD apps. Getting meaningful information about a person's neuroses, self-management ability, and ability to play well with others is extremely difficult in the space of a handful of hours of interviewing.

It sounds to me as if the problem here is not the pay grade but the expectations. Did you know what those expectations would be when you agreed to the project?

What you're expected to get done in the designated number of hours sounds to me as if it would be unreasonable at virtually any pay rate. Assuming the app you're building has a certain level of complexity, I wouldn't expect those results in that time frame from anyone less than the most experienced professionals. And it's obviously unreasonable to expect you, as a student, to work at an equivalent velocity.

My guess would be that the people in charge of this project don't actually understand the work involved in it. Either way, I would run, not walk away from it.