9 ms·

Tech Interviews Are Stupid

• westoque 5y ago
  The tech interview process is different for every company but it's definitely not broken. As a CTO, one of the things I look for is experience. You can look up all the "basic shit" you want but if we're talking about a specific problem, I want you to be able to give/walk me through a solution even if we don't finish the problem. If I'm interviewing a senior engineer, I want you to be able to show your seniority one way or another, if we talk about architecting something, I want you to be able to talk about why we want to solve it this way, pros-cons etc. Experience also shows me that it wouldn't take you a long time to solve the problem, and in our industry, at least my experience in startups, speed is key.
  • forbiddenvoid 5y ago
    I'm curious about the reasoning behind these statements. For example: > if we're talking about a specific problem, I want you to be able to give/walk me through a solution even if we don't finish the problem" Why does this matter? Why do you want this? How do you correlate what you're stating you want here with actual job performance?
    • westoque 5y ago
      > Why does this matter? Why do you want this? How do you correlate what you're stating you want here with actual job performance? It matters to me because we want to be able to show that we can think through solutions. If we're building a feature that has something to do with streaming video, it would be a plus if you've shown that you have experience building streaming services or at least some knowledge along the topic. This should correlate with job performance because of the experience and working on this topic is already known. Now, there would be a case where we have 0 experience with this problem space but again it comes down to thinking through solutions and thinking about race conditions, side-effects etc and being able to identify these.
  • nowherebeen 5y ago
    > most tech role interviews involve some sort of coding challenge He is talking about coding challenges specifically.
  • choppaface 5y ago
    In the macro, there is a ton of demand for engineers yet short supply (particularly for universities). Thus the very high false negative rate observed at nearly every company indicates the interview system is broken. What would help is more disclosure from hiring managers and interviewers about what they want and the success rates of candidates. That information is still largely today only available to hiring managers and executives. We need less information arbitrage for a more efficient hiring system.
    • duped 5y ago
      More information just makes it more difficult to filter out the scripters trying to automate their job applications. That's the biggest issue I have seen, personally. There's too much noise on the channel, and giving any advantage to the CV spammers is not going to make it less noisy.
    • dahart 5y ago
      > Thus the very high false negative rate observed at nearly every company indicates the interview system is broken. What high false negative rate? Can you point to some data? By "false negative", are you referring to rejecting a good candidate? Are false negatives (rejecting a good candidate) more important than false positives (hiring a bad candidate)? > We need less information arbitrage for a more efficient hiring system. How do you define efficient? Whose efficiency are you considering, the company or the candidate? Why should efficiency be a primary goal of the hiring system, as opposed to simply finding the best candidates in a reasonable time frame?
    • throwaway744678 5y ago
      The cost of a false negative to the employer is quite low (missing on a good candidate) compared to the cost of a false positive (hiring a bad one).
    • quickthrower2 5y ago
      Engineers are of course not a uniform thing and every role is looking for different experiences and traits, so you’ll get a lot of good engineers knocked back from interviews who go on to get a job somewhere else. This might be trite but thought it is worth mentioning as what seems “unfair” can often just be this.
  • tchalla 5y ago
    > Experience also shows me that it wouldn't take you a long time to solve the problem, and in our industry, at least my experience in startups, speed is key. If you feel that way, here's a viewpoint from Derek Sivers which talks about "Idea being a multiple of execution" [0]. If you genuinely believe that "solving a problem within a few minutes" can be reached, I'm going to ask you - What problems are you asking people to solve in a limited time frame? [0] https://sive.rs/multiply https://sive.rs/multiply
  • beebmam 5y ago
    In my experience, speed is the opposite of key for longer term success. Speed is how my companies have ended up with designs and implementations that weren't maintainable and/or had big gaps in them. I'm sure the usefulness of speed varies by context
• gizeta 5y ago
  I worked in a company which was hiring tech folks without coding interviews. I am glad I left.
  • rimliu 5y ago
    I also worked at two companies like this. Both rank as #1 and #2 best places to work. A bunch of very competent people.
  • wdb 5y ago
    The company didn't use the three or six month probation period?
    • obviouspenguin 5y ago
      In my experience, getting a bad hire is worse than not hiring at all. It takes a huge amount of resources to properly onboard a new team member, and then if they are not performing well the work they were doing ends up becoming a liability instead of an asset to the team.
      • wdb 5y ago
        Yes, sure but if it's a bad hire. You would dismiss within the probation period, right?
  • handrous 5y ago
    I think part of the problem is that places with coding interviews usually pay better than those without, and the ones with the really painful, idiotic, grueling interviews that everyone hates offer the top pay, so the system ends up sorting all the worst candidates to the companies that don't do "normal" coding interviews. In fact, I think that effect is exactly why the top-paying places do it, because it makes their hiring easier. At this point, if any of them unilaterally drops the hellish, silly, hazing-interview process, they'll be inundated with good candidates they've been excluding plus a shitload of bad ones who'd already been filtered out by the fact that their process is hellish and silly. So none of them will.
• kristiandupont 5y ago
  I find that pair programming with the candidate on their laptop, using their preferred tools works well. It takes time and in many ways it requires more energy from me than if I were to just sit and observe. However, it gives a better feel for how the person goes about solving problems from the abstract, architectural stuff to the nitty gritty. I love it when pairing with a fellow vim-user as I will inevitably learn some new trick.
  • aprdm 5y ago
    Totally! On their laptop being the key. I interviewed at Pivotal around ~6 years ago and the person had some customized VIM setup which was a PITA to work with. He had a very good workflow with it and I honestly looked dumb trying to achieve the same things as him in his computer...
    • wdb 5y ago
      Yeah, or when they assume you have an English keyboard...
• villasv 5y ago
  > I understand why interviewers do this. They want to get a sense for what candidates actually know versus what they’ve copy/pasted from the web. Bad assumption. If you really did understand why , you wouldn’t say it’s stupid (unless for clickbait).
  • wizzwizz4 5y ago
    By that logic, no societal system can ever be broken.
  • gitowiec 5y ago
    I think that they want to hear is thinking. So every time I am during technical interview, I just talk out loud what I see in front of my eyes. That is great because they get to know my thinking process and it works as a rubber ducky for myself.
    • cogman10 5y ago
      This is something a great interviewee does. I don't try and trick interviewees or make things unnecessarily hard. I really just want to see "can you think like a programmer". When an interviewee gets stuck and isn't saying what they are thinking about, it makes it really hard for me as an interviewer to give good prompts. Obviously, I can't give away a solution, but at the same time some people will get stuck on things like "Can I use X" or "can I use Y". And for me, that answer is almost always "Yes, absolutely use X!". Because that's what I WANT from someone I'm working with. I don't want you to write a sort from scratch, I want you to call `Collections.sort` or even have the wherewithal to ask someone/google "Hey, I know Java has some inbuilt sorts, how do I invoke those?". The only time I'll maybe mark you lower is if you start the interview by saying "Yes, java is my favorite language to program in and I use it all the time!" and then struggle to do `new ArrayList<>()` (which has happened on multiple interviews). I always try to get someone to use whatever language they are most comfortable with. Because, to me, languages are stupidly easy to pick up and which one you are most familiar matters far less than how you use it.
• ub99 5y ago
  There is a limit to the proposed approach. Most interviews I conduct (algorithms) include puzzle-like problems. So if you just Google them - you would find a complete answer. In that case, what's left for the interviewee to solve? (Whether algorithm questions should be a part of the interview cycle is a different matter.)
  • aprdm 5y ago
    I interviewed at SkyScanner around 5 years ago and they gave me some problems that I already had seen since I was interviewing like crazy. I solved them very easily and the interviewee had nothing else to say. Then her feedback to the interview was negative because it looked like I had already seen the problem.. like... :shrugs:
    • wdb 5y ago
      Yes, Skyscanner is a horrible at hiring. Can't even bother to reject you or give feedback in the last round
  • tchalla 5y ago
    > Most interviews I conduct (algorithms) include puzzle-like problems. The reason for your predicament is in your comment.
    • ub99 5y ago
      It's a company policy with vetted questions, I dislike this approach.
• goalieca 5y ago
  This is one of my favourite tweets: https://twitter.com/mxcl/status/608682016205344768 https://twitter.com/mxcl/status/608682016205344768 I've seen some rather complex problems being asked in interviews. I've always wondered why my credentials don't seem to matter when it comes to programming skills. I have a masters degree where i did some very tricky algorithms and I even open-sourced it for all to see. But every time I've been looking for a job, i have to rehearse some leetcode problems so that i can put on a good show for 45 minutes. I get that deep-dives matter a lot and i can respect some of those exercises. These are crucial for senior positions since ideas are more important than code. Then I really get the life story kind of interviews because relating to coworkers and culture fit are hugely important. It's just the dang leetcode that ticks us all off isn't it?
  • vultour 5y ago
    I was also a fan of this tweet until I found out what inverting a binary tree actually is. Being asked to code relatively complicated algorithms like balancing a binary tree is one thing, but this guy essentially failed FizzBuzz. At that point it’s not about testing the limits of your candidate but filtering out the low hanging fruit. Obviously I don’t have the whole story of the interview, but it makes me a little worried for homebrew.
    • SQueeeeeL 5y ago
      Inverting a binary tree is essentially trivia in the context of most programming, honestly, if I had to do it without a library I'd be extremely worried I'd fuck it up in some subtle way. Max Howell obviously has a strong understanding of file systems, web protocols, package management, and a whole other suite of skills I'm too stupid to understand.
    • pydry 5y ago
      The fact it was trivia irrelevant to most programmers is precisely why it was such a brain dead question. Asking what FizzBuzz is is similarly useless and would also make an abysmal question.
    • ClumsyPilot 5y ago
• evrydayhustling 5y ago
  Our tech interviews focus on watching you work the way you actually work: Google allowed, your IDE of choice, your boilerplate project templates, etc. Yes, you still have to show progress against a problem in 30-60m -- but sometimes rapid prototyping is important to the job!
• stevebmark 5y ago
  This is a bad take. Coding interviews help you see how someone solves a problem. And good coding interviews let you search for whatever you want except for "how to do this problem in x language."
  • horsawlarway 5y ago
    I've done more interviews over the last two years than I'd like, and honestly - I have no problem with folks googling "how do I solve X in language Y". Frankly, we tell folks up front - "This is not a memory test, please feel free to ask questions, use google/stack overflow/man-pages/etc." I'm in the interview to give you a problem that looks as close as possible to the work we're going to ask you to do, and then discuss with you how you solved that problem. If you copy from stack overflow and it works, great! Now we can talk about possible edge cases, performance issues, testing, add a new requirement, etc. I don't really care how you get the code into the file, or where it comes from - I care that you understand it, and can think through how that code will perform in different situations. Most importantly of all - I care that you can tell me that information in a coherent fashion.
  • lliamander 5y ago
    What is your process for evaluating "how someone solves a problem" and how does that inform your hiring decision? Does it simply come down to "does this person solve the problem the way I would"? How do you address confounding issues like performance anxiety induced by constraints not present in a normal work scenario? My observation is that many companies don't address those problems well.
• smcl 5y ago
  Hold on, how are they “fundamentally broken” if the author is happy with the format with just a slight tweak (allowing use of Google, which many places do already)? I see that phrase a lot and it’s often deployed without a great deal of thought, which is a good indicator that what I’m about to read is a pretty low-effort article, blog post or tweet.
  • Invictus0 5y ago
    I think the author is trying to say that interviews are testing for the wrong thing (ability to solve tricky problems quickly, on the fly, and with no help, which is unrealistic in the workplace) when what they should be testing for is good analytical and research skills, with the assistance of the internet available, just like in real life.
    • pydry 5y ago
      Realism is criminally underrated in interviewing.
      • rsj_hn 5y ago
        Most likely because an interview is not a probationary period where the candidate does actual work. Neither can it simulate the important parts of doing the work. So you have to look for proxies you believe correlate well with being able to do work and test for those instead. Things that can be reasonable measured in 45 minute chunks, thus the proxies you pick will not at all look like someone doing actual work, they will be far removed from that. Hence they will not be "realistic". But that doesn't mean they aren't informative. So while it's true that having a candidate be able to write code that implements a stack and or whiteboard a simple app is not a realistic scenario of what they will be doing day to day, if they are able to do that well than they are much more likely to be able to do the work than if they are unable to do it well. So you use that as a proxy. Then 5 people interview for an hour, each using a different proxy, and you look at all the information the proxies are telling you to decide whether the candidate should be hired.
• yoz-y 5y ago
  I like the idea of letting the candidate do whatever they would if they were actually coding. I even think it could be interesting (in the initial part of the process) to ask the candidate what question they would like to be asked, and let them implement that. Few things to point out though: 1. you can ask the interviewer questions 2. the problems are usually simple enough that you don't need to google them, and should have prepared for them in the first place 3. you should be somewhat efficient (being able to do basic stuff without googling) in at least one language, since you can choose the language for the interview do that
• deleted 5y ago
  [deleted]
• jjordan 5y ago
  I'm lead dev on a rather large frontend project, and I still feel like I'd struggle in a frontend-focused interview today. Underappreciated by many I think is the ability to solve problems. I solve them (almost) every day, but sometimes it's easy, and sometimes it's really tough. But eventually, if you know how to ask the right questions, you'll get to a workable answer. That kind of real-world experience doesn't seem to surface well in a typical interviewer/interviewee type setting.
  • quickthrower2 5y ago
    And once you are a lead you are doing less of the stuff day to day that would make you shine in a coding interview. Especially the ones where “we need a c# engineer so let’s dust off those weird exception handling edge cases again and test on it” when in real life you look it up or run a unit test over it (better!)
• dahart 5y ago
  If the title was a comment, it would be breaking the site guidelines. More importantly, it's throwing out absolute opinions on why interviews are broken without demonstrating a real problem. There have been hundreds of articles saying hiring/interviews are broken because <logic/opinion>, and almost none that point to data showing that companies are not able to hire developers, nor that developers are statistically unable to get jobs. Interviews can be difficult and frustrating for both sides, but that doesn't mean they're not working. Despite the fact that the article is correct that looking things up is routine in a dev job, I still may prefer to hire the candidate who doesn't need to during my interview question that was specifically designed to not really need to. I don't know how often coding challenges disallow using the internet, but the last time I interviewed it was allowed. I've seen lots of companies allow use of any language, and spend your time searching the internet if you want.
  • ClumsyPilot 5y ago
    We literally have thousands of research studies demonstrating that place of birth, income, gender, and even names bias hiring. If it was this prilliant data driven meritocratic nirvana of scientific precision, we would never have issues with discrimination again minorities, the poor and people who looks funny and have tatoos. The burden of proof is on folks that keep pushing these silly tasks, where is the data "we've added some stupid questions to our interviews, and now we are doing twice better"?
    • dahart 5y ago
      Oh I'd agree there's cultural bias issues, but that is a complete straw man in this context. The article wasn't about cultural bias, nor was my reply. Meritocracy, incidentally, is a term that was invented to demonstrate bias, not a signifier of the ideal system. https://en.wikipedia.org/wiki/Meritocracy#Early_definitions https://en.wikipedia.org/wiki/Meritocracy#Early_definitions > The burden of proof is on folks that keep pushing these silly tasks This strikes me as a somewhat bizarre and myopic way of thinking about jobs. There is no burden of proof at all, because there is no claim being made. The deal here is someone will pay you money, if you agree to do the work they ask. This opportunity is available to people who make it through the interviews in order to demonstrate they meet the qualifications for the job. Companies that are hiring are the sole decider of what these qualifications are, and can choose to have them demonstrated in any way they choose (up to what we agree are legal limits.) If you don't want money, then don't submit to "silly tasks". (I've never witnessed silly tasks in my interviewing, ever. I've had questions for which I don't have experience, and questions that are too hard, but the questions have always been pretty focused on figuring out what I know and how good of a programmer I am, and by extension how much they are going to pay me...)
• ng12 5y ago
  Where are you interviewing that they don't let you google stuff? I've gotten to the point that I don't even ask anymore, I just open a new tab and explain what I'm looking for. If the interviewer takes issue with it that's a big red flag for me.
• lbarrow 5y ago
  I see posts like this all the time on HN and I really wonder if there's an alternate world of really stupid interview practices out there that I've just been lucky enough to avoid. In this case: I've never heard of, participated in or administered a programming interview where the candidate couldn't Google things. I remember when I interviewed at Braintree, I spent a good chunk of the pairing interview searching for Linux command syntax because I was new to using it. I got the job and spent 7 years there.
  • chrisseaton 5y ago
    Are you allowed to Google things in a Google interview? I don’t think I was allowed to! How would that even work? You’d just Google for the answer to the brain teaser and find it because there’s only so many brain teasers out there.
    • lbarrow 5y ago
      I'm referring to a programming interview, where you are writing code with the candidate -- not a brain teaser.
      • chrisseaton 5y ago
        I'm not sure there's much of a clear line between the two. Google asked me to solve what was really a brain teaser, but solve it using code. Don't think I was allowed to Google anything.
        • lbarrow 5y ago
          That's fair, in that situation there's probably a valid case for disallowing use of a search engine. Whether or not that's an effective interview is another story :)
  • jl2718 5y ago
    I failed an interview once because I knew pacman but they were looking for apt. Big green GPU company.
• TrackerFF 5y ago
  Probably very controversial opinion, but so far, my favorite type of interviews have actually been take-home problems. Of course, it sucks if you've invested time into those, and get ghosted afterwards - but luckily I have yet to experience that. Some people excel on taking test, some people excel on projects, others in both - I've personally never been the type to perform well on banging out code on whiteboards, but I will perform well on projects. edit: Let me expand a bit on this All my take-home problems have been very reasonable. Usually they've been more big-picture / architecture oriented, and not some specific implementation - some coding, some presentation, usually takes 2-6 hours to complete, depending on how much you put into it. It is of course unfortunate if someone decides to code up something for a whole weekend, like 20-30 hours, only to get ghosted or similar. I guess it comes down to identifying free work from actual interview problems.
  • SteveNuts 5y ago
    Not controversial so long as they pay you for your time. This should be standard practice IMO
    • amelius 5y ago
      Perhaps both parties should pay, i.e. 50/50.
      • lokimedes 5y ago
        Well it is a single-sided risk reduction strategy. The candidate presumably is convinced that she can fulfill the role regardless of the test.
        • quickthrower2 5y ago
          Then does the candidate pay for the part of the time spent explaining the company and role?
    • andrewingram 5y ago
      Personally I don't find making my tax situation more complicated doesn't help with the stress of job applications. I did a work trial last year and it added a whole new layer of anxiety about figuring out how i'm supposed to declare ad-hoc income (which in this case was foreign, making it even more complicated). If you're used to something like the UK's PAYE system, being paid for interviewing is far from a no-brainer.
• froggertoaster 5y ago
  What a way to add nothing to a conversation horse that's been beaten to death as is.
• jordache 5y ago
  Just ask them to articulate technical concepts, so you can know whether they are full of sh*r not. People who can hold targeted low-level technical conversations are generally well equipped to do the work you are expecting him/her to do. What's wrong with this approach?
  • lordnacho 5y ago
    That's my preferred method as well. Talk about the stuff, throw in words they should have heard of. See if they run out of intelligent things to say.
    • jordache 5y ago
      A good question for ppl in the coding challenge camp. What new information do you neeed from a coding challenge that you don't get talking shop with the individual? I don't think low level technical stuff is something you can BS your way through an interview. If it works on you, then you as an interviewer has major gaps
• davidw 5y ago
  I find the 'take home exercise' to be tolerable. I hate the live coding things. Those are awful. Even the take home things are not fantastic, though - if you already have a job, a family and other stuff going on, "just 4 hours" is kind of a PITA.
  • handrous 5y ago
    "Just 4 hours" for a chance at the job, and how high a chance depends on the employer (i.e. how early in the process they drop the take-home exercise on you, whether you've already come to terms on pay at that point, et c.) In general I just wish places that weren't FAANG would be more open about their process. Do I need to brush up on leetcode shit before applying, or no? Are you gonna quiz me on obscure corners of a language that I reflexively avoid because they're terrible, so haven't thought about in a while? Gonna talk architecture? Will I be writing code with someone looking over my shoulder? Pairing? On what kind of thing, generally? Is your filter for the 200 candidates who apply to hit them with a take-home assignment or longish automated test first thing, so I know to just skip applying at all (screw burning that much time to apply for the privilege of getting an interview at just one place)? With FAANG you know what you're getting in to, so at least you know you're about to step in a big pile of shit and can put on your waders first. The blind roulette wheel of hiring outside FAANG is its own kind of trash-fire.
  • quickthrower2 5y ago
    I remember this with a newborn I spent 20 minutes on such a test. Recruiter tells me they said no because code quality so i gave it another shot spending 2 hours. Remember with multiple applications these times added up. Got to the interview and they were so obsessed about this being written in some “perfect way” (see the enterprise fizz buzz someone linked to) that they knocked me back when I was explaining it at the interview. It’s the coding equivalent of “ooh so you are not using a suse vide” at a mates bbq.
• rullelito 5y ago
  When I interview using coding problems, you just need to know very basic Java or python to solve the problem. We also nudge interviewees in the right direction to make sure they don't get stuck, which would be in no ones interest. There is also no hard requirement that you need to solve the problem completely. If you talk to someone for 45 minutes about a coding problem you will get a good sense of their performance, even if they don't solve the problem. Coding interviews are great (except making the intervieww very nervous), but you have to be mindful as an interviewer.
• roland35 5y ago
  I disagree that coding challenges are stupid, I actually find them having some of the best signal-to-noise ratio of any step in the interview. Maybe it depends a lot on what type of coding problem it is? One important aspect of doing the coding interview well is to make it generic enough and not look for a specific exact solution, so things like "write a function for a movie theater ticket dispenser" vs "write the most efficient string reversal" function. I am also totally fine if a candidate needs to look something up, but I don't think it is unreasonable to expect candidates to be able to work though a general coding exercise without needing to stop and google things frequently. Especially if they can pick their own preferred language!
  • planet-and-halo 5y ago
    It's largely in the execution. Coding exercises are probably the best thing you can do, but many interviewers use them to ask bizarre trivia and look down on people who don't have it memorized.
• grishka 5y ago
  I want to take one of these interviews just to look the interviewer in the eyes and ask one question. Since I'm not allowed to google stuff now, would that mean I won't be allowed to do that while working for your company as well?
  • nappy-doo 5y ago
    Ok, go ahead. Ask me a question. I've done > 400 interviews at FAANG companies, so I guess I'm due.
• jamal-kumar 5y ago
  After convincing the boss to fire a guy who laughed at me using vim saying it was really old and then proceeded to push broken code to production at 4am, trying to blame it on me when the logs were really not in his favour, I ended up in the position of doing the hiring for a guy to replace this yahoo. I live in a country where people's resumes fit in a damn manila envelope because there's just SO MUCH emphasis on degrees and stuff like that, and while the education here is pretty good (A lot of focus on hardware in the compsci curriculum here actually), really all I wanted after rejecting a bunch of prospects for technobabbling bullshit at me with their huge, multi page resumes i barely read was someone to tell me humbly enough that he'd just have to google the solution to the really damn easy fizzbuzz i was presenting them. You know how hard it was to find that in a braindrain situation? My boss thought I was being too mean, but really I just can't work with dishonest people. It's the most important thing to me that I actually like my coworkers for being good people. A coding interview of the MOST BASIC kind can act as a sort of filter for this. Like sheesh, I'm not looking for this: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris... All I want is to know if you know how to work with a modulo operators or not in an honest way, if you know basic third grade level integer division with remainders. If you give me bullshit instead of that, chances are you're not going to get hired. A probationary period for a couple of weeks after on the job after that to see how good you actually are, paid, with the knowledge that if you're just a terrible programmer you don't make it past that.
• the_jeremy 5y ago
  As a job searcher, I want to be able to spend as little time as possible on the interview process for one company. I don't mind researching the company or talking about their specific process, but I want to minimize the amount of time I have to take to prove my competence to them, because that's something that should transfer well between the different roles I'm pursuing. I understand that not everyone has an OSS portfolio, but it's better than having 5 different companies give me a unique take-home project, and then having another 3 companies give me an algorithms assessment. If everything was "let's take a look at one repo you've spent <10 hours on" or "let's do leetcode problems" that would be preferable to the current state of affairs, because as it stands I have the worst of both worlds.
  • ClumsyPilot 5y ago
    The best is when they give you a take-home problem and an agreement: "we own all the code you write, dont show this to anyone"
• karmakaze 5y ago
  The author hasn't had the more dynamic interactive form of tech interview that I (as a platform dev) am used to. > Coding is solving problems. A big part of that is looking stuff up. Like, seriously, the most important skill a developer can have it knowing how to research solutions to problems. Specifically… Breaking problems into parts Identifying what to search for Knowing how to sort good info from junk Rather than have them Google things, there's an open dialog with the interviewer where the candidate thinks out loud and the interviewer gives the 'search results' for them to use now, later, or not. The interview is not about 'if' the candidate can solve the problem. Even it they don't the result can be positive. It's about how they think, break things down, compose the parts into a solution. No one should care if you memorized the syntax of anything.
  • kokanee 5y ago
    Agree with this. In my experience interviewers don't mind if you would normally look something up, but you need to state "hmm I always forget which direction Array.sort sorts based on your return value" and they'll usually say something like "yeah me too, let's try it this way and flip it if needed." If you say nothing and freeze or implement it incorrectly without making it clear that you half expected it, the same situation feels much worse. In general, I've been seeing some conflation between the "tech interviews are broken" sentiment and the "tech interviews are too hard" sentiment. There's probably some truth to both, and some specific things that both interviewers and candidates can do differently to make more interviews more productive. In all cases, being calm and congenial and trying to put the other person at ease (even if you're the candidate) can work wonders.
  • rimliu 5y ago
    > It's about how they think, break things down, compose > the parts into a solution I usually think in silence, and alone.
    • karmakaze 5y ago
      That's fine too. Often if I'm thinking out loud it's for the benefit of the interviewer so they don't get bored or confused later when I write a bunch of stuff after a long period of silence. I also tend to do a lot of scribbling of intermediate picture/thoughts that I wipe and redo so it's not a complete void. Where it can penalize you is if you don't finish and not having talked/shown your work to that point doesn't count for as much. The best tech interview is if you describe the strategy, algorithm outline and datastructures that you would be using and the interviewer says, "that's good enough, next question".
• amusedcyclist 5y ago
  Looking up things isn't solving problems. Sometimes you need to look up things to solve problems but they are fundamentally unrelated. Coding interviews generally require 0 background (other than base CS principles) so you shouldn't need to look up anything. I've never had someone ask me for correct syntax in an interview setting.
• rasfincher 5y ago
  One of the companies I interviewed with did what he described and it was nice. I thought the cool thing was that in the second interview they wanted me to walk them through some of my thought process for why I did/searched for certain things. I didn't end up taking the job, but boy was it a breath of fresh air compared to some of the other interviews I've done.
• deleted 5y ago
  [deleted]
• thenanyu 5y ago
  Posts like this pop up pretty frequently. The format is usually… > I hate tech interviews, they’re a poor proxy for real work. > Here are some ways they’re silly (some examples follow). > A good interview would not have these bad features, maybe someone should do that. What I’ve observed in 12 years of practice is — It works; things go south quickly if you don’t do rigorous technical interviewing. There is huge variance between interviewers, in both accuracy and bedside manner. The most effective signal by far (close to 100%) is: someone I already trust technically who has worked with them says they’re good, and is willing to stake their reputation on it. I enthusiastically skip the more tedious parts of interviewing in these cases. Interesting things I’ve seen, experienced, or practiced: Long trial contracts to hire, no exceptions. Buys you accuracy at the cost of reduced candidate pool. Willingness to fire quickly (first 30 days) — in practice similar to above. This is often advocated for but rarely implemented. De-emphasize interview, heavily game-plan and weigh reference calls; do a lot of them (5+). This works if you have the technique to blow past the boilerplate endorsements.
  • dfadsadsf 5y ago
    > The most effective signal by far (close to 100%) is: someone I already trust technically who has worked with them says they’re good, and is willing to stake their reputation on it. I enthusiastically skip the more tedious parts of interviewing in these cases. This works in small companies where somebody you refer will likely work directly with you and your reputation is at stake. This breaks at around 100 people or so. If you refer somebody to big company, chances are you will never work with them directly and your reputation is not at stake. Why not help out a unqualified friend at a cost to big faceless company?
    • thenanyu 5y ago
      I’ve seen it work in companies at scale, though it’s not universal. Teams are still on the order of 20 or so and the dynamics still apply. Beyond that, you’re right — but even at huge companies a lot of exec hiring is done that way. I got hired into a big i-bank through a couple of Facebook messages. We ticked all the HR boxes but it was a done deal. Happens all the time
• spideymans 5y ago
  I much prefer interview styles where the candidate and the interviewer just talk about a technical solution they've solved in detail (challenges, architectural decisions, etc...). It'll become evident fairly quickly if the candidate doesn't know what they're talking about.
  • quickthrower2 5y ago
    Except for me there is a half life of about 48 hours on how detailed I can talk about that solution. This has me thinking that interviews should openly publish what types of question you’ll be asked so you can prepare. Otherwise it’s prepare for anything, which is 20 or more hours work per interview, and requires me deciding what animal I am.
• NiceWayToDoIT 5y ago
  Point of the interview should be to asses knowledge and thinking process, and many other things. Definitely, it is not easy, as in one hour someone needs to assess that person is not faking his entire working history, and that has acceptable skills for the certain role. One of the good interviews I had was with few people DB/Architecture/Testing/Coding at the end they had combined overview. Usually when I am interviewing I would allow everything, as I am more interested in thinking process of attempting to solve something than actually giving me some clever solution in extra limited time. For me it is interesting that many companies have decoupled skills vs. money paid for those skills expectation, and often they would like to have star workaholic developers but only if they could pay them as McDonald employees. What I am trying to say, don't have an interview like you trying to employee in Google if you are are not prepared to pay those people like the Google.
• Zababa 5y ago
  > I understand why interviewers do this. They want to get a sense for what candidates actually know versus what they’ve copy/pasted from the web. But this process is stupid for a variety of reasons. That's not how I understand them. I always saw them as a way to see if the candidate is ready to invest a certain amount of time and energy. A bit like "if you can grind leetcode and pass the X interview, you can probably contribute to our codebase".
• nsonha 5y ago
  Poorly written blog post. What an elaborate way to say "let me google". Except for hackerank type of interview, I've always been able to google or ask interviewers to help me out. Just have some communication skill and communicate in the interviews, they want to test that in you too, rightfully so.
• kokanator 5y ago
  They are missing the point. Coding interview has very little to do with Code! I hire a lot of developers and the code interview is a pivotal point in the process. This is where I find out how you collaborate, take new ideas and incorporate them, deal with changing requirements, handle criticism etc. Of course I am validating you actually know how to code but I am really looking for the rest other skills because this is what will make you a valuable integral part of the development environment here. Trying to throw a 'stump the jock' type of question at a developer is worthless and only proves to show how well they memorize things. Throwing them a difficult problem that requires them to research, ask questions, collaborate will show how well they will grow and take on new challenges they are uncomfortable with.
• caymanjim 5y ago
  One thing I rarely see talked about is that the people doing tech interviews just plain suck at interviewing. Everyone assumes intent; that interviews go a certain way because someone has decided they should go that way. While that is quite possibly true at FANG, in my experience it's not the case elsewhere. Interviews at most companies amount to "hey, who wants to/can interview someone next week?" Some people volunteer, and then they wing it. They might do a FANG-style interview because that's what they think they're supposed to do. They might parrot whatever the interview process was when they were hired. They usually just wing it, making up questions as they go. It's not normally intentional or nefarious. Good engineers don't often make good interviewers. Sometimes they don't want to be doing the interview, and are simply trying to bumble through it. Usually, they have the best intentions, but they don't know what they're doing. No one's prepared them; they haven't prepared themselves (and likely don't know how to). Everyone usually has good intentions. They want to give the candidate a fair shake; they don't want to make the wrong decision; they want to find a good coworker; they want to do their employer a solid by finding the best employee. I know I suck at interviewing, despite doing it dozens of times. I've had a few regrets about people I've hired, but not many. Whatever failures my process has, I don't think they're too egregious. I've been on my own to figure out what works and what doesn't.
• jkingsbery 5y ago
  As others have mentioned, this is more a sign of bad interviewers than a bad format. Of the companies I've worked at, at least one has allowed googling during the interview, and most de-emphasize all the stuff you have to look up in order to focus on the problem-break-down part of the question. I think there's too much imitation without understanding in interviewing. Candidates hear questions, and then go on to repeat them when it's their turn to be interviewers, without really understanding what's behind the question. These new interviewers then approach the interview as if they were administering a coding test, whereas what they ought to be doing is facilitating a conversation using the question as a starting prompt. The other problem that I see sometimes with interviewing is interviewers asking obscure questions. Really good candidates aren't solving the problem on the spot - they've come across problems like the one the interviewer asks, and are using approaches they've already validated in their life experience. When an interviewer asks an obscure question, they are not helping to facilitate a conversation as to whether the candidate can handle the typical things that would come his or her way.
• juancn 5y ago
  The problem result is not the goal of the exercise, I don't care if you solve it, but rather how you approach it. Note that I don't use puzzle problems, but more open-ended ones that elicit discussion and architectural approaches rather than simple coding. When I'm interviewing I'm google for all intents and purposes. I want to see how you interact, what you're thinking and how it would be like working with you as a team member. I look for potential and red flags. I try to find out two main things: - will you be good for the team? - will the team be good for you? It's a two way relationship we're trying to build here. Interviewing is a lot like speed dating, we're trying to find a long term partner in a very small amount of time.
• kodah 5y ago
  Some context, first: I work on infrastructure software. I'll try to define it so it's not so vague: software that is core to the company's platform that has strict performance, stability, and FMEA guarantees. Often the skillset we look for is niche, you need systems skills (broad spectrum, both OS and network) as well as software skills (preferred polyglot; "languages are tools" kind of people). On one hand, I deplore the runaway game that software has let algorithmic knowledge play on our minds. People destroy themselves preparing for interviews at large firms on exciting teams, only to get blown away because someone threw them a curveball in algorithm or systems design knowledge. On the other hand, I've watched developers copy solutions on one screen and transpose them on another. I've hired engineers only to find out they only know the kind of information we would ask in an interview and how to bullshit. College will never provide my team the guarantees we need to make a hire, that much is well-accepted. Being from a "top tier" company is no guarantee either. What I do think is worthwhile is investing in two things simultaneously: 1. An apprenticeship program. I entered software (and mathematics in general) without a degree. These subjects can be learned with self-discipline and having a career that gradually increases in complexity is a perfect aid to this learning process. In my path, it produced a generalist software engineer with a specialty in systems engineering. In another, it could produce a web backend software engineer, a frontend engineer, an infrastructure engineer, etc... 2. A certification exam. I mean something orthogonal to Professional Engineering or the Bar exam. Something entirely divorced from colleges that can prove you can negotiate algorithms and data structures. I believe people who are keen enough to figure this out once can figure it out again when the time is needed, however, in most cases your brains will be put to more abstract talents that are non-numerical in nature. Reserving your sanity for then, rather than depleting it all throughout the interviewing process over the course of your career seems to me to be the optimal choice.