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

71–80 of 237 posts

Re: The Imposter's Handbook

#71

Post by EliRivers »

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.

Re: The Imposter's Handbook

#73

Post by PUSH_AX »

squeaky-clean wrote: post #62

I'm always pretty skeptical of anything that offers "Learn X Quick!". Is there any reason I should trust the author of this as a good source? They even state they only started learning this stuff a year ago. I wouldn't take a course or buy a book from anyone claiming only 1 year's study in any subject, why should CS be any different? edit: It's also hard to find the author's name to find out who they are. It's not in…

http://rob.conery.io/about/

Re: The Imposter's Handbook

#74

Post by RealityVoid »

qwertyuiop924 wrote: post #57
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…

The problem with design patterns and SOLID is that they're sometimes followed in a cargo-cult like manner. You don't necessarily get good code just following a set of instructions. You have to apply common sense, and know the tradeoffs of various approaches. Experience is the most important think to have, and it's something I lack, admittedly. CS is no substitute for that, but it's still an important part of getting…

Experience is good, but I find some people have a "knack"... they intuitively understand when something is good and when not. How do you instill that? Priming from good logical and mathematical education help. Nudges to think for yourself and thins of the reason things are done a certain way sort of help. What more?

Re: The Imposter's Handbook

#75

Post by [deleted] »

qwertyuiop924 wrote: post #57
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…

The problem with design patterns and SOLID is that they're sometimes followed in a cargo-cult like manner. You don't necessarily get good code just following a set of instructions. You have to apply common sense, and know the tradeoffs of various approaches. Experience is the most important think to have, and it's something I lack, admittedly. CS is no substitute for that, but it's still an important part of getting…

[deleted]

Re: The Imposter's Handbook

#77

Post by sotojuan »

chris11 wrote: post #45
sotojuan wrote: post #30

Earlier quoted context omitted.

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 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.

Re: The Imposter's Handbook

#78

Post by riskable »

ThePawnBreak wrote: post #55
kchoudhu wrote: post #46

Earlier quoted context omitted.

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

That's the point, there is no magic library that can do this for you. For example, let's say you're writing Python and have a list of receipt numbers. When you get a new receipt, you want to check if it's already in the list, so you do the pythonic thing: "if receipt_nr in receipts", assuming that the standard implementation of this operation in the library is efficient. The problem is, a set would be a lot more effi…

What's funny about your example is that using a set in that situation would be an example of premature optimization. If your entire list of receipts fits into memory users won't notice a difference between a list and a set.

Also, if you used a list in Python (or other similar dynamic languages) swapping a list out for a set is a trivial operation...

    receipts = []
    # ...becomes:
    receipts = set()
...and it would require no changes to the conditional logic of the application. So later, if it turns out you're having performance issues you (usually) make a few minor changes here and there and get your 10x or 100x or even 10,000x speedup.

Re: The Imposter's Handbook

#79

Post by hibikir »

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?

Oh yes. While this might not be a hard, publicly facing requirement, I have seen resume review processes that took into account things like school or whether you have worked for a hip, big name tech employer.

If your sensible resume with 10 years of experience doing work on an in demand field doesn't even get a recruiter call back, it might be because you did it for an enterprise company the recruiting team doesn't really know anything about. Chances are that no engineering manager ever got to read it.

I for one have worked with people coming from all kinds of backgrounds, and I don't think that the filtering makes any sense. My favorite software engineer hire had a Physics degree from Missouri-Rolla, and whose career highlight was work at a company that makes billing software for telcos. She would not have been given the time of the day in a lot of big tech companies.

If I was leading a company's recruiting strategy today, I'd aim at those kinds of candidates: If I aim at pedigree, I am competing, both economically and prestige-wise, with all the big names in tech. If instead I aim for the kinds of people that the market undervalues, I'll close more candidates and keep them longer.

Re: The Imposter's Handbook

#80

Post by qwertyuiop924 »

RealityVoid wrote: post #74
qwertyuiop924 wrote: post #57

Earlier quoted context omitted.

The problem with design patterns and SOLID is that they're sometimes followed in a cargo-cult like manner. You don't necessarily get good code just following a set of instructions. You have to apply common sense, and know the tradeoffs of various approaches. Experience is the most important think to have, and it's something I lack, admittedly. CS is no substitute for that, but it's still an important part of getting…

Experience is good, but I find some people have a "knack"... they intuitively understand when something is good and when not. How do you instill that? Priming from good logical and mathematical education help. Nudges to think for yourself and thins of the reason things are done a certain way sort of help. What more?

That's actually kind of what I was trying to say...

CS is no substitute for experience, but it helps.

Post reply on HN