While we're at it, the function name `aTypicalDay` is one of the poorest naming choice I've seen in a while. Is it typical or atypical ?

In camel-casing, a capital letter indicates the start of a new word. Therefore this is clearly "a typical day" while "atypical day" would be "atypicalDay".

wouldnt't atypical day be atypicalDay and a typical day be aTypicalDay? following camel case nomenclature the function name seems to suggest a typical day and is aptly named.

I would interpret the former. Presumably the latter would be "atypicalDay"

All I could think about after that first image was giving the author a code review.

Also note that the "easier" interviews are from companies that are less competitive/less established. So their offers are going to be lower not because the candidate comes off as less qualified, but because they just don't have the money to pay their employees the 120K+ salaries. So that graphic is also misleading.

This hasn't been my experience in general. Most of my hard interviews were at startups. To sound old and jaded, I think a lot of it has to do with the startup mentality "we only hire the top 0.0001% of coders " . Once you've been in the business for years you realize the fallacy of that thinking and try to hire good coders with a focus on finding people fun to work with.

Most big companies I applied at had about half of the grilling and the rest of the interview was "culture fit"

I'm a bit jaded about startups myself and I'm not even 30. The couple I worked in seemed like "we are so smart" cults, which drove me absolutely nuts. The people working there were smart, but their definition of intelligence was narrow-minded. I find it very unlikely that you are hiring the "best-of-the-best" if the vast majority of your employees are men under the age of thirty who attended a very specific list of colleges.

Running a company is a team activity. I think there are too many sports metaphors in business, but if you've ever played a team sport you realize that the best teams are usually the ones with the players who play best together, not the ones with the most talented players. I could run this metaphor in to the ground, but the point is that hiring only the "best-of-the-best" is neither a credible claim nor a good methodology for creating a successful business. You might be able to do that when your company is 5 people, but it's probably much better to have good role players who are a cultural fit for your organization in the long run.

Advice I give at all levels is if you're getting bored at your job start interviewing again even if you're not going to take it because: you never know && you need the practice.

Looks like your refactor could use a test or two :p

OMG - you're 100% right and I've already passed the "you're still allowed to edit or delete this post" time limit imposed by HN.

This is going to be a black mark on my OCD coder's soul for the rest of time. A code typo immortalised next to my name.

/sigh.

There's a lesson for me... Never. Ever. Attempt to be clever on hackernews.

Thanks for pointing it out.

... I wonder if HN mods would be willing to spare me this suffering. Undoubtedly a waste of their time.

Judge and you will be judged :)

Seriously, the original code is not too bad and probably what most people would write if the inputs and functionality of that function are only complex enough. "Hm, what else goes into isPrepared? Do I have to consider anything else before returning true or false?"

Just fix it in the parser. ;)