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

101–110 of 237 posts

Re: The Imposter's Handbook

#101

Post by chris11 »

sotojuan wrote: post #77
chris11 wrote: post #45

Earlier quoted context omitted.

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 targ…

Sure, that's fair. Do you think you would've gotten at least a phone interview had you had a lot of experience and a good resume (aside from the non-target school)? I have friends who have such experience in finance and firms won't even look at them because of the university name in their resume.

I don't know what their criteria was. I guess they could have skimmed it for a few seconds. I actually just had a classmate tell me that they just had an interview for an internship at that company.

But I can say I do have a good resume. I have a little bit of full time experience (before I decided to go to school full time for cs) and an internship at a company they recruit from.

So it's technically not an immediate disqualifier. But I did get a rejection quickly enough that I think it might have been automatic, and my school is still listed as "other - please specify" on their internship application.

Re: The Imposter's Handbook

#102

Post by matthewking »

continuational wrote: post #43
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?

Having a degree doesn't guarantee that you're automatically better than anyone without one, there will be good and bad people on both sides. People that don't take the traditional education route will generally be self studying through private courses or just reading lots and lots of books. It takes a lot of drive, determination and study skills to do it on your own too. Additionally many of them may have been able to break into the job market early, so they'll have years of real world experience and learning from peers by the time they would have usually finished their degree.

Re: The Imposter's Handbook

#103

Post by apeace »

I have a funny anecdote about CS.

I am a CS dropout who has been working in startups for a few years. About once a year, I see another programmer making a common mistake, and I draw on my CS knowledge to help them out.

The mistake is parsing HTML with regular expressions. It is so tempting to write a good ole' regex to grab that attribute value off of that element. And it works on the 5-6 samples you write your unit tests with. If you have run into this before, you may know that zalgo[0] tends to appear in this situation. Parsing HTML with a regex will always fail eventually.

Of course the reason is that HTML is not a regular language. It is a context-free grammar, and thus requires a parser to parse it.

The funny part is, I failed CS Theory once, and was in the middle of taking it again when I decided to drop out. But this tidbit of knowledge has always stuck with me, and I've used it again and again to fix or prevent bugs in real software.

Takeaway: CS knowledge does have real-world value to everyday programming. You just have to know what you're looking for. And of course, always use an HTML parser to parse HTML.

(I'll add one more note to anticipate a common response. If you look at any HTML parser, you will see regular expressions in the code. These regex are used for chunking the HTML, and from that point the chunks are parsed.)

[0] https://stackoverflow.com/questions/1732348/regex-match-open...

EDIT: Formatting

Re: The Imposter's Handbook

#104

Post by eksemplar »

EliRivers wrote: post #71
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…

"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..." How about in job interviews? Obviously never on the actual job, but how about interviews? They ask all sorts of crazy crap. I suspect because they've got no idea what to ask.

I live in Denmark, so the short answer is that I don't. Big-o came up in an interview once, but it was mainly along the lines of being asked if I knew what it was and me answering with a yes.

I've spent a semester doing all sorts of silly algorithms, including * sort, so it's not like I couldn't handle them if it was ever required. The thing is, time to market and code consistency will almost always leave you using the standard libraries which came with your environment.

There are obviously a few jobs where it's relevant, but I'm into things like architecture, digitizations and business development, so I'll never work one of those jobs, and neither will 95% of you.

Re: The Imposter's Handbook

#105

Post by philippeback »

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…

When you deal with large data sets (e.g. Hadoop/Spark...), BigO starts to hit badly.

Dynamic Programming also requires you to have a clue about it.

See https://www.youtube.com/watch?v=OQ5jsbhAv_M for some cool explanations.

Re: The Imposter's Handbook

#106

Post by nulagrithom »

r0fl wrote: post #83
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.

It's a way to easily filter when you get 1000 applicants for 1 job posting. Not the fairest but it's quick.

And an even easier way to filter out the company.

Re: The Imposter's Handbook

#107

Post by steve_g »

mattmanser wrote: post #67
jredwards wrote: post #52

Earlier quoted context omitted.

I have no degree in CS and I see these terms regularly. So I google them and read about them.

You don't know what you don't know. The point of a book like this is that some who knows what you don't know from being asked questions about things he didn't know by people who did know, he now knows what you don't know and can tell you what you need to know. The only knowledge you have now is of known unknowns without knowing anything at all about the unknowns unknowns. Know what I mean?

You should have ended with "You know?"

Re: The Imposter's Handbook

#108

Post by dineshp2 »

haylem wrote: post #31
teekert wrote: post #20

Earlier quoted context omitted.

I have no degree in CS and I see these terms (Big O, np vs p, etc) regularly, mostly here on HN. No idea what they mean, this books sounds great to me.

> mostly here on HN Which may or may not be an accurate depiction (as we read personal accounts and thoughts of the commenters) of a quite marginal subset of real-life IT-professionals. I wouldn't worry too much about what's being said or not said on HN. There are great ideas and topics to be covered here for sure, but they're sprinkled on top of a giant cake made with 1-part self-loathing, 2-parts day-dreaming, and…

> I wouldn't worry too much about what's being said or not said on HN. There are great ideas and topics to be covered here for sure, but they're sprinkled on top of a giant cake made with 1-part self-loathing, 2-parts day-dreaming, and 1-part regular huff-and-puffing.

I don't understand your argument regarding why you would not pay much attention to what is being said on HN. Could you explain?

Re: The Imposter's Handbook

#110

Post by riskable »

fitzwatermellow wrote: post #58

As an alternative, I would recommend something like Michael Kerrisk's The Linux Programming Interface in lieu of a survey of foundational CS. Gaining a deep understanding of memory, files, processes, threads, signals, sockets, etc. As well as strong Emacs-Fu and bash scripting ability. These are the first steps on the path to mastery ;)

What's interesting is that what you're talking about is computing fundamentals. Stuff that kids should be learning about in high school before they go to college. At the very least they should teach kids what happens when they type a character in a text editor and then save that as a file. Kids should know that the key switch state change gets detected by the keyboard hardware, sent as a signal over the wire, detected/handled by the OS/kernel/driver, sent to the program as an actual keystroke which decides to "display" it to the user by updating the interface, etc etc.

Discussions surrounding what happens when two programs try to write to the same file. How to detect when a file changes. Stuff like that. These things just don't seem to come up in high school education and I can't help but wonder why. It'd go a long way to giving people explanations as to what's wrong with their computer when it's running slow or a basic means of interpreting error messages/conditions.

Post reply on HN