11 ms·

My career path in tech so far has been junior engineer -> mid level -> senior -> tech lead. As I've progressed through that path, I have had literally no oppor

• giantg2 5y ago
  I went to an internal job interview about 5 years into working for the company. They were asking me all sorts of textbook questions about defining stuff like polymorphism and explaining some sort algorithms. I bombed. Many of these terms and algorithms had never been used during my 5 years, and I forgot many since they hadn't been used since college. I wanted to ask the interviewer if they actually use these terms in meetings or used the algorithms, but I didn't. Since it was internal, I already knew the answers would be that they didn't, and I didn't want to appear confrontational. I was internal, a high performer on my team at the time, and you're going to ask me this useless stuff?
  • sharpy 5y ago
    Haha. At some companies, they made the interviews tougher for internal candidates... Amazon used to require full loop, but last time I changed jobs there (I no longer wok there), all it took was conversations with some senior engineers, and somebody reviewing my work sample. And totally agree with the absurdity of the questions we ask in tech interviews. At least for my current employer, we use simplified versions of real problems we faced in the past, and place more emphasis on how they communicate, rather than just throwing some leetcode medium/hard problems, and let candidates self select based on how much prep work they put in.
    • giantg2 5y ago
      Well, there's really two ways it works at my company. The other way it works is managers making backroom deals and then it's just some conversation with the tech lead that counts as the interview for HR's sake. So sort of similar to what you described.
• ramraj07 5y ago
  What’s your suggested alternative? Please remember that while some of us would do well and prefer some live pair programming or debugging sessions, it stresses the hell out of some folks and penalizes them unfairly. Take home tests penalizes people with families and other responsibilities and probably has a racial bias as well in countries where different races have different societal loads. In the end, even if these coding challenges might not reflect the actual work you do, they might still be predictive of success in the job, as much as any other method can be when we look for unbiased markers. This is similar to how the entrance exams to the IITs in india are pretty much completely discordant to what you actually end up having to know, the rigor and preparation you need to do ends up reasonably selecting for well performing students anyway. Not perfect though. Any system can be gamed but it works alright.
  • rmbyrro 5y ago
    > they might still be predictive of success in the job Basing an assumption out of thin air like this, we can throw the opposite argument: 'they might be predictive of failure in the job'. Writers of bad code and choices mentioned by OP were likely hired out of a fantastic hacker rank score, and yet failed to produce good output.
  • synthos 5y ago
    grinding leetcode is just as bad, if not worse, than a take-home test
    • majormajor 5y ago
      Perhaps not everyone has to grind it so much. (I would wager they're the same people who do regularly find themselves thinking about computational and space complexity, and about using different datastructures and algorithms for problems, vs the ones who never see reason to!) A take home test requires spending free time for everyone. A whiteboard interview requires variable amounts of free time. I would wager that, on average, the people inside companies using these processes require less time to "grind leetcode" than the people outside those companies do. You gotta be able to convince the folks on the inside, not the ones on the outside. To them, it being hard to "grind" might even seem like a good thing! "It's hard to cram for this compared to other sorts of tests!"
• samstave 5y ago
  The next big tech interview craze, I have long thought: Here is a fucked up environment. Here are logins for each role. Here is your team. Here is your role. Each of you has a chance at each role. There are three of you. So three challenges. The environment is experiencing the following symptoms. Diagnose, report, fix. --- Then throw them at some broken stack with admin rights and figure why its broken and fix it. Create various stack models to throw at teams based on team skill-set. Never hire individuals. Hire strong individuals who can work in a team.
  • xerox13ster 5y ago
    I'd kill for something like that. Don't have me create and solve some arbitrary math problem in code syntax, this isn't quiz bowl and work isn't a scholastic decathlon. This is tech, give me broken technology tell me its expected behaviors, give me space to figure out what makes it tick and and I will fix it.
  • jfrbfbreudh 5y ago
    I was recently given something like this as a phone screen. I was provided an ip address and some credentials and I was expected to ssh in and get some python scripts working. I was only given this after passing a difficult HackerRank though.
• adam_arthur 5y ago
  The whole psychology around tech interviews tends not to be focused on the right things. At least in the general sense, a lot of it appears to be people copying others without understanding the motivations. The theory of interviewing should be to ask questions that are as predictive as possible e.g. success on the interview correlates as closely as possible with success on the job. The strengths needed will vary greatly by the role, company, and so on. But what you tend to see is, everybody has a handful of "pet" questions that they ask over and over, without applying strict rationale for why its predictive to success. Personally, any good interview question must both be iterative and highly correlated with actual work. Questions that have one "trick" and judging on that basis is a poor interview. Questions that focus on data structures or algorithms that aren't going to be relatively common are also poor. Questions which lack real world applications, also poor. At least for me, I have a handful of questions, but one of my basic ones is to implement a certain data structure. And honestly, I care more about seeing the naive solution than the highly optimized one... because I care first and foremost that the candidate can code proficiently. The naive solution is super easy and requires little theoretical strength... but it becomes very obvious how proficient of a coder they are by seeing them write out the solution. How quickly can they write it? Do they make syntax errors? How long to grasp the intention of the question? Some write the solution in 5 minutes, some take 40 minutes. That gap alone is probably the most strong predictor. There is a more theoretically optimal solution, but I just followup at the end and we'll talk through what it could be. But if somebody can hammer out a naive solution with good code quality, quickly I weight that about 90%. But my company also needs strong coders over particularly theoretical people. One of my best coworkers bombed on a tree interview questions I asked... but I could tell from all the supplemental details that he was very strong.
• WalterBright 5y ago
  > I have had literally no opportunities of applying the stuff I've learnt on HackerRank I have. Many times.
  • mkl95 5y ago
    If you are THE Walter Bright, I have no doubt you have. Respect
    • WalterBright 5y ago
      There can be only one.
  • game_the0ry 5y ago
    Yes, the opportunities are possible, but exceptional. For the most part, you will be wiring crud APIs or trying to figure out why your button is misaligned by 12 pixels. Those problems also pay better too, bc those are business problems. The hackerrank problems have mostly been solved. Think about that - you think Ed Dijkstra or Tony Hoare ever made more than a facebook swe?
    • Kranar 5y ago
      Tony Hoare works at Microsoft as a Principal Researcher, as well as having won over 5 million dollars just in awards. I'm quite sure he makes more than a Facebook SWE. Dijkstra won a similar amount of money in prizes and worked at UT Austin which according to their 1985 docket paid 110k a year ($287,418.96 adjusted for inflation) and also worked in private industry in a research role, so once again... likely made more than a FB SWE.
      • game_the0ry 5y ago
        Alrigt, alright, I stand corrected. Here's your upvote.
        • mhh__ 5y ago
• game_the0ry 5y ago
  Bingo. It should be telling that there are a number of, usually for-profit, resources for prepping for just the interview process: * leetcode * Cracking the Coding Interview * Elements of Programing Interviews * Interview Kickstart, which costs like $5500, is a bootcamp just for passing interviews * educative.io * algoexpert.io That being said, I might just play along with the DS / Algo interview game. Having an interview process that is artificially arduous and way outside the expectations of the job duties means that the job market will stay artificially inflated on the demand side. Hiring leetcode monkeys who can barely deploy and manage k8s cluster on AWS means the demand for my skills will be more valuable than if the interview process actually worked. I can complain all day to my bosses about how hard it is to hire (its not that hard) and meanwhile rip their HR budget to shreds when I threaten to leave unless I get paid more (I've done that before, I recently got a promotion and 50% raise on base alone). So yeah, I'll gatekeep as long as others play too. I hate the game, but I will play it to my advantage.
  • mkl95 5y ago
    > I can complain all day to my bosses about how hard it is to hire (its not that hard) and meanwhile rip their HR budget to shreds when I threaten to leave unless I get paid more (I've done that before, I recently got a promotion and 50% raise on base alone). Kudos for that. I may be making a similar move soon.
  • majormajor 5y ago
    What is that supposed to be telling? There are a quite a few industries where there are profitable neighbor industries around breaking in to it. Even ones with licensing and blah blah blah instead of whiteboards. Hell, the cynics would call the entire current university system one! And if not that, than it least the massive industries around getting into better schools...
    • Apocryphon 5y ago
      Why don’t other STEM fields have those neighbor/parasite industries?
• dionidium 5y ago
  The reason this complaint never changes anything, despite being very popular, is that these interviews serve two purposes that it doesn’t address: 1) they’re an intelligence test; 2) they’re a perseverance/conscientiousness test. Will you take the time and put in the work to pass one of these interviews? That measures perseverance and conscientiousness. Having put in the time, can you recall and adapt what you learned to perform complex tasks on a whiteboard in a stressful environment? That’s an intelligence test. In combination, these criteria measure the famed, “smart and gets thing done” in a way that more practical lines of questioning might not. Or at least that’s the theory. For the record, I’ve only interviewed at one FAANG company, got to the on-site interviews, did not get an offer (in case you think I’m secretly patting myself on the back here).
  • syspec 5y ago
    I really think you nailed it, will have to borrow this point in the future. A lot of it is about gauging the candidates aptitude, and of course their willingness to put in the work. It's like those kids in math class that say, "I'm never going to use this in real life."
    • analog31 5y ago
      Those kids are right. School math is mainly an attrition machine. Most students, including in STEM fields, look forward to forgetting all of their school math on graduation day. The math that engineers need is baked into their high level software. Most engineering teams have a "math person" who handles any higher math related problems that crop up. I'm one of those people at my workplace. I was a college math major, but believe that the math curriculum is ripe for reform.
      • eftychis 5y ago
        This is a chicken and egg problem that I believe exists in Computer Engineering/developer positions because of i) the extremely diverse background of hires (some of them not being engineers or mathematicians or physicists per se i.e. could be coming in with a bio background (ML usually), no degree at all (perhaps a bootcamp -- usually front end work), or other) ii) a lot of businesses do low hanging fruit work with little novelty, iii) a lot of cost can be thrown to "buy more hardware/server time," iv) low quality is not just advised but sought for. Because of the usual lack of rigorousness -- e.g. most companies will not require you to prove that the system is going to be up for 99.9999% of the time, the load balancing is optimal, the abstract queue in our system is not going to diverge (when it does inevitably we will just reboot and keep doing it until we get more funding) -- the expectation and targets is also to avoid it. Most developer positions are doing essentially the equivalent of designing over and over the equivalent in civil engineering terms of one or two story buildings. There are positions that will exercise one's engineering skills (including math). However, the culture and expectation of "math person" does not promote them. Graphics, cryptography, distributed/byzantine systems (I don't mean using AWS here), optimization, ML (new algorithms/improvements), maps, are some areas that one's cs/math/engineering skills can be used at. But note that when any X of those areas become trendy there is the gut reaction of an "intro to X for programmers" coming out that is a couple of hand-wavy sketches, some sketchy intuition -- most often wrong in the details -- and an API guide. Having done my undergraduate in Europe, every year was math heavy -- math was the core not the attrition machine. And I do see this mentality in the U.S. startup industry where a lot of times the Edison approach is taken of trying every single filament width choice on a mock-up instead of doing a quick calculation. Having taught math to undegrads in the U.S. and from discussions with people that TA'd, I would agree with you that the math curriculum needs to be revised from the ground up as being extremely inadequate. On the other hand, most software "engineer" positions, do not require any engineering to be done.
• monkeybutton 5y ago
  At least have empathy for your predecessors! How often have you chosen an architecture and stack to solve a problem only have the slow but constant shifting sands of managements' requirements completely undermine the foundation of what you've built, and been given no extra time to migrate and make it right instead of adding on another layer of shortsighted hacks?
• dmkirwan 5y ago
  I totally agree with you. Some of the content there seems relevant to CS in general, but I hate the fact that you need to study content that you won't use on the job in order to pass an interview. It doesn't make sense to me. I've seen new grads perform as well as senior engineers with these Leetcode-style questions so I've stopped using them to assess engineers. Further, I know we're specifically trying to assess technical ability in an interview, but that's not the whole picture for an engineer. They need to be able to take feedback well and provide good mentorship also. I think we miss this. Inspired by some realistic interviews that I did recently, I've been working on something[1] that aims to equip companies to hire engineers using realistic assessment methods. It scales like Hackerrank, but I think it's fairer. [1] https://devscreen.io/ https://devscreen.io/
  • Ancalagon 5y ago
    do you have a demo video or something for this?
    • dmkirwan 5y ago
      Not yet - I'm going to add one to the homepage this week and also support a free trial.
  • whimsicalism 5y ago
    > I've seen new grads perform as well as senior engineers with these Leetcode-style questions so I've stopped using them to assess engineers To me, this seems to be reasoning from an unproven premise. As tech becomes ever more lucrative, it honestly wouldn't surprise me that the average competence of new grad hires will skyrocket - supply of software engineers is going to increase and each subsequent generation will have more experience with technology.
  • lmm 5y ago
    > I've seen new grads perform as well as senior engineers with these Leetcode-style questions so I've stopped using them to assess engineers. Good point, it could start a real crisis if the industry collectively admitted that senior engineers are no better than new grads.
• joe_the_user 5y ago
  I'd be OK with modern interviews if they reflected the job you will be doing to a reasonable degree. But knowing the state of the industry I feel that they fall somewhere between gatekeeping and a bait & switch scheme. Yep, Back in the 90s and early 2000s, the interview problems I got were often the actual problem I was meant to solve on the job. Which is to say that I don't think there's any barrier to coming up with questions like. Of course, if the job is as you describe, putting people through hoops is indeed a way to avoid actually telling people what they'll do.
  • rtlfe 5y ago
    > Back in the 90s and early 2000s, the interview problems I got were often the actual problem I was meant to solve on the job. Really? In the early 2000s, half the questions I got for dev jobs were completely irrelevant riddles and nonsense like "which US state would you remove?"
• yibg 5y ago
  Seems like the consensus is that engineering interview is broken, but no one has come up with a better method? You’d think with the war to get talent these days if there was a better way to screen for candidates companies would use it.
  • whimsicalism 5y ago
    > Seems like the consensus is that engineering interview is broken, but no one has come up with a better method? These sort of "consensus"-es appear for most sorts of screening processes where the majority of people are screened out. See: any form of standardized testing.
  • DrBenCarson 5y ago
    Self-plug but I think I have an answer https://haig.io/post/most-underrated-software-skillset/ https://haig.io/post/most-underrated-software-skillset/
• lhorie 5y ago
  I interview senior SWEs at a big tech company (I've done in the order of a few hundred interviews, which were a mix of coding and system design sessions). I'm always open to hearing about ideas to improve my interviewing, but I find that threads like this are repetitive and not really actionable. One common misconception I keep seeing is the idea that the interview result revolves around solving the question. IMHO, that's a bad approach (which is unfortunately taken by many interviewers) and in fact it's an incomplete way of assessing candidates, given that most big tech companies have a list of competencies and/or values that are supposed to be evaluated. Big tech companies usually want interviewers to assess on multiple dimensions, ranging from communication quality to specialization fit. As an interviewer, you're supposed to think of the question as a vehicle to go over these topics, not a pass/fail end goal in and of itself. In my interviews, I pace my hints with the goal of having the candidate complete the question, even if it means dictating answers to unblock them. There's nothing worse that sitting there wasting time feeling smug when the candidate gets stuck on something. Time is short, so it's much better to move on quickly to different topics than linger on something unproductive. If you're on the interviewer side, my number one advice would be this: question the calibration of the question bank. It's usually a kitchen sink of everything the person writing it could think of, without regards for time. You might already feel that you don't have time to cover everything that the question is supposed to cover, let alone all the non technical criteria that leadership asks for. So instead, cover a few actual technical concepts (syntax, recursion, what have you) to rule out complete incompetence, and then take liberties to go into topics that do cover a wider variety of aspects. For example, discussions about testing, refactoring or debugging can all be productive ways to spend time in a coding interview. </two-cents>
  • urthor 5y ago
    "One common misconception I keep seeing is the idea that the interview result revolves around solving the question." Candidates know this. The issue is: Interviewers who do their job, and build a broad based picture of a developer's skills and give fair ratings, are rare. The perception is 75% interviewers don't even bother. They're tired, they're unmotivated. Their annual bonus doesn't reflect "conducts fair and balanced job interviews." They underclock their brain to 10% of its maximum, and at the end of the hour look at how shiny and perfect the piece of code at the end is. Despite whatever the intentions of the system, I don't think anyone has ever hired a candidate with a messy code who spoke and reasoned well. My extremely strong perception, having never conducted a big tech company interview, is that a candidate who submitted a shiny piece of clean code at the end of a technical interview will always be first pick. No matter how much they mumbled. A picture is worth a thousand words. A shiny perfect coding solution is a perfect image in the mind of the interviewer. Interviewers are human, fallible people. When they're doing the end of day calibration on interview performance, having a shiny perfect solution changes their perception of a candidate utterly.
• urthor 5y ago
  Oh the focus of the interview is very good. It's Google's interview format after all (actually Microsoft's, but operating systems are hard as well). The great big sleight of hand trick behind all of this is that the entire industry has copied the interview process of a single, extremely large, company. And Google makes $$$ writing software for *extremely complex graphing and search algorithms*. It's a great interview process. For Google. For everyone else, it's holding up a great big sign that says "I'm a moron and I copied my homework assignment from Wikipedia."
• machinelearning 5y ago
  Having had quite a bit of experience on both sides of the equation, you’re absolutely right. The very act of extrapolating how a person would perform based on a brief snapshot in time seems flawed. It is unreasonable to task the interviewer with making a good decision with barely any data. I used to think that a well calibrated question bank or interview style could be a reliable signal. But the moment you ask something specific is the moment you don’t ask everything else. A poor performing but good candidate’s strengths could lie in the latter category and a well performing but bad candidate’s strengths could be in the former. There needs to be a reliable and credible way to learn about a persons strengths and weaknesses based on their track record. I’d weight credible reference checks, previous projects and credentials more than their actual interview performance.