Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Imposter's Handbook

impostershandbook.com

Post reply on HN
Print view View original

41–50 of 237 posts

Re: The Imposter's Handbook

#41

Post by marcosdumay »

eksemplar wrote: post #13

I have a degree in CS and I've never found myself in a situation where anyone would discuss bouble sort vs merge sort. Neither have I been in a situation where big-o was relevant beyond the basic concept of not doing obviously stupid shit. What you've really missed is things like best practices, design patterns and concepts like SOLID, but a lot of people with CS degrees missed some of those as well. If the book cove…

> Neither have I been in a situation where big-o was relevant beyond the basic concept of not doing obviously stupid shit.

How do you know you are doing stupid shit if you don't know about complexity and don't know your algorithms?

Really, I do work on CRUD applications from time to time, and I often have to select algorithms based on complexity. Yeah, didn't have to implement one of them for ages¹, but I do have to tell coworkers things like "here you use a set", "here you use a list", "this sorting algorithm isn't stable", or "nah, just use brute force and get done" once in a while.

1 - Or, better, did implement a B-tree for a side project just a couple of months ago. Ended up just throwing it away, but I didn't know I wouldn't use it at the beginning.

Re: The Imposter's Handbook

#42

Post by lanna »

eksemplar wrote: post #13

I have a degree in CS and I've never found myself in a situation where anyone would discuss bouble sort vs merge sort. Neither have I been in a situation where big-o was relevant beyond the basic concept of not doing obviously stupid shit. What you've really missed is things like best practices, design patterns and concepts like SOLID, but a lot of people with CS degrees missed some of those as well. If the book cove…

http://www.joelonsoftware.com/articles/fog0000000319.html

Re: The Imposter's Handbook

#43

Post by continuational »

anexprogrammer wrote: post #18

The main thing people miss out on not having a degree is not getting past silly HR "must have degree" filtration. Never once found a CS degree a worthwhile indicator of ability. It may be a superb book, but not even giving a sample chapter out to judge writing style, quality of explanations, depth and so on?

Comments like these can only really have two causes:

- You've bought into the anti-intellectualism wave that's going on in the US.

- The universities near you are really poor.

Is it really the case that you learn so little on these universities that you literally have no advantage over those who didn't attend?

Re: The Imposter's Handbook

#44

Post by marcosdumay »

drak3 wrote: post #32

The excerpt on the Boolean Satisfiability Problem reads > The basic concept that people have figured out, so far, is that a number of NP-complete problems can likely be solved if we crack the Boolean Satisfiability problem. And > If NP-Complete problems get resolved, it is likely (though nobody knows for sure) that we'll crack every NP-Problem Isn't the definition of a NP-Complete problem exactly that it is in NP _an…

You aren't missing anything. It's wrong.

Re: The Imposter's Handbook

#45

Post by chris11 »

sotojuan wrote: post #30
6DM wrote: post #22

Earlier quoted context omitted.

Even funnier, coming across companies that don't accept anyone who doesn't have a degree from xyz university.

That's the case for some elite finance institutions, but does it happen with programming?

I once got a rejection from an internship application late one night a few hours after I applied. I wouldn't be really surprised if I had been automatically rejected. And my rejection might have been because the state university I went to was not specifically mentioned in the drop down list of schools, it was in the "other" category. I think I might have not gotten a rejection so quickly if I had been going to a target school like MIT or Stanford.

Re: The Imposter's Handbook

#46

Post by kchoudhu »

marcosdumay wrote: post #41
eksemplar wrote: post #13

I have a degree in CS and I've never found myself in a situation where anyone would discuss bouble sort vs merge sort. Neither have I been in a situation where big-o was relevant beyond the basic concept of not doing obviously stupid shit. What you've really missed is things like best practices, design patterns and concepts like SOLID, but a lot of people with CS degrees missed some of those as well. If the book cove…

> Neither have I been in a situation where big-o was relevant beyond the basic concept of not doing obviously stupid shit. How do you know you are doing stupid shit if you don't know about complexity and don't know your algorithms? Really, I do work on CRUD applications from time to time, and I often have to select algorithms based on complexity. Yeah, didn't have to implement one of them for ages¹, but I do have to…

I have libraries that make sure I don't do stupid shit.

Re: The Imposter's Handbook

#47

Post by Clubber »

anexprogrammer wrote: post #18

The main thing people miss out on not having a degree is not getting past silly HR "must have degree" filtration. Never once found a CS degree a worthwhile indicator of ability. It may be a superb book, but not even giving a sample chapter out to judge writing style, quality of explanations, depth and so on?

I think there is more to a degree than that, but you make a good point. Now a days, instead of trying to figure out a problem, coders try to figure out which framework has already figured out the problem. It allows for less experienced people to get things done, but limits you to being able to mortar together bricks rather than make bricks.

The problem arises when you need to make bricks. You don't necessarily need a CS degree to make bricks, but you need to learn most things taught with a CS degree.

Re: The Imposter's Handbook

#48

Post by squeaky-clean »

lamacase wrote: post #16
jcbeard wrote: post #8

Anybody else vaguely reminded of The Fountainhead's cover: http://www.steinerag.com/flw/Book%20Images/Fountainhead1994.... For some reason the combination of "imposter" and the colors evoked memories of an old paperback.

The cover actually appears to be one of the jpl "visions of the future" posters. http://www.jpl.nasa.gov/visions-of-the-future/images/superea... I hope the author has permission to use it?

NASA are extremely liberal with how you're allowed to use these images. There are other people selling prints of them, for example.

"Unless otherwise noted, images and video on JPL public web sites (public sites ending with a jpl.nasa.gov address) may be used for any purpose without prior permission, subject to the special cases noted below."

The "special cases" mostly deal with using the NASA or JPL logos, or using photos with real humans in them commercially.

http://www.jpl.nasa.gov/imagepolicy/

Re: The Imposter's Handbook

#49

Post by smnscu »

datguacdoh wrote: post #28
anexprogrammer wrote: post #18

The main thing people miss out on not having a degree is not getting past silly HR "must have degree" filtration. Never once found a CS degree a worthwhile indicator of ability. It may be a superb book, but not even giving a sample chapter out to judge writing style, quality of explanations, depth and so on?

I've interviewed somewhere around 200 people at this point and from my perspective, the degree, university or GPA have had no correlation with how well the candidate does. Now, I interview for Ops roles and not software engineering, so this might not apply across the board for other roles, but I have my doubts.

It'd be interesting to correlate not just credentials to interview performance, but credentials, interview performance, and actual job performance. There is however the challenge that for the third aspect you can only assess the people that passed the interview and accepted the offer.

Re: The Imposter's Handbook

#50

Post by Practicality »

chris11 wrote: post #37
Practicality wrote: post #35

Earlier quoted context omitted.

Ironically, big-O describes things that are very easy to understand, in a notation that looks complicated. If you have a lot of experience, you probably already understand the concepts. The notation just gives a clear way to describe them: https://rob-bell.net/2009/06/a-beginners-guide-to-big-o-nota... ,

True, but studying the theory gives a better intuition for big-O. And theory is helpful for some of the edge cases that can be more complicated. For instance, I wouldn't want to try to determine the run-time of a recursive algorithm with just the info in that article.

Indeed, and if you did learn these things through experience, as I supposed, then you probably did so by writing something O(2^n) and suffering when you had to process >100,000 records.

(Why does it take 100 ms for 10,000 records and 50 minutes for 100,000? ... hmm)

Learning these concepts through the theory is definitely more efficient.

Post reply on HN