cauterized

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.

Not to mention that discrimination in hiring decreases opportunities for minorities. Which in turn increases recidivism.

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.

But I did learn the principle, back in school. I've just never needed to use 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.

How do you structure your reference checks? And what do you do for new hires who are very early in their careers and don't have real work references?

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

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.