I have worked on similar kinds of problems where obscure details about sparse matrix algorithms were required. My team ended up writing a large in-house search engine and ranking framework that combined image and text search, all in Cython, using various types of bit packed indices for fast filtering and our own implementation of a series of sparse matrix algorithms sort of ripping out CSC and CSR internals for a handful of operations related to applying latent semantic indexing and some in house vision model neural networks to the sparse data in a way that was both fast and let us store hundreds of millions of documents in memory on fairly normal hardware.
I would say that tech interviews which assess this type of skill are deeply irrelevant and fail even at the very task they attempt to solve. Not to mention how arrogant it is to reduce emphasis that should be placed on straightforward communication about real work experiences as a more important measure than performance on any type of interview coding tasks.
What you say just falls flat. You don’t give any reason to think that this stuff needs to be an interview-ready skill to be tested in a time-sensitive way. It could just be picked up later when you have a project where you need it. Most engineers can quickly grok this stuff from a book or online tutorials or talking to someone else or even just writing the problem down and locking themselves in a room for a few hours to think.
Any assumption that it needs to be already in your brain cache all the time prior to an interview or every day at a job is just harmful.
At worst it’s a thin excuse for promoting a hazing style of oneupmanship as a barrier to jobs, killing diversity of thought and at best it’s misguided reward for a certain type of extreme premature optimization thinking (that carries a lot of antagonistic culture with it too).
I don’t think it’s hazing, Google internal culture frowns on that kind of alpha male coder oneupsmanship.
its mostly likely a residual of the fact that people fresh out of school actually don’t have a lot of projects or experience to talk about.
If you ask me what the perfect interview is? I’d say, send me a bunch of github repos you participate in and let me review your code, bugs, and discussions with collaborators.
I’ll learn a lot more than any 1 hr FtF interview.
My overall point is there’s this kind of attitude “calculus? I never need it.” Prevalent in society where people rail against subjects they were forced to learn and then claim their day job never needs them.
I think whether or not you actually use anything you learned in CS courses highly depends on what you want to work on. My interests happen to be in compilers, computer graphics, and cryptography and I find I need to quite often revisit stuff I learned in college.
Even when I was writing 8-bit games and demos on the Commodore 64 I found some need sometimes for these skills like replacing expensive functions with approximations.
I’m not saying interviews need to question you on these things, I’m saying these things are useful to study and learn and stay abreast of. Perhaps I’m biased because I kind of love math and find an inherent beauty in these things and so I find these kinds of puzzles fascinating. (The Shannon Fano plane is a particular example of a beautiful construct that I just adore for reasons I can’t explain)
I can’t speak to Google in terms of the alpha mentality, but it’s still irresponsible of the world’s most effective computer science company to support it, advertise it with study guides, etc. I expect more self-awareness than that, and less lazy thinking that you need such time constrained trivia to keep an artificial prestige barrier (because it very sincerely is not about detecting engineer effectiveness). Take some responsibility for the cargo cult copycats you are fueling. The same could be said about stack ranking and various other policies as well.
Regarding interviews, everybody’s a comedian. You say GitHub but some of the best engineers I know do not participate in open source projects or are prevented from doing so by their employers. I say just treat software engineering like every other professional field on the planet and just conversationally interview people in a technically detailed way, focus on their past projects, work history, ability to get specific about their work. And of course that would not be as good for people just out of school or who forgot ancient work project details.
I would be fine with a holistic average approach, where each of these different ways is applied, but each counts for little weight individually. So you can be forgiven for a code test flub if you’re sharp on your work experience technical details.
But we exist in a state far away from that... where things are overwhelmingly based on isolated, time-sensitive trivia given 100% of the decision weight.
Calculus probably isn't the best example, because you really don't need it. Real engineers need it, but if software engineers got a different sequence in discrete math I think they'd be better prepared for the job market. I ended up doing a math concentration so I got both Calc 1-3 and some nice discrete courses like number theory, combinatorics, and abstract algebra that were super useful, and in my opinion we could definitely stand to replace memorizing integration techniques with studying some of those topics.
This really is not true. Using a little calculus to derive a closed form solution to a problem can reduce computational burden. A team where I work just had to do exactly this for a geographic distance optimization problem. At first glance it seemed like you needed dynamic programming and it was expensive, but drawing it out and modeking it with equations, we actually set up a Lagrange multiplier formula for the problem and found it had an exact solution. This was not a team of mathematicians or anything, just database engineers working on a specialized in-house search optimization problem.
If you do work in statistics, then calculus matters quite a bit, especially for transformations of variables and deriving the formulas for the probability distributions you’re working with. In Bayesian methods, even if you use autodifferentiation tools to automatically sample from your model, you still often need to do a bit of calculus here or there.
Likewise, if you ever find that you need to implement your own model training algorithms, you’ll probably need to calculate gradients (for example, the gradient of custom log-likelihood functions) analytically before writing them as software functions.
Calculus is pretty pervasive in professional software engineering. You don’t need to be an expert, but should have working knowledge and ability to dig into references and work through it.
Yeah the statistics and machine learning applications are a bit hard to get away from. But I would still replace the calculus sequence with discrete math, assuming the number of math credits had to stay the same. At my school (University of Maryland, College Park) most CS majors just took calculus 1-3, statistics, and one basic discrete math course from the computer science department. The size of calculus seems massive (3/5 of the total math load) compared to the benefit. That precious time could be spent digging deep into linear algebra or combinatorics or graph theory etc, and that's useful for all developers who write algorithms, not just in specific applications' niches.
Why do you think they are mutually exclusive? Generating functions, geometric series, difference equations, integrals over discrete probability distributions, elliptic curve cryptography, general linear programming and optimization, eigenvalue analysis in graph theory, stochastic optimization, all these things involve calculus to solve discrete algorithmic questions.
In fact I’d argue it makes calculus more important than what is typically understood as “discrete math” because in order to have the mathematical maturity to really understand the meaning of major discrete math results and theorems, it requires understanding calculus first.
If you “just” study discrete math mistakenly believing “that’s where the value is” then you’d end up with a shallow understanding of discrete math, lacking ability to extract value from it except in some narrow sense from rote discrete math application-specific coursework.
> … applying semantic indexing … to the sparse data in a way that was both fast and let us store hundreds of millions of documents in memory on fairly normal hardware.
Fascinating. Would you mind sharing more, some links / white papers?
We did something similar with ScaleText.ai (as a step-up from Gensim), I'd be curious to compare notes and perf numbers. Drop me an email at radim@rare-technologies.com if interested. Thanks!
I would say that tech interviews which assess this type of skill are deeply irrelevant and fail even at the very task they attempt to solve. Not to mention how arrogant it is to reduce emphasis that should be placed on straightforward communication about real work experiences as a more important measure than performance on any type of interview coding tasks.
What you say just falls flat. You don’t give any reason to think that this stuff needs to be an interview-ready skill to be tested in a time-sensitive way. It could just be picked up later when you have a project where you need it. Most engineers can quickly grok this stuff from a book or online tutorials or talking to someone else or even just writing the problem down and locking themselves in a room for a few hours to think.
Any assumption that it needs to be already in your brain cache all the time prior to an interview or every day at a job is just harmful.
At worst it’s a thin excuse for promoting a hazing style of oneupmanship as a barrier to jobs, killing diversity of thought and at best it’s misguided reward for a certain type of extreme premature optimization thinking (that carries a lot of antagonistic culture with it too).