wandering2

What was the difference in the interviews?

>front-end features like form generation and HTML templating were really important, but now they're arguably better to avoid.

Why is that?

> I was shocked to learn that the binary search program that Bentley proved correct and subsequently tested in Chapter 5 of Programming Pearls contains a bug.

Huh? How did he prove it correct, then?

>Python and Ruby get you where you need to be fast, and if you get far enough and need to scale, there are a huge number of options, from stalwart holdouts like Java and C# (now on Linux!) to newer languages on rock-solid run times like Clojure and Elixir, to whole new languages like Go and Rust.

To be clear, are you suggesting that's reasonable to do a rewrite (or at least for certain parts) from Python/Ruby when you need to scale? Is that going to be reasonably accomplishable in many cases? Honest question. Just wondering what you have in mind.

So are they outdated now?

This I really don't understand. All it takes is a simple Google search about "what can I expect in a software interview?" and you'll see right away the importance of whiteboard interviews for so many companies, especially when you are coming out of college. I don't how true the quote actually is, but for anyone, regardless of race, I feel like this is just basic due diligence if you want a job.

I've barely been to any career events at my school, and professors never mention about whiteboard interviews. My friends in CS don't discuss this either. I just learned right away when I did some basic research on job searching.

I'm a senior in CS at the moment; I declared somewhat late, and I never did any programming until my sophomore year. Before I got into in CS, I was worried that classes would assume outside knowledge (beyond prerequisite classes), and that my classmates that had programmed in high school or earlier would be way ahead in terms of ability.

In my experience (and this is at a "top" school/program), this has not been the case at all. In fact, a lot of the types that already had prior experience seemed to struggle when it came to more difficult or theoretical/mathematically rigorous classes (e.g. Algorithms & data structures etc.). I suspect that a lot of those who had already programmed did a lot of little personal projects or hacks. Maybe they learned some different languages, played around on the command line, generally dabbled in different areas of CS and software, etc. But I think the kind of skills gained from doing these sorts of things are mostly trivial. The types of problems solved in most typical apps and websites are not that difficult technically. You learn about a lot of the difficult problems in software and computability through CS material. And the other difficult problems are engineering ones - things like necessarily complex systems with lots dependencies, large-scale or scalable systems, software with high technical demands, comprehensive testing etc. etc. But that kind of thing is learned on the job, or at least in some kind of capable team working on an important project. Not by writing little scripts or apps on your own. Learning how to write readable, modularized code can be naturally (and fairly quickly) learned in intro classes if you are mindful and dedicated to improving.

However, this is just my own experience and observations. And there is no doubt that there are plenty of people out there who started at a young age, and are also superb at computer science and/or are fantastic engineers. But I don't think that in itself is a great predictor of someone's capability.

Reinforcement learning is not strictly what is considered supervised learning in ML, but it's very much in the same vein. And a supervised learning algorithm doesn't have any "knowledge" of the domain it's learning about either - it just adjusts its parameters based on training example and class/output pairs. RL attempts to find the best actions to take to ultimately maximize a measure cumulative reward, i.e. a signal which provides an objective measure of performance (much like the class or target output of a training example used in supervised learning).

RL is definitely not unsupervised learning, which in contrast, attempts to find some structure in unlabeled data.

What do you mean by "bliss states"?

What did you like about that AMA? As many of the comments expressed, most of the answers were very vague, and the whole thing was pretty much a tease.

>Basically, it is a specialized method of learning faster and retaining knowledge more comprehensively. Think about it -- what percentage of what you learn do you retain? In all likelihood, you are losing information almost as fast as you are gaining. Second, assemble the information into a useful format within your mind. Then, find out where inventions emerge within the mind. Turns out, you won't like the answer. Your mind invents in a place you may not be able to access. Break into this space and you will be inventing quickly, methodically, and reliably. To solve the learning problem and the thinking problem will take some years.

>I invent using a specific system that was developed by myself and a colleague when we were in college. The system allows one to invent in whatever field you want and methodically (you will definitely solve the problem more effectively than even the practitioners within the field). However, there are specific limitations. However, it is one of the few "systems" that is methodical and that can be taught. It is not random. My colleague has something like 60-70 patents and is also a successful inventor and intrapreneur. He did not like being independent so he has stayed at a large company. I went solo.

Everyone wanted to know the details of these ideas, but the OP refused to provide any specifics, not even a very general overview.

Despite this, there were a few interesting tidbits concerning patents and about how he generally approaches his career and problem solving. I'd really like to know more about his process though.