I understand the resistance to flash cards as rote memorization without being able to build upon them, I think that's a cogent criticism. At the same time I think some people will be able to take advantage of this to build their toolbox.
And as a minor note, I personally love when people can name an algorithm or concept. There was one interview that I think I completely failed, but I was able to name (but not write out) a concept. I actually incorrectly name dropped Hamming distance, when it was actually the Levenshtein distance, but I was able to diagram the concept behind it. I passed that interview (to my tremendous surprise), and I think the name drop and the simple diagram helped.
I literally had someone write down the exact answer for an algorithm question that appears on GeeksforGeeks down to the small bugs which the post had originally.
how did you know/verify this?
wondering why an interviewer would go GeeksforGeeks and other interview sites and match a candidates answer line by line.
"Memorizing" these algorithms isn't the approach I'd use at all. No interview of mine will ever be of the form "implement such-and-such well-known algorithm".
However, my questions do begin with "imagine we're on the x team and we have y technical problem - what should we do?", and it's helpful to have a toolchest of coding techniques that includes hash tables, trees, etc.
I still having a hard time understanding the use for this after the job interview. The few times I’ve had to deal with data that was large enough to be big O and needed to optimize it, I just spend some time researching it a bit. Plenty of answers online for those cases. Someone who actually enjoys thinking and researching this subject, but not I’m not going to grind hackerrank.
It actually stopped me for even considering to apply at a company that uses this as a bar. A developer generally is someone who solves business problems, sometimes with code.
I’m happy that I work in a country where this grinding is not the norm.
Otherwise buy a $100 android and use the free app. Or use the windows and Linux versions (free too)
For example, it is infinitely more useful (faster implementations, more proven code, less maintenance overhead, free upgrades) to be familiar with iconv and the data available in the Unicode database than to memorize random facts about encodings.
That's actually the popular opinion.
Unpopular opinion: programmer time is more valuable than machine time up until the product starts to scale and/or outlives the savings. A programmer spending a week longer on doing something right might cost you a couple thousand dollars up-front, and would repay itself only in a decade. Then you scale 200x, and suddenly that suboptimal code is bleeding you those thousands of dollars a week.
Very unpopular opinion: the above examples is a good case; if your AWS bill gets too large, somebody in the company will start asking questions. What usually happens is that performance is externalized to end-users. It's their CPUs that burn through fossil-fuel-generated electricity that much faster and can no longer run more than a few apps at the same time; it's their mobile phones that need to be replaced a year early because of the aggregate bloat. It's their sanity that's being assaulted by laggy, constantly acting up devices. But it doesn't manifest itself as a separate line item on the company's books, so nobody gives a damn. Instead, laziness and shoddy craftsmanship is explained away by economic self-interest.
When you study you will learn a lot of stuff that seems useless for a Software developer at his daily job.
When you only know practice you will be able to use the tools but probably do not understand what most of them do, how they do it and why. Of course this may seem useless in many cases but on certain occasions like optimization some more theoretical knowledge may help you to dramatically improve your code or architecture (It could be the other way around of course).
In the end I think no matter if it is practical or theoretical know how you may gain something from it in the future even if it is not a (typical) topic of your field of work.
A very important insight for me is that you can learn as long as you breathe and it helps you to age more gracefully while being better at what you do.
return (num & (num - 1)) == 0;
}
That looks like it'll fail when num == 0. I think it should be:
return num && ((num & (num - 1)) == 0);