61–70 of 100 posts
Question: At what point in a career do you expect someone to have gone from "I know Big O" to "I know how this data structure is laid out in memory on this OS?" My experience says really good engineers know the latter, but I'd like to hear if this holds for others.
Earlier quoted context omitted.
A major force driving this is the employers who choose to conduct interviews in this way. I'm a developer with about 6 years experience in full stack web app development (Rails & Django mostly), and I recently got my ass absolutely kicked during a couple of live coding challenges that were very heavy on theory (also worth mentioning that I'm a self-taught dev without a CS degree). I started talking to some former cow…
Self-taught as well. It’s a game. All the big name software co’s and the startups founded by former big name software devs like to play it. Heck, I’m starting to enjoy the game (primarily because I have exceptional pattern recognition skills). I was failing interviews too until I picked up an undergrad CS algorithms book and read through the first few chapters on data structures and theory. Then I signed up for LeetC…
def print_first_item(items): print items[0] This function runs in O(1) time (or "constant time") relative to its input. If this were C where the only types are fixed-size, that might be true. But in Python it seems like items[0] could display as 10 gigabytes of JSON. And if stdout is piped to a process that isn't consuming its input, it might never terminate naturally. Also, since Python has arbitrarily large integer…
in C, it items[0] could segfault, the fault could be caught by a signal handler which does some unbounded amount of work, then populates the appropriate memory location and returns... More realistically, the page of memory that items[0] is sitting on could be swapped to disk, requiring the OS to do some big operation. trying to write a piece of code with the big-O you are looking for generally has a huge number of ca…
But it is doesn't matter here because we have chosen n to be the size of the array, because it is what we are studying.
Here it is big-O "constant time" because the execution time doesn't depend on on the size of the array, assuming it is really big. Not that every call of the function will take the same time to run.
The reality is much more complicated, with things like caches to take into account. As a result, complexities under O(n) often don't mean much in practice. But the higher you go, the more important it becomes. As you get to O(n^2) it is time to take a hard look at your algorithms, or make really sure that n is small and stays small.
We're doing a poor job with navigation on the site ATM, so here are some "you might also like" hits for you:
A piece where we derive most of the main data structures step by step, starting with naked bits in RAM: - https://www.interviewcake.com/data-structures-and-algorithms...
A reference / cheat sheet for the main data structures: - https://www.interviewcake.com/data-structures-reference
A reference / cheat sheet for sorting algorithms: - https://www.interviewcake.com/sorting-algorithm-cheat-sheet
Earlier quoted context omitted.
Where I work we give people real problems to solve during interviews. We have a great team that gets a lot of work done. In hiring we put emphasis on practical expertise with the tech we use and the problems we face and not academic puzzles. There's immense value in having a strong computer science background and I feel we've had success being able to get a sense in our candidates where they stand without the standar…
Can you give an example problem? I wonder how rigorous non-algo challenges can be inside of an hour. Or how you would “get a sense” of CS fundamentals without algo tests.
What are the top level concerns, how do you break that problem down, how might your problems scale, etc. There's a lot of questions I'd expect to get to, and this should be something done along with the team kind of like we're all working on the problem together.
I find it useful to see how well people can talk through the problem, it can lead easily into questions about licensing and rights of reuse, types of errors, etc. If they suggest an approach they've used before, can they explain likely failure cases / benefits? Are there workarounds, detection methods? For example, if you're doing text classification then tfidf+svm is a solid first thing to try, and there's easy ways that can fail which we could talk about.
There's a lot of that you can cover in an hour, and it tests whether someone can explain a potential solution to the team effectively, just as they would have to on a day-to-day basis. We can bring up specific types of problems that we face within it, what we've tried, and we can constrain the problem more or lead someone to starting points if it's a bit overwhelming.
edit - I guess this would fall under some data science fundamentals, but the approach I think works for CS fundamentals. What data structures could you use? What are the tradeoffs? It's not about finding the one optimal solution, but about how to proceed.
Earlier quoted context omitted.
It depends on the company, but most of the FAANG company (and others that try to imitate them) interviews come down to how quickly you can get the optimal solution on the board. It has very little to do with how well you can code day to day. Most interviews have 4 sessions broken up in the following manner: 1 hour: coding 1 hour: coding 1 hour: lunch 1 hour: system design 1 hour: cross-functional In my experience tho…
> The other funny thing is that your previous experience doesn't do anything for you other than maybe getting to skip the technical phone screen. Everyone goes through the same process You could also argue that this is fair chance between those who just came to the field. > On the bright side, it does look like many companies are now realizing this isn't a great way to evaluate someone's ability and are beginning to…
It /might/ be /somewhat/ true. But I'm skeptical.
Anecdotally, when I started Interview Cake 6 years ago it was already true that most small companies my friends and I interviewed with were using these sorts of data structures and algorithms questions. The handful of exceptions were mostly companies that were outside the "scene" (usually because they weren't in SF or NY).
> not-boring math What's next? Gradient decent with no gradients? Fourrier transform with no functions? If math is do boring just skip the whole thing, don't try to kid yourself by saying you're not doing it when you are in fact doing it. /rant
Big-O notation is a useful tool in a programmer's belt, knowing the math behind it in details is less useful. What's the problem? It's the same thing as not needing to know how an engine works to be able to use a car
> not-boring math What's next? Gradient decent with no gradients? Fourrier transform with no functions? If math is do boring just skip the whole thing, don't try to kid yourself by saying you're not doing it when you are in fact doing it. /rant
What's with this gatekeeping attitude? Big-O notation is a useful tool in a programmer's belt, knowing the math behind it in details is less useful. What's the problem? It's the same thing as not needing to know how an engine works to be able to use a car
Big-O notation is a mathematical notation. By using it, you are using math. It's the same as using a car and saying you are not using a car.