Live data from Hacker News

The Imposter's Handbook

impostershandbook.com

161–170 of 237 posts

Re: The Imposter's Handbook

#161

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…

Just got back from a meeting where we discussed on-disk data structures, in-memory data structures, and design of a query language for a time-series database with the goal of achieving There's lots of good stuff in the front-end and web dev space as well. I know enough about UX to understand there is a lot of depth there. If you understand functional programming you'll go a long way with React and friends (and perhaps be able to innovate in this area as well.) Not all of this is in the typical CS curriculum but that doesn't invalidate the usefulness of what is.

Re: The Imposter's Handbook

#162

I think one of things that "millennial" self-taught programmers have trouble understanding is OS. While the need to implement OS functionality is now a niche (like process scheduling), I have noticed that "millennial" self-taught programmers have gaps in knowledge with respect to threading, mutex/semaphore, consumer-producer pattern, synchronization vs. lock-free (blocking vs. non-blocking), concurrency and paralleli…

Just curious, why the "millennial" descriptor? Is having trouble understanding the OS something unique to only "millennial" self-taught programmers?

Re: The Imposter's Handbook

#163

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…

Here's another perspective. Let's say the company you joined has a culture that is big on sports, specifically American football. A lot of the people on the team care about the sport, make jokes about it, and make passing references to the current events in the game. If you're the kind of person who cares about fitting in, you might just read up on the game and perhaps browse the sports page headlines so the comments…

> Here's another perspective. Let's say the company you joined has a culture that is big on sports, specifically American football. A lot of the people on the team care about the sport, make jokes about it, and make passing references to the current events in the game. If you're the kind of person who cares about fitting in, you might just read up on the game and perhaps browse the sports page headlines so the comments and jokes don't go totally over your head. You know when to laugh.

Personally, I wouldn't want to work at a place where I felt like I needed to "fit in".

Re: The Imposter's Handbook

#164

Earlier quoted context omitted.

You will not get through a Google style interview knowing what algorithms exist. You will be expected to implement them. On a whiteboard. Almost perfectly. Without access to a computer.

"Only a portion". And almost-perfectly is a big deal. You're not expected to write compiler-ready code, just to show that you understand what's happening under the hood. Which meshes up with practical expectations -- if you can't understand what potential bugs/space/time complexity you're introducing when leveraging a library, then you're a fundamentally worse coder than someone who can.

Except this is in fact bullshit since if you're ever working on some speed/memory critical code, that's the time to bother filling your brain with the different options available and picking the appropriate one. Carrying around arbitrary knowledge to show off is pointless.

Most code most programmers write won't ever run at sufficient scale or be sufficiently critical that CPU or memory bounds will matter, and using e.g. one sorting algorithm vs another will be largely irrelevant. It's recognising when you need to bother optimising that is the sign of a competent developer.

And asking someone to write actual (not pseudo) code on paper/whiteboards - as I've seen in interviews - is like assessing someone's driving ability by asking them to mime driving a car.

Re: The Imposter's Handbook

#165

Earlier quoted context omitted.

I have a CS degree, and while nobody sits around talking about data structures and complexity that's not the point. It gives you a foundation of knowledge that you automatically and subconsciously apply to every job you do. A CS degree prevent you from making a lot of obvious (if you have a CS degree) and costly mistakes. It sort of gives you a crystal ball. You can see that some code isn't going to work when a db ta…

The thing is though that you don't really deal with this in your day to day life, and when you do, even with a few CS candidates on staff, you're going to hire a consultant with a Ph.D. in the field. Of course I may be environmentally damaged from never having worked with someone who was self taught.

I don't think that's entirely true. It comes up pretty often. You may not be doing formal proofs but it's helpful to have a thorough understanding as it helps guide intuition around scaling your product (e.g. how a database query will scale with more users). It should influence your design early on rather than be something requiring a PHD consultant later on

Re: The Imposter's Handbook

#166

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 don't have a CS degree, and while I know not to write ten nested loops it's nice to know the actual reasons behind why it's a problem. Understanding the core principles allows for a deeper understanding of what you're doing, and as a result might lead to some novel use of something. Not saying novel use or innovative stuff requires a CS degree, merely that improved understanding of the basics of computing will like…

Any body who spends any amount of decent time with a problem, eventually know hows to optimize it. This isn't just with software, its with every task on earth.

Humans have an in built ability to think about saving the effort required to achieve any task X.

Re: The Imposter's Handbook

#167

I am curious, do people actually pay $30 for an ebook without even being able to see a(propsed) table of contents of a sample of the writing? This is unusua. With both Amazon and LeanPub you can at least gauge the writer's style or get a feel for writing quality by looking at a sample chapter and a table of contents. I'm skeptical that all of those people praising the book bought the book site unseen.

apparently this is the ToC for "pre-release #2" http://i.imgur.com/ssYr5ki.png

seems like pretty simple stuff; couldn't all the information be found with one internet search away?

Re: The Imposter's Handbook

#168

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 have a CS degree, and while nobody sits around talking about data structures and complexity that's not the point. It gives you a foundation of knowledge that you automatically and subconsciously apply to every job you do. A CS degree prevent you from making a lot of obvious (if you have a CS degree) and costly mistakes. It sort of gives you a crystal ball. You can see that some code isn't going to work when a db ta…

Spending 4 years to get a CS degree gives you a lot of skills and knowledge.

But so does writing software outside of college for 4 years.

Which one is better? That's an empirical question.

Re: The Imposter's Handbook

#169

Earlier quoted context omitted.

Asymptotic complexity comes up pretty frequently in bioinformatics contexts because the volumes of data can be huge.

How does it change what you do, though? I did signal processing with massive data streams rather than bioinformatics, but I assume the situation is similar. The algorithms are what they are. They are complex mathematical equations or transformations that need to be run on data and are often optimized without being able to change their asymptotic complexity.

Skiena's Algorithm Design Manual mentions him being brought in as an algorithmic consultant to modify some genetics analysis software so that it'd actually finish but I don't really remember the details or know enough about the field to give you plausible examples.

Re: The Imposter's Handbook

#170

Earlier quoted context omitted.

I have a CS degree, and while nobody sits around talking about data structures and complexity that's not the point. It gives you a foundation of knowledge that you automatically and subconsciously apply to every job you do. A CS degree prevent you from making a lot of obvious (if you have a CS degree) and costly mistakes. It sort of gives you a crystal ball. You can see that some code isn't going to work when a db ta…

Spending 4 years to get a CS degree gives you a lot of skills and knowledge. But so does writing software outside of college for 4 years. Which one is better? That's an empirical question.

Usually here is where we observe Dell, Gates and Jobs didn't finish college. But that's more about business than engineering.
Post reply on HN