Ask HN: A question for those who went to MIT/Stanford/CMU | Hacker News Reader

Ask HN: A question for those who went to MIT/Stanford/CMU

38 pointsartisfury53 comments

I am wondering what's the learning environment and what behavior makes folks at these and alike school smart. They don't get hung up on new Javascript framework or new language. My observation is that top performers from this school are focused on solving problems. I have met quite a few who are very smart folks but they are not chasing new Java/Scala/GO language feature. Heck, some even don't know Java programming.

Despite this, these folks solve hard problems and often solve it better than anyone else.

I am curious about distinction between chasing new language/technology/language vs solving problems. How do you see yourself after graduating from these schools?

View on HN

I think that focusing on undergraduate credentials as a measure of engineering ability is largely unproductive, and phrases like "they don't get hung up on new Javascript framework" are stereotypes, and you will meet many counterexamples. To be clear, these schools turn out plenty of mediocre engineers.

Usually, the selection process of which you're seeing the results is that kids who are very good at engineering will choose to go to one of these schools to maximize the chances of meeting like-minded people.

These people were already budding great engineers in beforehand. The schools they attend do not apply some kind of Midas' touch that turns an ordinary person into a great engineer or scientist.

So, I think your proposition has its causality inverted. Potential great engineers often end up at MIT/Stanford/etc., and they continue being great engineers. It is not the case that MIT/Stanford produce great engineers by having some magic classes that the other top-20 schools don't.

>that MIT/Stanford produce great engineers by having some magic classes that the other top-20 schools don't.

They also have rigorous DS&A courses that make it easy to get into top companies, but the rest of the Top-20 schools have those too.

I would assert that, given that great engineers end up at these top unis, they are able to widen their gap with others by a) accelerating their skills/knowledge by associating with like-minded individuals, and b) being stretched by their respective colleges.

My observation is that top colleges tend to lump more work of greater breadth and depth in their students.

It's like joining a great sports academy where you develop faster by constantly being in competition with your peers and by also training harder.

I think this assertion is accurate.

/second, came here to say this too. The top schools give their students much more, harder problem sets, exams, etc. than others. Some grade on a curve too, meaning that if everyone scores between 90-100, they don't all get A's, rather the bottom third gets C's, the mid 90s get B's, and the top third get A's. Creates an extremely competitive environment that pushes folks with raw talent to really work hard to hone it. Finally, most of the work is focused on learning problem solving methodologies, rather than learning the syntax and grammar of particular languages.

Yes. Competition is a powerful motivator. I recall at CMU one day when they gathered all us ECE students together in an auditorium and said "There are an order of magnitude (base 2) too many of you here - we will have to fail half of you out. Look to your left. Look to your right. Those two students may soon be gone." Swear to God a true story. Any fellow classmates ('88) can vouch for the meeting. Meant that a "C" was a great grade since you got to stay. Was terrible for one's GPA however.

its a common engineering thing. In my Dad's EE class in the mid 60s they did the same thing.

rutgers did the same thing iirc

What modern top level colleges scale grades downward?

On the topic of curriculum Robert Harper has some good posts on reasons why CMU jettisoned their entire curriculum and rewrote[1] it from scratch back around 2011 and it's success[2]. It really is a great curriculum I haven't seen at other schools that focuses on verification, functional programming and parallel algorithms.

[1]https://existentialtype.wordpress.com/2012/08/17/intro-curri...

[2]https://existentialtype.wordpress.com/2011/03/21/the-dog-tha...

It's rather simple: A proper CS education, one that has all that "useless" theory that a number of HNers love to deride, equips its bearer to understand how anything in the software world is implemented. You don't have to study as hard to pick up a new technology or stack because you will know roughly what the underlying implementation has to look like and can simply poke around to identify the components and interfaces that you know have to be there.

Or, as a recent blog posting that made HN succinctly put it "'How' ages faster than 'Why'" (https://news.ycombinator.com/item?id=13500883). Knowing the "why" of CS means you never have to chase the "how" of the latest flavor of the month stack or framework.

yeah … it's about the high-order bit, thinking at a higher level of abstraction … learning a language vs. learning why the language is that way, how to design a language.

This seems a bit like saying a physicist is more capable of understanding how satellites work than an engineer who designs satellites because he knows the underlying theory better. It's kind of true in some sense but doesn't really capture the context or nuance that goes into a non-trivial engineering effort, or the more general case asserted by the topic author.

That's not a very good analogy. Most would agree, I think, that the separation between CS, as taught in most programs, and professional software development is far, far smaller than the separation between physics and aerospace engineering.

Well, that's another discussion altogether. I'm of the view that the closeness of professional software development to academic CS is one of the biggest problems in the industry from the perspective of regarding it as an engineering discipline.

Agreed.. software engineering, as usually practiced, is definitely a craft. It's a very technical craft, but still a craft discipline.

I think that's just a function of how much money is in the field - more people end up in industry than academia AND industry has an even bigger interest in pushing the boundaries. This leads to blurring between the lines of industry and academia.

I'm sure if there were more money in subatomic physics we'd observe the same thing.

Not really. More like: if the way you make satellites dramatically changes on a continuing basis, then some solid knowledge in physics might prepare you better to adapt to the changing times than being trained in the current methodology.

It's going to be difficult to draw a generalization because I have mostly my experience from MIT, but I can't tell how that's the same/different as others from MIT or other schools.

For me, MIT taught me how to think more than it taught me anything specific. Sure, I learned a bunch of engineering, but mostly, I learned to be skeptical, to think through and quickly identify the key aspects of a design, a business, or a model and zero my efforts in on the sensitive areas and ignore (or minimize investment in) the routine parts. (Part of it is you get this secondarily from having such a firehose of work and interesting opportunities around you.)

In industry, it has made me skeptical of the framework flavor of the week, but I also don't want to be forever stuck in K&R C, so there's a balance to be struck.

I also wouldn't be overly impressed with an MIT grad just based on that fact. Getting into MIT is hard. Getting out of MIT mostly takes determination.

I would add to that MIT taught me how to learn new topics very quickly without much handholding at all. That's the skill that makes one not so prone to obsess on one framework versus the other, because if necessary you can learn both.

Back in the day (perhaps still the case today?) there was not a single "learn to code" in some specific language anywhere in MIT's EECS department. There was Sussman's SICP class which taught scheme more or less in the first week. Barbara Liskov's class taught her research language named CLU more or less the same way. As a short diversion before getting to the meat of the course.

CMU grad here, working on a PhD.

First, don't put too much emphasis on school. Great programmers can come from anywhere.

Many other commenters are emphasizing the role of selection effect: top-tier schools select good students, rather than teaching well. I think the effect of good teaching shouldn't be undervalued. Although, again, good teachers and courses can come from anywhere, here are some things CMU does or did in the way of pedagogy:

1. Focus on concepts and skills, not specific technologies. Many of CMU's intro courses are taught in Standard ML, a language used by basically nobody. This levels the playing field, forcing people who think they already know everything to learn things from a different perspective. It puts the focus on how to design and reason about programs, rather than the minutiae of popular languages.

2. Have project-based courses. The star example here is CMU's operating systems course, which is a thing of beauty and terror. At many schools OS courses teach you trivia about hardware. CMU's OS course involves some of that, but is mostly about (a) working with a partner (b) time management (c) designing concurrent programs. The compilers course is of similar quality.

3. Teach math-as-problem-solving. CMU has a course, 15-251, which is notoriously difficult, because it introduces you to a lot of discrete math very quickly. This is partly because discrete math is the core of CS theory; most programs will never need this, but when you do need it, knowing a bit of theory can save you days or months. But the other goal is to simply practice solving difficult conceptual problems.

I went to one of these schools. I know the basics of java but pray to the spaghetti monster I never have to actually work with it.

Most people I knew at school were a lot smarter than me. And the thing I noticed about them was that they saw things more abstractly. It wasn't about semi colons, or the latest frameworks; but a desire to see things a little more generally so that their understanding could apply to large classes of languages.

Beyond languages, another thing this helped with was being able to use mathematics, computer science and logic to model parts of the world with some level of mathematical rigor. In other words, answering an under defined question systematically by first formulating it rigorously.

One more thing abstract thinking seems to help with is that it makes learning new concepts a little easier. And so, being at these schools probably also teaches people how to learn, which can be useful throughout life.

"It wasn't about semi colons, or the latest frameworks; but a desire to see things a little more generally that could apply to large classes of languages."

This is the number one most important lesson a software developer can learn. Strive to understand the underlying abstractions and patterns, make sure to have a broad experience base so you can see many different ways these abstractions and patterns are applied in different languages and frameworks. You will be far more useful as your career progresses, quicker to learn things, able to spot the good and bad in the latest buzzwords.

I did not go to one of the 3 named schools but my observation over the last 20 or so years has been that while not a perfect correlation, better CS programs tend to do a better job instilling this sentiment into students.

Just by their admission standards, these top tier schools are going to have a higher percentage of very smart students who are fundamentally prepared for college and have learned how to learn. At the university, they also have an advantage of learning from and interacting with a faculty who are themselves, leaders in their respective fields. Thus, there are opportunities to participate in cutting edge research that isn't offered at other schools.

A computer language is simply a tool to get things done. Education isn't about learning the latest and greatest tool but applying what you know with what you have in an effective and productive manner. To wit, Fortran, that old-timey language from the 60s, is still being used in modern research in physics, electronics, and other technical disciplines.

I went to one of these schools. I disagree with fellow HNers who say that the students are great engineering minds or have the right motivations from before hand.

These institutions do a damn good job at making you very very strong on your foundations of CS and problem solving and architecture. They deserve a ton of credit. They focus much lesser on teaching you cool and trendy stuff, and much more on grounded understanding of everything that forms the foundational basis of computing technology, especially in the first 2 years of the 4 year programs.

I've spent a lot of time around Stanford and Berkeley CS grads. The main difference I would say is not that they are particularly more intelligent than anyone else, but that they are filled with an incredible amount of motivation. They tend to be extremely driven, focused people who are capable of putting in tons of work to "get shit done". They also tend to have a million different things going on at once (clubs, side projects, jobs, etc.) and have every moment of their lives scheduled out.

CMU grad here, currently working on a PhD. All I can say is, this description doesn't apply to me. I'm definitely of the "work smart, not hard" persuasion. Persistence, I guess I have; but not an unbounded work ethic, or the focus to work on ten things at a time. Persistence for me means finding a new way to attack a problem, not pushing as hard as possible, John Henry style.

PhD student here, and I'm exactly the same. I procrastinate a lot (not good!), but I've been able to get things done. My current goal is to figure the optimal way to minimize procrastination...

I've recently made pretty good gains at minimizing procrastination.

First, I simply eliminated working on anything I didn't really need and/or want to do. I don't need to think about doing stuff I don't plan on doing!

Second, anything that needed to get done, I scheduled it. For simple tasks, I just created morning and evening blocks of time for home and work. The repetitive stuff I do first, and then I work on one off stuff until I don't feel like doing it anymore. It just gets done in the next block. For example, scanning N tax documents is lame, so I scanned maybe a dozen in one block, and just did the rest the rest in the next block. For important things, I schedule a single purpose appointment, and do my best to just make it happen.

Lastly, I bought a wall calendar, and nailed it to... aait for it... my wall. I "x" out every day I feel like I attended to the stuff I said I was gonna do. If I don't feel a "x" has been earned, it is usually for a specific reason, and I try to address that reason. I choose not to care about the "x" streak, days in in a row. I simply use the calendar to gauge whether I'm being as consistent as I'd like to be.

I've gone made pretty good gains on transitioning from Professor Procrastinator to Captain Consistent. Will always be a work in progress :)

Thanks for sharing!

This morning I wrote a note to myself that I didn't earn the "X". I've been trying to wake up at 7a, and go thru a start of day checklist. I want the "X" damn it. Tomorrow, maybe I'll read the checklist. Still, I got way more done this morning before heading into the office than I would have if there was no concept of a plan :)

Nothing wrong with that. Life isn't supposed to be all about work. I've made plenty of money working smart, not hard. I enjoy building stuff, but I'd much rather prefer working less than more (and I do). Laziness (in some way or another) can often also drive innovation.

That, and I don't believe you can be really productive for more than 3-4 hours straight (even a day, unless you take a long break) anyway on a consistent basis.

20% of the effort often gets you 80% of the way there. At that point you have to decide whether putting in the additional effort is worth it. Sometimes it is, sometimes it isn't.

Lots of people responding to the "get shit done" post seem to be talking about how they procrastinate or "think" but don't like to work hard. If you want to get to the top of your field, whatever it is, it's not enough to just be smart. You also need to love to work hard in your field.

If you don't love to work hard in your field and you do want to get to the top of the field, you're on a road to problems because everyone at the top of your field is as smart as you are AND they are driven by passion to work incredibly hard. You can't get into their league without both.

So, if you want to get to the top of your field and don't want to work hard in it, my advice is either (a) find the joy that makes you want to work hard or (b) find a different field that does bring you that joy and desire to work hard.

(Note there is no requirement that you want to get to the top of your field, this is just for those who do want to do so)

Yeah man coming from CMU there is an intense focus on not getting lost in microtrends and "new" ideas which are simply rehashing what's already been done. You want to avoid poisoning your mind by learning say functional programming in Rambda.js instead of going straight to the source. Before CMU I would pour over blog posts by amateur developers arguing that Ruby on Rails is always better than PHP or some other trite overdetermined point like that. After school I will actually look at their background to see if they are someone worth listening to or if there are just another bad developer with an opinion. A lesson that stuck with me from systems class was (paraphrasing here) "you want to be the power programmer who truly understands how the system works and can solve bugs nobody else can, and the only way to do that is to crack a book and read about how operating systems work, how networking works, etc instead of being stuck in user land, unable to deal with situations where the abstractions break"

The second half of your comment really resonates with me. I was generally pretty good at really understanding how things worked at the system level, but there is one friend I used to work with who was simply amazing at it. He was the guy who would go deep on our web farm, figure out what was wrong in the garbage collector, monkey patch a workaround, and send a bug report to Microsoft with what needed to be changed on 16-core NUMA machines, saving us 25% of performance across the farm AND reduce page times by a 100ms or so. Or troubleshoot a sporadic network issue by isolating the issue via testing in production (without access to the network gear) and tell the network team where the bottleneck is. (Needless to say, this can ruffle some feathers of the easily offended, or with the people who believe that purity is more important than functional and that one simply shouldn't write code that understands you're running on a NUMA machine, but it was amazing to watch time after time.) He's moved on to another local company where I've heard from him (and others) that he continues to do the same over there.

Regardless of your education, once you learn a set of technologies well enough it generally becomes easy to just start working on a problem.

Also, I don't mean to be invidious but, programming languages are normally the easy part: Unless you jump from (say) VB.Net to Haskell most programming languages are actually fairly similar. In fact, programming languages are boring: Once you know a few, particularly if you know a bit about compilers (e.g. can work from the specification/grammar, Haskell made sense only after I'd read SPJ(possibly et al)'s, it becomes fairly easy to pick up a new programming language. However, software engineering is very important (e.g. Style, testing and optimisation, i.e. for the cache, are all very important skills that I'd assume most people learn by themselves.

I'm 16, so I can't exactly speak from experience; I also don't have any data: My guess would be that because of the difficulty of getting into the top schools/Unis, they cream off the top students. These students then spend years honing their skills, however (assuming your observations are true) they get particularly good at the more rigorous/theoretical side of their science. Supposedly, that would help you focus on the stuff that matters(TM).

In practice, I think that this is probably not true. I'd be fairly surprised (Or shocked) if MIT et al just spat out magically excellent engineers. I'd guess, that it just provides a nice foundation to learn on top of.

Not sure about those particular schools, but my experience of CS is that it is completely separate from the going ons of the commercial market.

I believe most schools stick with traditional tools for educating, using Haskell and C for projects, although some are moving towards python.

I'd be surprised if any of them teach any javascript whatsoever unless you took a course specifically on that topic.

I went to Stanford, class of 2010. I got a BS and MS in computer science; the MS was with Stanford's "coterm" program where you can earn credits towards your master's degree during your four years as an undergrad.

* what behavior makes folks at these and alike school smart *

My experience was that almost everyone I met at Stanford had done something pretty extraordinary in high school. Examples: teaching an AP science class, being an amazing pianist, doing well at national science fairs, being a published author.

To answer your question: Almost everyone was very smart, but at least at Stanford there was great variety in the kinds of intelligence on display. This was true even among CS majors.

* what's the learning environment *

I'm not totally sure what you're asking about here. Undergrad CS classes were pretty similar to what you'd see at most universities: Professors lecturing, then people taking home exercises or programming assignments. Collaboration was usually encouraged on exercises, and programming assignments were usually done in groups.

My honest experience was that a lot of big courses were not particularly well taught. The first few CS courses are an exception; they're taught not by professors but by lecturers, who are all really good.

The best CS classes I took were graduate "seminar"-type classes, where we'd read a few papers each week and then come to class and discuss them. Shout out to Dawson Engler; his operating systems seminar was inspiring and eye-opening.

I can't speak as much to non-CS classes. I took some math and physics classes; these were pretty traditional, with lectures and written homework. Collaboration was encouraged on homework, and personally I wouldn't have been able to get through those classes without help from my friends.

* How do you see yourself after graduating from these schools? *

Again I'm not totally sure what you're after with this question. One of the best things that happened to me was that I became friends with musicians and biologists and English majors; people who are (academically, anyway) quite different from me. I learned to dance, and swing dancing has become a huge part of my life.

I work at Google now, and that's pretty humbling. Working at Mozilla when I did was as well. But life isn't all work, and in a lot of ways the non-CS stuff I learned in college has been much more impactful to my life and how I see myself.

In my first college adventure, I learned Fortran, Algol-60, Simula,PL/I, APL, BCPL, and five assembly languages (MIX, IBM 1620, PDP-11, IBM 360,Burroughs 5500). We used Knuth AoCP volume I. My first job was programming a proprietary microprocessor with a mostly secret, weird architecture.

In my graduate adventure at Stanford, the course work was in Pascal, our research was in Ada (83), and I learned C, C++ (using Cfront), Prolog, Smalltalk, Lisp, and some formal specification languages. Assembly languages included DEC 10/20, VAX, Data General Eclipse, Sun IV, Cray I, and Sequent. Hennessy and gang were creating MIPS, and the CISC versus RISC debates were everywhere. My first job after Stanford was programming C and assembly language on IBM's brand new, unannounced RISC/System 6000 with a Unix-like OS. My next job was C programming on OS/2 on a very large office system with a homemade object oriented structure using C macros. The next job was a DARPA distributed system using CORBA where I brought in brand new Java to solve our multi platform GUI problem.

New programming languages are mostly boring; a Frankenstein collection of reused parts, badly stitched together. New frameworks are mostly silly.

Thanks to all of the parsing research in the early 1960s,resulting in LEX and YACC, plus books like the Dragon book, and Cooper's Compiler book, and LLVM, many programmers can invent and implement programming languages. But that does not mean that they SHOULD. Programming language design require aesthetics, which are not taught in Computer Science. Knuth's books are titled The ART of Computer Programming for a reason.

Could it be that rather than the impact of the school, you're simply seeing how people who are capable enough to do well at these schools approach problems?

When graduating, I knew I'd had the joy of working on real problems, designing real things, and being surrounded by really smart friends doing the same.

Much later I realized the classroom learning I'd thought was getting in the way of my experiential learning was what gave me the discipline to dig in and learn the things I needed to know to do the things I wanted to do.

Very little of my CS education at MIT took place on a computer or in a language other than English. Watch an OCW lecture to see what I mean. You aren't dealing with anything more than simple C/Java notation or pseudocode if you see code at all. You learn the concepts and data structures in abstraction from their implementation.

Many top people have been very self-motivated at some point in their lives. When you experience this, you can sit down and work on problems in flow day after day without fatigue -- even when the going is rough. It feels like solving a puzzle, where you get excited figuring out how every piece fits.

And then burnout kicks in and everything goes out the window. Even if you feel unlimited energy, make sure to take a break every now and then. Just my two cents.

Bigger question to me is - how do we non-Top4 plebs rise to even 70% of their level?

Study some of it yourself https://functionalcs.github.io/curriculum/ though you miss a lot not being in group projects, getting feedback from TAs and profs, ect.

I go to a school ranked ~48 by USNews. Concerned that I'll be I'll always be scraping the bottom, salary and respect wise because of it.

CMU/Stanford is full of grad students who went to so-called lesser ranked schools. You could also do the background work and get one of your professors to write a recommendation for you to attend the Oregon Programming Language Summer School or other summer conference where you can learn from these Stanford/CMU/MIT professors and other students. https://www.cs.uoregon.edu/research/summerschool/summer17/sc... a friend of mine did this every summer and hustled a lot of internships out of it working in research at top schools because they remembered his name from the conference and emailed him when looking for interns after they received grant money.

Valid points, but I don't have a 4.0 or any publications yet (I'm a junior). It feels like grad school is out of reach a top school.

This is a great resource but looks incredibility intimidating, has anyone completed his and provided feedback as to how the curriculum is set up for self learning?

Because there's an enormous spectrum of talent at those schools and outside those schools. For every top MIT/Stanford/CMU grad, there are 20 more people someplace else in the world with the same raw talent and ability.

What kind of problems do you have in mind?

Those are _very_ different programs.

Reply on news.ycombinator.com