8 ms·
Here's my gripe with this interview process. It encourages engineers to spend months and years into learning and remembering optimal solutions to textbook probl
by NTDF9 10y ago
Here's my gripe with this interview process. It encourages engineers to spend months and years into learning and remembering optimal solutions to textbook problems.
A REAL engineer would spend the same time doing something productive....things like:
- Writing a sql optimization for their current company that saves resources
- Creating shared memory interfaces for faster processing of logs
- Modifying filesystems or kernel to create their own log processing
- Modifying JVM to optimize critical code
- Rewriting parts of a server to set up security alerts
- Fast encryption and decryption of in-memory cache records
- Writing an interpreter for faster generation of low level code for high speed processing
- And on and on
My point is, today's interview process treats engineers with such complicated experience as shit because they spent time working on complex projects and couldn't memorize these questions. But then these same companies will hire some mediocre engineer who cannot think out of the box but is an expert at memorization.
Said mediocre engineers then hire other mediocre engineers using the same process, because these mediocre engineers do not even have the ability to grasp what kind of engineering would lead to above points.
To top it off, these same mediocre engineers sweep this problem under the rug claiming they are trying to reduce false negatives. Lol!
Sad state of the industry!
- qaq 10y agoIf this materially impacts the bottom lines of companies that are practicing this approach eventually companies that are not using this process will prevail.
- inopinatus 10y agoThere are other equilibria, likely because the employment market does not have the characteristics necessary for analogies of the the Efficient Market Hypothesis to apply. (most glaringly: people are not fungible commodities / the agents involved do not have rational expectations)
- NTDF9 10y ago>> If this materially impacts the bottom lines of companies that are practicing this approach eventually companies that are not using this process will prevail. It would, if companies realize that they can save millions by improving their interview processes and not have to aqui-hire so much. But this insight requires smart people (who they eliminated with this interview process) to be already hired in those companies.
- qaq 10y agoWhile I highly dislike this trend it's hard for me to call say Sundar Pichai not smart for example.
- NTDF9 10y agoWhat do you think about Marissa Mayer? For every outlier winner person you point out, the industry is littered with losers. Perhaps stop correlating wrong things together?
- dsacco 10y agoThere are several problems with your and the parent commenter's approach here: 1) You've not defined intelligence in an agreeable way, such that all parties are discussing the same thing (you seem to have interpreted his point about Sundar Pachai as successful due to being CEO of Google, but that may not be the case). 2) You've not defined intelligence in a rigorous way, such that all parties know it's meaningful even if they agree on it (is being CEO of a publicly traded company a robust proxy for intelligence? Can we positively correlate corporate success with intellectual formidability?) 3) You have not established any empirical way to assess intelligence in these people aside from what you'd consider tautological (CEOs are intelligent, Pachai is a CEO, Pachai is intelligent) and therefore self-evident. But you can't discriminate between the relative intelligences of members in this group, especially remotely on a forum, which makes this an issue even if 1) and 2) are solved. I know, taking dialectics this seriously on an internet messageboard is a major pain in the ass. But this brings us full circle to software engineering interviews. One person mentioned a potential proxy for intelligence they consider self-evident, someone else argued against it without full and transparent clarification, and the cycle continues. This is how whiteboard interviews were born, this is how they became controversial, and this cycle continues even on discussions of whiteboard interviews. People who want to filter for "intelligent" in their interviewing process can't define the term. People who come up with methodologies for assessing it, or identify proxies to it, can't prove they work. People who argue against these assessments or proxies can't prove they don't work because no one can even agree on what should be assessed. It's a Wittgensteinian clusterfuck all the way down, but the same human habits that gave rise to whiteboard interviews are perfectly manifested in the counterculture reaction to them and the resulting controversy. I propose instead that you resist the temptation to use the word "smart", even in situations you'd consider the quality self-evident. "Intelligence" is like AI - once it's rigorously defined, no one agrees it's AI and it's so narrow in scope that no one cares about it because it's not weaselly and magical anymore (example - the IQ test). When you appease everyone's inclinations and talk about it without defining it, madness ensues. Rigorously define a problem space, correctly map a set of empirically measurable capabilities to it, and hire people who demonstrate those capabilities. But don't use descriptions like "smart" which mean everything to everyone.
- BurningFrog 10y agoCompanies that hire the best engineers already use better processes.
- qaq 10y agoHow can we check this to be true?
- BurningFrog 10y agoYou probably have to become a real good engineer, or work among them, to see it.
- qaq 10y agoHow does this prove or disprove anything about the process they use?
- pkaye 10y agoSo what approach do you suggest for the interview process? How has it been your experience hiring under this process?
- eli_gottlieb 10y agoWithout spoilers, here's an outline of an interview problem I did last Friday: 1) Here is a very small VM (fewer registers and fewer instructions than you can count on your hands). Write an interpreter for it. 2) Add an I/O instruction. 3) Having your interpreter and your I/O instruction, you are given at least one example of a program with a specific property. Write a program analysis which will detect the property soundly and completely. Managing to finish (3) relies on knowing about certain fundamental concepts from automaton theory and program analysis. The company does actually use this knowledge regularly, so it makes sense that they'll ask. However, even parts (1) and (2) actually manage to test basic programming in a reasonable way.
- NTDF9 10y agoWhat do you work on? Can I interview with you?
- eli_gottlieb 10y agoI was the one interviewing for a job! If I get it, then maybe I can invite you. For now, precious is mine!
- NTDF9 10y agoHaha! Good luck. Sounds like an awesome opportunity if they deal with VMs and registers!
- twic 10y agoRegisters? You were lucky! Last time i did an interview problem with a weird machine, i didn't have any registers at all! And only three instructions, none of which were arithmetic!
- SamReidHughes 10y ago> Here's my gripe with this interview process. It encourages engineers to spend months and years into learning and remembering optimal solutions to textbook problems. Wrong. Questions aren't designed to be memorized. It shouldn't take months, or years, to prepare for this stuff if you already have a CS background unless you're really slow.
- NTDF9 10y agoWho do you want to work with? A person who can regurgitate CS trivia or a person who has interest and track record in solving interesting problems?
- SamReidHughes 10y agoLike I said, it's not regurgitation. There's a reason companies try to keep their questions secret.
- NTDF9 10y agoIt's all a variation of the 500 questions listed. Nobody memorizes code line by line. But there are enough hires at Google and FB who memorized algorithms and solutions and got in. Do you want to work with people who memorize solutions or do you want people who are innovative, genuine problem solvers who've solved interesting problems?
- SamReidHughes 10y agoIt's hard to imagine an innovative problem solver being unable to tackle Google's interview questions. You gave the example of optimizing an SQL query. That's a data structures problem itself. Google apparently has an NDA for the interview questions they ask, so they're trying to avoid quizzing people on stuff that they've memorized. I know any place I worked at always tried to ask "fresh" questions to people. There's just no point if they already know the answer.
- 10y ago
- JDiculous 10y agoGoogle style interviews don't screen for the best engineers, but they screen strongly for subservience. The fact that a candidate has to go out of their way to prepare for these interviews indicates that the candidate is likely willing to jump through whatever hoops they're told to jump through. It's similar to how investment banking jobs place such a high premium on Ivy league degrees with high GPAs despite the actual job itself being so simple a high school student could do it. Someone who's willing to jump through all those hoops to get into a top school and graduate with a high GPA has a strong track record of following orders and is less likely to complain about 100 hours workweeks.
- NTDF9 10y ago>> Google style interviews don't screen for the best engineers, but they screen strongly for subservience. The fact that a candidate has to go out of their way to prepare for these interviews indicates that the candidate is likely willing to jump through whatever hoops they're told to jump through. Try saying this obvious observation to some Google engineers in real life. I've never seen such butthurt adult-kids!
- eli_gottlieb 10y agoI mean, that's all true, but what matters is whether you have some personal goal which requires you to go through time at Google.