Yes. I've interviewed "developers" who failed FizzBuzz, and one who took 20 minutes to come up with a solution. I've never even specified a required language for it, and generally accepted pseudo-code.
If you want a job at a bank (perhaps because they work on hard problems or because they pay a shit-ton), maybe not the best idea unless you intend never to roll up your sleeves or wear short sleeves. (Maybe short sleeves aren't an option at a bank anyway?) Happy to work at a startup? Go for it.
I always refrigerate milk, just wanted to be clear about it to explain that it wasn't going sour because I was doing something dumb like leaving it open on the counter.
The problem is that if just two or three people like the lively, chatty open office, it ruins it for everyone else whose productivity suffers by an order of magnitude in a noisy environment.
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 see these challenges as a great way for excellent experienced developers to weed out incompetent companies.
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.
I've had a similar experience. I think the organics companies just clean their equipment/tanks better or something. Regular milk with an expiration date 3 weeks in the future often turns sour within 3 days of opening, despite refrigeration. Whereas organic milk with the same expiration date, from the same shelf in the same store, will last a week and a half. And there's really nothing inherent about organic milk that should make it last longer.
Honestly, that sounds awful. I already guard my phone number more closely than my email because a) spam calls are more disruptive than spam email, and b) it's easy to make a throwaway or catch-all email; throwaway phone numbers are harder to obtain. To the point that phone numbers are being used by some systems as an identifying datum. Hell no.
It's mature. The community is mature (in multiple senses of the word). The ecosystem is mature. The package management is solid. There are drivers or SDKs for basically every tool or service I would want to interface with.
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 building life support software or manned lunar probes, maybe you want him on your team.
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.
I've never had a hire go wrong for technical reasons. I have hired, participated in hiring, or inherited several developers who had to be let go for reasons related to attitude or soft skills. Some examples:
- 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.
I don't get the drive to eliminate bezels. I mean, big bezels are a waste of space. On a laptop they may serve an engineering purpose, but no user purpose. But for handheld devices at least, it's nice to have enough bezel to be able to hold your device without worrying about activating touch response.
I think the difference is that in wood frame you can sometimes hear things through the walls. Whereas with concrete, any sort of impact (chairs moving, doors slamming, people walking in heels, the guy putting a nail in the wall to hang a picture on) gets transmitted to the entire building.
Definitely depends on the construction type. I will say that floor-to-floor noise transmission in a 19thC brownstone is a tiny fraction of what it is in a mid-20th-C apartment block. In the latter, you can hear people moving furniture or turning on the shower multiple floors away on the far side of the building.
I wouldn't necessarily use the term "exploited" (I would save that for a different sort of situation), but you've certainly been put in an untenable position.
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.