Tech interviewing is terrible, as we all (hopefully) know.
I've been through the interview process at quite a few companies, and one of the more frustrating aspects is the sheer repetitiveness of the early-stage technical screening questions.
So, naturally, I began to develop solutions which don't quite match up to what interviewers are likely expecting. Think of it as malicious compliance, applied to tech interviewing.
Feel free to use these solutions as you wish.
Would you ever actually use these in real interviews?
Maybe. Probably only if I'd already decided the company wasn't going to be worth my time, and even then I often just hang up on bad phone screens.
But companies *have* to use questions like these to weed out fake coders!
That's not a question. But: no, they don't. I've run a lot of interviews, and my opinion is that the epidemic of "fake coders" is vastly overblown. Also, most interview processes these days copy Google, which admits that its approach has a high false-negative rate (i.e., they flunk a lot of qualified people), but for some reason people interpret failing a Google-style interview as being synonymous with "unqualified". That's a shame.
Why bother, though? If you can come up with clever solutions like these, you're obviously qualified! Just give them what they want and move on to the next stage!
Thanks for the vote of confidence. But, while I think I am qualified to work as a programmer -- and have been doing so, at companies large and small, for many years -- I still sometimes freeze up in interviews. And I'm not alone: among candidates who get the highest average ratings on interviewing.io, fully one-third bomb at least one interview. The way to fix this is not to put up with it; the way to fix this is to change how companies interview.
So work on improving your employer's interview process, instead of being mean to screeners.
Also not a question. But just so you know: I have put in effort to improve interviewing at companies I've worked for, and I'm proud of what my efforts have accomplished. However, the industry as a whole is still terrible, and sometimes a kick in the pants is what's needed.
Do you actually write code like this in real life?
Some of the solutions make heavy use of Python's itertools module and functional-programming-ish features, which I'm a fan of and do use when appropriate. But Python is my language of choice largely because I like writing readable code; these interview-problem solutions are just a way to blow off steam and have a little fun.
I get errors when trying to run your solutions!
Again, not a question. But try using Python 3. I tested all of these solutions using Python 3.6.
I've seen some of these before! Why didn't you credit people?
When the basic idea that led to one of the solutions here came from someone else, I've credited it; all the code in this repository, however, was written by me. But great minds tend to think alike, as the saying goes, and I wouldn't be surprised to find someone else coming up with similar solutions to stock problems.
Can I contribute a new question or a new solution to this repository?
You can open a pull request if you want to. I can't promise I'll review it quickly, or merge it, since I've got a few repositories of actual code I'm responsible for, but I always like to see clever and novel approaches to stock questions.