i actually have began to enjoy places that use these types of things for interview questions. it's a good way for me to know that i don't want to work there. i once interviewed at a prominent company focusing on a certain language. they specifically stated in their job application that they just wanted motivated, enthusiastic, and smart people and that they didn't care if you knew said language. i sent them my resume…
I don't know. I get your point and understand that language is just a tool, but having a vast code base in our company in C++ (for example), we have actively interviewed people who had experience in that language and were not just "smart", as we needed someone who could quickly get to work and we don't have to teach him inheritance and virtual functions from the beginning. Also, not sure about other languages, but efficient C++ code does take some experience IMO. So, personally I'd be willing to accept a good C++ programmer for a Java/C# programming job, but the opposite might not be an easy decision.
I got an impression who their target audience is, based on the examples used, drinking kombucha and listening to Spotify. All the young, beautiful people who wouldn't have ever taken a computer science course if it weren't such a lucrative industry to be in right now. Maybe with this guide they can pass an interview at a big company where they just twiddle with bits all day. I won't be holding my breath until they ca…
BRB, gonna change it to drinking "Ensure" and listening to "Days of Our Lives" :P
Author here :) Thanks for the note--this is interesting. Target audience is folks who never learned this stuff, or learned it but forgot it. Interesting to hear you had a different assumption from the title. If you want something trickier, check these ones out: https://www.interviewcake.com/question/stock-price https://www.interviewcake.com/question/swift/find-duplicate-...
I suggest that you market the series in a different way, perhaps "An Introduction to Data Structures", or something along those lines. Out of all the bullets in your outline you really only cover lists (random access, linked) and hash tables as actual data structures. That's partly why I expected a totally different article based on the title. You could argue that the others are technically data structures, but I'm w…
Iiiiinteresting.
Definitely agree that the first half of the article isn't exactly data structures yet.
But I just struggle with calling something "An inroduction to X." Have you ever heard "an introduction" and thought "oh, that's what I need!" I picture a super-dry textbook. Or one of those YouTube videos that promises to teach you how to do a thing but starts off with the person saying, "Now, before we get started..." and talks about nothing for 5 minutes before actually teaching you the thing.
I recently added data structure visualization to a gdb frontend called gdbgui, which might be of interest to people trying to debug their algorithms. https://github.com/cs01/gdbgui
I got an impression who their target audience is, based on the examples used, drinking kombucha and listening to Spotify. All the young, beautiful people who wouldn't have ever taken a computer science course if it weren't such a lucrative industry to be in right now. Maybe with this guide they can pass an interview at a big company where they just twiddle with bits all day. I won't be holding my breath until they ca…
I once walked into an interview with such questions. On the first question I asked them why they asked the question. The interviewer looked puzzled and asked me to finish the question. I again asked him why, what part of my job would require it. He couldn't answer that question whilst he was an engineer at the department I was interviewed for. I asked a follow-up question if he had the same questions when he joined,…
Thanks for doing this. As an interviewer I like to be transparent about my interviews and explain to the candidates what I expect in the answer/code before going ahead with the question.
This is a good cheat sheet for those who don't have (or have forgotten) the knowledge but want to game an algorithm heavy interview. The problem I got with this is exactly the same as when I tried reading the "Cracking the Coding Interview" book: I got through a few chapters and then the author mentions something off the cuff with an assumption that the reader will know what they mean. But of course, I don't, because…
i have the same feelings about "cracking the coding interview" the day someone unironically asks me to "Write an algorithm to print all ways of arranging eight queens on a chess board so that none of them share the same row, column or diagonal" - I will jump off a bridge
You can finish that algorithm and then ask for a *2 wage LOL
I'm thinking a lot about folks who come out of coding "boot camps." Those folks for the most part have /heard/ of "RAM" and "disc," but might not know why they both exist and what each one does.
I would not want to hire anyone who doesn't have _some_ idea of what these things are, and how they work.
Then presumably you're able to appreciate the value in someone explaining it to them in a blog post.
I got an impression who their target audience is, based on the examples used, drinking kombucha and listening to Spotify. All the young, beautiful people who wouldn't have ever taken a computer science course if it weren't such a lucrative industry to be in right now. Maybe with this guide they can pass an interview at a big company where they just twiddle with bits all day. I won't be holding my breath until they ca…
This is what you get when you commoditise Computer Science. The article is about coding interviews and then goes on to deliver a lecture about "Computer science in plain English". Isn't it common knowledge that Computer Science and coding are like chalk and cheese?
People used to study DataStructures for a whole semester to get a deep understanding of how these work, and the time/space complexities affect system design. But now we get a pop-culture laced listicle that people will use to ace the interviews and write mediocre software. Does anyone wonder why there aren't listicles like this for Structural Engineering/Thermal Power Engineering/Mechanical Engineering etc?
No wonder we get data-breaches, password leaks, system outages, because we continue to treat Computer Science/Software Engineering as the next fad to make quick buck, and not science.
It's unfortunate, but all the companies are doing this. Here's what a Google lead said in a tweet: > Hello, my name is Tim. I'm a lead at Google with over 30 years coding experience and I need to look up how to get length of a python string. DHH: > Hello, my name is David. I would fail to write bubble sort on a whiteboard. I look code up on the internet all the time. I don't do riddles. Max Howell: > Google: 90% of o…
There's a difference between not being able to write bubble sort and realizing that looking it up is a better use of your time. But when it actually comes time to do something you can't copy/paste off the internet, what do you expect a programmer who can't reinvent a half-decent bubble sort to do? The interview is to convince the other person that you can think logically about programs. Bubble sort is a low, low bar,…
With all due respect, I hear what you mean, but further supporting an interview system so divorced from actual problem solving (because most everyone who really really wants a job just endures the empty tediusness and memorizes these algorithmic puzzles from CTCI and Interview Cake and other sources) just enforces a kind of innane candy-empty arms race just like the SAT did, before it was clear that there were proven ways to master it. (the SAT has become just another pay wall at this point) The ultimate effect of this race is to render every programmer with the money and time to practice this equal. It is, forgive me, an infinite loop (sorry) -- and the bar will just get higher and new innane hoops will be added to the performing monkey obstacle course. Then, employers will be (or already are) selecting for a kind of navy seal squad of pedantry-- coders who like to submit and follow directions and behave themselves. Creative problem solving requires a bit of the rebel/subversive spirit. These kinds of interviews may test for an intrepid spirit. But honestly, There is no more intrepid spirit than that of an actual well-programmed machine. This popular interview method reveals that we are merely looking for programmers to be as similar to intrepid, well-programmed machines as possible. It results in machine-like workers working on machines. In effect, perhaps, the blind leading the blind. Is that what we want? I could be wrong, but I think we need to more highly value what humans bring to the task/process/team that computers can't. It seems less nihilistic, anyway. Or do we not know what that is? Maybe that is the real problem. Ironically, so many job ads say they are looking for "passion" in their programmers. Passion is at odds with what they select for. I wonder if the employers even realize this. My puzzle for them is: Given n programmers (all have memorized CTCI etc) ... so how do you decide what to select for and how would you implement an efficient, blind process that is more likely to include a diverse array of programmers who could work together hapily?