"...if you're trying to get better at technical interviews, the best way to do that is to actually do it."
No dammit, I don't want to get better at technical interviews - I want to live in a world where we don't need them. Why not fix the root problem instead of amplifying it?
I agree completely. But for now, that's a pipe dream. If you want to be in this world, resources like this do help. "Cracking the coding interview" is a great study resource, but how do you actually get feedback and practice? This could be useful.
I wouldn't discourage someone from becoming a software developer, since there are good careers to be had here. But in general, I think it's probably a good decision to go into a different field, if you have the skill and talent to do so, and you aren't bound by visa restrictions that limit what jobs you're allowed to work,
This is valuable. Thank you for creating and posting it.
First, it's an excellent reference for people who don't really understand technical "interviews" and their exam-like nature. Most interviews in other fields do probe knowledge, but interviews in our fields really are exams.
Another factor is that there's very little knowledge of information out there. We take these exams under conditions of secrecy, with very little feedback. For example, there are scores for my performance on interview exams in a database somewhere at google, but I'm not allowed to know how they were judged, who scored them, or what the scores are. I actually don't know what would be considered a good or bad performance. This site helps me get a better sense of how these are conducted and evaluated.
From a business point of view, it's also clever. People really do want to get feedback, the kind they can't get from Google or other interviewers, in part because of liability issues. So by providing an area to practice, the placement site can identify people who are most likely to get through the technical interview - which means they are most likely to place candidates. Not bad.
That said... I'm still not surprised that people who have the skill and focus to become software developers take a look at how tech interviews work and decide that they would much rather work in a different field.
The complexity of the forwarded message problem is wrong. Any algorithm solving this can be used to answer whether a graph of order n is Hamiltonian by simply asking if the longest forwarding path is of length n-1. Thus, either the complexity is nonpolynomial or the interviewee has just won the million dollar prize for solving an NP-complete problem in polynomial time.
A linear solution for this problem is possible under the assumptions that the graph is directed and acyclic. The directed nature of the graph in this particular example is very clear, and because an individual doesn’t forward a message more than once, there are “basically” no cycles.
Had to Google what a Hamiltonian graph was though. I’ve been listening to the musical too much.
The stated problem does not produce an acyclic graph. For instance, if A has B in their contacts, then B is not forbidden from having A in their contacts. In fact, by ensuring that for all A, if A has B as a contact, then B has A as a contact, we can eliminate directedness from the graph and, via isomorphism, pretend we are operating on an undirected graph.
The requirement that no actor forward a message twice is merely equivalent to finding a simple path through the graph. It does not “basically” mean there are no cycles.
I see what you mean, but it just boils down to how you interpret the problem. Specifically, if you focus on the actual forwarding paths instead of the contact lists, the tree structure that enables the linear solution becomes more clear.
As I’m guessing was intended, this problem is particularly well-suited for engineering interviews because you can start with an easy example (the DAG one could derive in this specific interview) then ask the applicant how the solution would change given the additional constraints you’ve described.
That’s simply not correct. Do an example. What graph do you draw? That’s the underlying graph that has to be acyclic. Where is this supposed tree structure coming from? Try a dense graph, like with n=5, and every actor having at least 3 contacts.
These recordings are really useful. Does anyone know how representative these are from actual interviews? For example, for the interview question on finding pairs in array that sum to k, the case where duplicate numbers in input array sum up to k is missed, and the interviewer didn't bring it up. Also, the space complexity of in-place quick sort is log(n), since the indices need to be kept in each call to sort subpartitions.
The audio quality of these interviews made me grimace. Audio quality aside, this looks like it would be a great resource for anyone trying to go through a "FAANG-style" multi-round interview process.
Small nitpick: in most cases, these companies make a hiring decision with just one round of interviews (if you exclude the technical phone screen, which is a way to reduce wasting everyone's time when it's obvious it's a poor fit).
As both a candidate and as a hiring manager, I much prefer to have a single round of on-site interviews, vs. having the candidate come on site more than once. Good candidates probably have a good job already, and asking them to take multiple half days off to interview is an unnecessary burden.
No dammit, I don't want to get better at technical interviews - I want to live in a world where we don't need them. Why not fix the root problem instead of amplifying it?