3 ms·
> Technical interviews are much harder today than they used to be. Engineers study for months and routinely get down-leveled despite that. Beyond Cracking the C
by neilv 2y ago
> Technical interviews are much harder today than they used to be. Engineers study for months and routinely get down-leveled despite that. Beyond Cracking the Coding Interview, in addition to covering a bunch of new questions and topics, teaches you how to think instead of memorizing. Grinding and memorization isn’t the way in this market (though in fairness, it’s never really the way). With us, you’ll still have to do the work, of course, but we’ll teach you to work smarter.
It's like they're doubling-down on the steaming load of BS that is the techbro interview.
Please permit me to share my 'review' of the original book, which I made when I gave away my copy on an MIT-internal free-stuff email list.
> Date: Friday, October 20, 2023 7:53:39 AM
> Subject: [Reuse] "cracking the coding interview" book of satan
> "Cracking the Coding Interview" 6th Edition
> I literally just opened this book to a random page, about 1/3 of the way through, and the first thing I read on the page was, "You should first ask your interviewer if the string is an ASCII or a Unicode string. Asking this question will show an eye for detail and a solid foundation in computer science." With no hint that the writer was aware of the irony.
> However, since some successful tech companies were founded during the dotcom boom by students with no professional experience, they adopted hiring filters based around a cocky student's idea of what is important in software engineering. Then, subsequent startups, without the benefit of dotcom gold rush handing gobs of money to anyone who could spell "HTML", looked at those companies that had a lot of money, and thought "I, too, want a lot of money, so I should mimic whatever that big company with tens of thousands of worker drone employees does." Now we have a whole lot of startups who are filtering their hiring with a mix of fratbro hazing rituals, and attacking anyone who climbs the ladder in the middle of the room to reach the bananas.
> This book will tell you not to climb the ladder to reach the bananas. Simultaneously, it will rot your brain, crush your soul, and make you a terrible person when you're later on the other side of the interviewing table and you inflict it upon someone else.
> Unfortunately, I have old-school conditioning against destroying books,no matter how offensive and harmful.
> TO CLAIM: Please email me and say *which day* you promise you will no-contact pick up, in Mid-Cambridge.
> TO NOT CLAIM: Kudos, and maybe you join me in telling companies who recommend this book as interview prep material, "No, thank you".
(Epilogue: That copy of the book went to someone who responded, "As a linguist (and ex CS person) who is now considering selling her soul to big tech because academia is not a lot more better, I'd be interested in this cursed book!")
- anotherhue 2y ago> > You should first ask your interviewer if the string is an ASCII or a Unicode string. UTF-7 they reply, with a twisted glint in their eye.
- stmw 2y ago10/10 ! :)
- michael_mroczka 2y agoYou got me! Hahaha :)
- stmw 2y agoI'm sorry, this is just non-sensical -- I do not mean to say that all interviewing practices are good or that there is not a lot of great humor in your post giving away the original book -- but as someone who has hired many software engineers and persevered through some coding questions as a candidate, these things have value. IT's nothing about "worker drone" or "rot your brain" -- companies need some ways to see if people can 1. code and 2. collaborate before adding them to the team. Candidates need ways to understand what those hiring processes (not just the coding question) are like and to have a fair chance to prepare for them.
- neilv 2y agoI'm going to quote again part of that passage to which I literally flipped open the book: > Asking this question will show an eye for detail and a solid foundation in computer science. Which question an experienced programmer who developed string routines in a low-level language might well ask, and maybe that's who the authors stole it from as they were collecting material for the book, so that readers of the book could then BS and pretend to have thought to ask it, like this author recommends, although the author should also know it has almost nothing to do with CS. Perhaps one would protest that this bit isn't representative of the book. Feel free to argue that God was guiding my hand, to the only bit of poo in the book. But then you have to ask yourself why God thought that taking down this book was so important, for Him to intervene. So I actually skimmed much of the book, and I'm confident in saying that it's full of poo. Initially, this idea that people should have study hundreds of pages of material specific to interview rituals was maybe a little too familiar, to people of a certain socioeconomic class. Like an admissions-gaming "prep" service, which in the past you'd give to affluent kids, to give them special advantage in getting into a prestigious school, if you couldn't afford to buy the school a new building. OK, we could be wrong about the snotty pedigree angle, so let's consult the author's bio on the book's Web site: > Gayle is the Founder / CEO of CareerCup.com and the author of two books: Cracking the Coding Interview, Amazon.com's #1 best-selling interview book, and The Google Resume. She has worked for Google, Microsoft, and Apple and served on Google's hiring committee. She holds a BSE and MSE in Computer Science from the University of Pennsylvania and an MBA from the Wharton School. Which makes it look like not only a full-of-poo Ivy fratbro gatekeeping ritual, but -- plot twist! -- one that then was then cleverly sold out, by an MBA, to turn it into what's effectively a protection racket. (Youse have a lovely career potential; its would be a shame if somethings was to happen to it, because you didn't buy the book and memorize these disingenuous BS performance rituals.) Back to your point: you don't need this full-of-poo book, nor the full-of-poo smug halfwit nonsense behind it, to assess "if people can 1. code and 2. collaborate". That's not what this book is about. You instead have to be smart, and stop forcing people to be full-of-poo corporate drone performers. Hey, you know what, if you hire people like this book, even if you had a gazillion dollars, you'd have to throw away almost every new product they develop, for over a decade, and then eventually some upstart will come along and overnight destroy the single gazillion-dollar product (gifted by ancient ancestors, from before BS took over), which you've been coasting on all that time, because you're telling everyone from the very start, at the interview stage, that the company is about acting full-of-poo.