The behaviour isn't socially desirable, has potentially serious consequences for disclosure ("The Triplebyte people won't work with us because I told them my interview process begins by throwing out all resumes with funny sounding names."), and assumes that the people involved are aware of their behaviour.
Then they proceed to ask candidates to derive a card shuffling algorithm on a whiteboard in 30 minutes and fail them from the interview if the running time complexity would be too high or if they can’t mathematically prove the result would be a uniform draw from the space of permutations of the cards.
Whatever story they tell you, it’s not about whether they are lying or not, it’s about the extreme myopia in tech where these people actually believe they are sleuthing out the inner talents and dispositions of candidates when they are obviously doing nothing but berating candidates with parochial, uninformative trivia.
I may be wrong, but it sounds like you're using hyperbole in two ways here: (a) you make a statement about all the senior engineers you know, and (b) that statement makes a rather extreme claim about how they evaluate candidates.
I think using hyperbole is a mistake in this conversation because we're interested specifically in how common and how intense these phenomena are.
(I don't mean to single you out. This thought has also occurred to me when reading other online discussions lately.)
I can’t be certain that the same would have applied to all senior engineers in other companies where I previously worked. But I did interact with dozens of other senior engineers over the years and it’s a remarkably constant phenomenon.
It’s not surprising either. We all like to tell ourselves stories about how we embody the best ideals that a broader community espouses, even when the reality of our day to day behavior is different.
That is why I chose the term myopia. I think it’s a symptom of the tech world wishing to be associated with generally progressive human values, but that where the rubber meets the road, the implied values of tech orgs are no better or no more exemplary of positive human values than any other field of business.
> I think it’s a symptom of the tech world wishing to be associated with generally progressive human values
I'm having trouble parsing this part of your statement, but let me say that I think it is more a function of the personality types that get into software development and technology more broadly. Many of us are INTJ types (self included and yes I know that Myers-Briggs is bunk to many of you), and many of us have what was formerly called Aspbergers. In short, there are particular personality types that go into these fields, and those personality types fixate on details. So it isn't surprising that's how many then interview and expect their fellow team members to exhibit similar traits. Without going too far off tangent, I think this is often why this field is seen as combative towards women and non-white people, IE: it has less to do with a deliberate desire to exclude and more to do with the quirks of the people who enter this field.
That sometimes starts with a smaller community that takes such ideals seriously. It almost always ends with a much larger group that spouts those ideals but acts differently.
the implied values of tech orgs are no better or no more exemplary of positive human values than any other field of business
It's long been said that the practice of "Software Engineering" is more a technology heavy application of business and less like engineering.
I'd actually expect a surprisingly large fraction of programmers to be able to do reasonably OK on that particular problem--and I don't mean just those with CS degrees. I'm including the ones that are entirely self taught. In fact, especially those.
That's because so many of us, even those with CS degrees or other common degrees that programmers get instead of CS [1], started out trying to write games or other things that needed to shuffle, were sure that the obvious approach we took was right, and then found out it wasn't and why. It was our first personal encounter with the idea that you can analyze and reason about algorithms and their correctness.
In other words, shuffling was one of the first algorithmic "aha!" moments for many of us, and you don't really forget those.
[1] Mine is math, not CS, for example. Partly that's because when I got my degree, in the early '80s at Caltech, Caltech did not have an undergraduate CS degree. The CS department only offered graduate degrees. They had all the necessary undergraduate coursework available--they just had not yet put together a formal degree program.
Granted, the interview question is pretty bad if it's just a test of if you've seen the problem already.
Here's the algorithm, in pseudo code (yes, with 1-based arrays!):
let a = [1, 2, 3, ...., N] # the items to shuffle
for i = 1 to N
j = random_in(1, N)
swap(a[i], a[j])
That means that there are N^N distinct possible traces. Each of these traces is equally likely. We can associate with each of the traces a shuffle, namely the shuffle that results from the run of the program that produced that trace.
This gives us a list of N^N shuffles. This list will contain duplicates, because there are only N! distinct shuffles, and N! < N^N.
The shuffle is fair if and only if each possible shuffle occurs the same number of times in the list of N^N shuffles. For it to be even possible for that to happen, we must have N! divides N^N.
But if N > 2, that cannot happen. To show this note that if N! divides N^N, then every divisor of N! must divide N^N. Pick a prime P such that (1) p < N and (2) P does not divide N. Then p is a divisor of N! but is not a divisor of N^N, which shows that N! does not divide N^N, and so the shuffle is not fair.
Can we really always pick such a prime? Yes. If N is divisible by every prime p < N, then N-1 must be prime, but then N-1 is a prime < N that does not divide N.
Note that you cannot save this class of algorithm by doing more passes. Those just change the size of the trace from N^N to N^(kN) for some integer N. Nor can you save it by changing it to pick both indices at random for the swap instead of picking only one at random. That just changes N^N to (N^2)^N = N^(2N). As long as the random number generator is always asked for a number in {1, 2, ..., N} and it is called the same number of times every time the program is run, the trace size is going to be a power of N, and cannot be divide evenly by N!
Now we can see why Fisher-Yates might work. It asks for a random number up to N the first iteration, up to N-1 the second iteration, and so on. That means its trace is N! long. There is no problem dividing N! by N!. Since N!/N! = 1, if we can show that each shuffle is included, that will also show that each is included the same number of times, and hence that Fisher-Yates is fair.
All we have to do now to see that Fisher-Yates is fair is show that each shuffle can be produced by it. Given a desired shuffle, it is easy to construct the trace that results in it, and we are done.
All we have to do now to see that Fisher-Yates is fair is show that each shuffle can be produced by it. Given a desired shuffle, it is easy to construct the trace that results in it, and we are done.
You mean: Given a desired shuffle, you show you can construct the only trace that results in it.
We don't actually need a prime. We just need something that divides N! but does not divide N. N-1 will do nicely.
For a company that runs an online game server, let's say, this really isn't that high a bar.
I know off the top of my head that there's some edge case that can keep you from getting an even distribution, but otherwise 1st year probability and 1st year algorithms knowledge should be enough for that. The proof is a slow-ball and the algorithmic complexity is a slow-ball in your example.
it’s about the extreme myopia in tech where these people actually believe they are sleuthing out the inner talents and dispositions of candidates when they are obviously doing nothing but berating candidates with parochial, uninformative trivia.
Or, it could be about weeding out students who got by with nothing more than gluing libraries together and really only thought of degree work as a formality while they were busy networking.
Unless you have a super targeted problem space that interviewing employees know about, then you are doing about as well as drawing a random problem from a hat.
Most developers I know just brush on as many algorithms as they can remember when they are going to interview for a new job. Then they just go through interviews until they find a company that manages to pick an algorithm out of the ones they memorized. This is a giant waste of effort to create a system that is effectively a lottery if you can get past the, admittedly large, bump of being able to understand any comp sci algorithms
A programmer worth his salt should retain enough 1st principles knowledge to not create a O(n^3) bottleneck in production or otherwise stay out of trouble.
Unless you have a super targeted problem space that interviewing employees know about
Often the specific skills are mentioned up front. It doesn't have to be that targeted, either.
Most developers I know just brush on as many algorithms as they can remember when they are going to interview for a new job. Then they just go through interviews until they find a company that manages to pick an algorithm out of the ones they memorized.
This speaks more to bad interviewing. It certainly does not mean that such knowledge being worthless and arbitrary. What you want in a candidate, generally speaking, is someone who can actually apply knowledge. What you are describing above is just regurgitation.
The majority of development work does not have you working through every comp sci algorithm in existence on a frequent enough schedule that the average engineer, or even a great engineer, will remember them all. That is going to garuntees that interviews are a game of chance. The more algorithms and the trick question associated with them that you can memorize the greater your odds, but it's still down to luck of the draw for what questions you are asked.
If you're looking for devs to show that they understand the ideas, you'd be better off telling them the problem space ahead of time so that they can prepare for it, and then deeply questioning their knowledge in that space
It seems to me that a lot of younger folks want to lower the bar below that.
If you're looking for devs to show that they understand the ideas, you'd be better off telling them the problem space ahead of time so that they can prepare for it, and then deeply questioning their knowledge in that space
Perhaps combine that with a related but novel question.
Both of these routes put more risk on employers so they'd rather filter out the majority of people based on an inaccurate test, then throw their hands up and say there are no developers.
The whole country has at will employment and companies certainly aren't voluntarily signing any employment contract. Just fire someone if they turn out to be incompetent/fraud.
When I was a grad student TA, I told people not to cheat. If you don't know enough to answer the questions, you don't have enough knowledge to cheat. That turned out to be quite true.
My office scores the people with the brute force solution higher than the others, so long as they know the time/space complexity.
they practice the soft skills necessary to prevent the interview from ever getting to the point where you're asking questions about where the implementation can go wrong that aren't also on their script
Oh yeah. That sounds familiar. Not getting to the part where they can answer questions about where the implementation can go wrong counts against them.
Most candidates we interview have a combination of CS degrees, statistics degrees or experience, and are prepped ahead of time with some materials about the general type of question we might ask, and around 90% of them are rejected for failing to solve this question. Around 50% are given extremely poor ratings, like not even getting any type of coherent solution, even inefficient and not handling corner cases.
This is what I mean about myopia.
30 minutes is barely enough time for anyone to sketch a solution to any algorithmic problem, even if they are experienced and fully comfortable with the question’s subject matter.
This process just filters out candidates who are perfectly capable of solving the problem as a form of severe risk aversion against possibly hiring someone who lacks sufficient technical skills.
Sure. We used to give an hour, and HR reduced it to 45 minutes. I'd rather have more time. Also, you can dial up the stringency of this particular question to an expert level where hours could be used. Or, as you admit below, it can be dialed down considerably.
Around 50% are given extremely poor ratings, like not even getting any type of coherent solution, even inefficient and not handling corner cases.
You could also dial it back to where you accept a coherent, inefficient solution that at least shows an awareness of corner cases.
This process just filters out candidates who are perfectly capable of solving the problem as a form of severe risk aversion against possibly hiring someone who lacks sufficient technical skills.
So "myopia" in your view is the delusion that such a practice is anything more than that? There are plenty of people in our industry who know that's what it's really for and who know how bad whiteboard interviews are at this task. That doesn't mean the goal is worthless. It seems that many want the goalposts lowered, such that actually understanding anything isn't required anymore.
We know the test is bad and that something better should be developed. What I'm arguing against is lowering the standards and getting rid of the test altogether.
Things are truly understood in solitude not with a gun to your head.
Also, what a developer knows this second has less bearing on what they could learn than often thought. No one knows everything.
You should at least know the basics and be able to apply them. I'm rather shocked by the number of 3.75, 4.0 students from good schools who can spout 1st principles, then utterly fail at applying them.
The stuff you use all the time in your job is largely arbitrary trivia. However, the knowledge referred to in the example given above are first principles. So your standards fall below the level of being able to apply first principles? I can see why people would want to weed people like that out.
Because complexity analysis is a tiny part of a CS degree. A huge wing of our CS grad department focused on type theory and PL in general and could easily screw up a complexity analysis quiz like that because it's irrelevant to their day-to-day research/work.
Yes, but it's a slow-ball pitch! What's the complexity of filling in an array with its indices? If a CS grad can't solve something just a little more complex than that (for a sloppy/easy version of the question, not the shuffling algorithm expert version) then just what the heck are they learning?
If the confluence of 2 or 3 requests you were implementing were to cause a nasty O(n^2) or O(n^3) time or space workload, would you have a good chance of realizing it? If your answer is yes, then you'd have what I'd be looking for. If your answer is that you'd figure it out after the fact, after the problem reports came, by Googling, then you would cause a problem and require an additional spate of diagnosing and patching that a better trained programmer would not have.
I know this wasn't your point, but I would argue that college is a pretty bad investment in terms of a job training program.
For example, a stable team needs both extroverts and introverts, the ratio is not exactly fixed. Yet matching an extrovert to dominantly extroverted team may not be the best choice. How much one can tell at the first impression? Are we back to the era of personality tests at the interview?