26 ms·

Hiring Is Broken: What Do Developers Say About Technical Interviews?

• justinmk 7y ago
  > “I think it’s offensive and I don’t like how the industry has standardized on basically assuming everyone’s a bullshitter,” I think it's weird for people to complain about whiteboards and technical questions, given the implied alternative. There are many other industries if you prefer the traditional hiring model. That is, if you can get an interview. While you complain about the awkwardness of a whiteboard, people in other industries are quite happy to get a call. And in the interview, they compete in terms of poise, diction, rapport, and other intangibles, without the chance to repair any lack thereof by demonstrating technical competence. And they get 1 hour to make their case, not 3-6 hours.
  • tamersalama 7y ago
    There must exist a middle ground somewhere.
    • justinmk 7y ago
      But we are not in an "extreme". All of the complaining is tiresome. Some companies have difficult interviews, many do not. Who cares?
      • mixmastamyk 7y ago
        All companies cargo-cult some version of this nonsense today.
        • AnimalMuppet 7y ago
          All? No.
          • mixmastamyk 7y ago
            I've not interviewed with one that didn't in almost ten years, possibly more.
            • username90 7y ago
              Did you try to interview at companies paying $80k to senior engineers? Low status companies tend to have more normal interview processes, many don't even ask you to code before hiring you. This way you can get similar pay and interviewing as people get in other fields.
              • mixmastamyk 7y ago
                Not a viable wage in Southern CA these days; have not seen an ad at that rate in any case. Guess the gist is that bottom of the barrel jobs have easier interviews. I could buy that.
  • mlthoughts2018 7y ago
    I think it’s interesting when people characterize feedback about technical interview shortfalls as “complaining” ... reveals a lot of the pre-existing bias in this very contentious topic.
    • MegaButts 7y ago
      The few times I have been able to get genuine feedback, I have always been incredibly grateful.
  • shados 7y ago
    > That is, if you can get an interview That's a solid point. Yeah, engineering interviewing could be better, a lot better, but as we push to improve it, it's really important to keep in mind how privileged we are. I remember having a discussion with one of my friends in a different field who was thrilled to get a recruiter pinging them on Linkedin, for example. Also, given how chaotic the field is, and how people come from all sides (some with CS degrees, some self taught, some who worked at great tech companies, some who didn't, etc), assuming everyone's a bullshitter is unfortunately kind of expected. We absolutely should treat people with respect and dignity, but that doesn't mean being naive either. And in other fields getting fired and even demotions are pretty common, while in big tech hubs thats nearly unheard of, except for extreme cases or very very entry level people.
    • avh02 7y ago
      "Engineering"
      • shados 7y ago
        Hah. Point taken.
        • avh02 7y ago
          Wasn't about you in particular to be honest (but I like how you owned it). Personally, my official position is "software engineer" and I hate it. We have nowhere near the culpability engineers in other disciplines do.
          • shados 7y ago
            Ironically it took me a while to even start using that terminology. Where I'm from, "engineer" means something specific, even in software, and you can't just call yourself an engineer (well, there's no LAW against it, but people will call bullshit pretty fast if you didn't go through the right channels). In the US, everyone's an engineer. Im surprised the person who serves me my burger at the counter isn't a Bovine Product Assembly Engineer.
  • RubenSandwich 7y ago
    In other industries their past experience is also believed, rather then tested by random facts. I’ve had an interviewer ask me how to change Swift method names when exposing them to Objective C and then take that as an indicator of my whole iOS skill set.
    • shados 7y ago
      Most fields where experience is "believed" fall in one of a couple of categories: 1) Extremely regulated fields with strict education, training and certification requirements (eg: a physician) 2) Fields where you have to show something. Designers frequently need to have extensive portfolios. Carpenters need both that and real world referrals of happy customers (not just nearly automated HR checks we have in software dev where no one will say anything bad out of fear of getting sued) 3) Trial period followed by sink or swim. Come work for us and if it doesn't work out we'll demote you or fire you. There's a few places like that (I think its Netflix's model?), but generally firing someone has everyone around calling foul.
      • colmvp 7y ago
        The trial period is not without its flaws but I’ve always preferred that over take home tests and puzzles because it gives both parties time to truly assess one another. I’ve done it twice in my career and I appreciated getting paid like a contractor and giving more time to understand whether or not I really fit at the company I was joining. Likewise, the company’s weren’t 100% assured that I was good but I was able to prove my value both times.
        • shados 7y ago
          I wouldn't deal with the contractor paperwork myself, but in at will employment states that's not even needed. Hire by W-2 and let go after a few months if it doesn't work out. Thats absolutely my personal preference. The argument against it (very valid), is that if someone with a family relying on their paycheck quits their job to go work at another with that policy, and gets let go after 3 months, they're kind of fucked.
      • 7y ago
  • civilian 7y ago
    False dichotomy :) Just because something is different from the stupid option, doesn't make it a good option.
    • nck4222 7y ago
      White boarding is the worst form of interviewing, except for all the other forms that have been tried.
  • SantalBlush 7y ago
    >And in the interview, they compete in terms of poise, diction, rapport, and other intangibles Don't forget the interviewer's arbitrary "system" for weeding out applicants that has no basis in research and varies from one hiring manager to the next.
  • xamuel 7y ago
    If you give someone gold long enough, eventually they'll complain how heavy and ugly gold is. Whiteboards are an unbelievable utopia compared to so many other disciplines. It's an amazing stroke of luck that software developers don't have to do medical-style "residencies". We don't have to rely on letters of recommendation from our professors (hope that professor you slaved away for for six years doesn't have a bad day when he writes your letter!) We don't have to pay thousands of dollars to take excruciating standardized tests to obtain certifications that expire in a decade. We don't have to do unpaid internships, we don't even have to wear business suits to the interview. Software devs don't realize how many people in the world would kill to have things as good as we have them.
    • walshemj 7y ago
      A relatively badly paid and low status utopia at the same level of experience and you don't get pushed out at 45 as to old.
    • gjm11 7y ago
      There's a lot of truth in that. But I'm not sure it's that developers are being given gold and don't recognize it. It's that developers are being given mud and recognize it, while most other people are being given shit instead. I'd rather be handed a pile of mud than a pile of shit, but it's not hard to feel that there must be some alternative that's better than either. (Maybe there isn't, though. Matching candidates to jobs is just hard, I think; everyone's incentives are misaligned, performance is difficult to predict, it's amazingly difficult to get past your initial snap judgements or even to realise that you're failing to do so, etc.)
      • lacker 7y ago
        Well, some developers feel like they are being given mud. But developers who are really good at whiteboard interviews feel like they are being given gold.
    • suzzer99 7y ago
      I'd be thrilled with that. I've got a great resume, great references from former bosses, and have plenty enough confidence in my ability to work contract for a while to prove myself. The problem is those things only get you in the door, then it 100% comes down to your whiteboard under-fire skills - which admittedly have gotten worse for me the older I get. Although I know I'm a better programmer now.
  • tropicalia 7y ago
    Without the chance to repair any lack thereof by demonstrating technical competence. As if it's a given the whiteboard process actually provides a useful measure of technical competence.
  • alkonaut 7y ago
    The problem isn't technical interviews it's bad technical interviews. I think this is pretty "regional", with many people reporting big tech companies in e.g. the Bay Area doing things like have people code textbook algorithms on whiteboards. Technical interviews where you look at some code and review it, or is asked to broadly describe how to design a system etc isn't unreasonable, and as you say it's better than judging only on poise...
• tropicalia 7y ago
  Let’s begin with a technical interview problem. Consider the following coding question from LeetCode, an online platform for preparing software development candidates for interviews: [statement of the Maximum Subarray Problem] Before going further—and regardless of your coding proficiency—we’d like you to spend a few minutes and take a stab at this question. From Wikipedia: The maximum subarray problem was proposed by Ulf Grenander in 1977 as a simplified model for maximum likelihood estimation of patterns in digitized images. ... Grenander derived an algorithm that solves the one-dimensional problem in O(n2) time, improving the brute force running time of O(n3). Jay Kadane of Carnegie Mellon University soon after designed an O(n)-time algorithm for the one-dimensional problem,[1] which is clearly as fast as possible. The same O(n)-time algorithm was later automatically derived by algebraic manipulation of the brute-force algorithm using the Bird–Meertens formalism.[2] If you really think anyone -- short of a faculty-level algorithm specialist at places like CMU -- can be reasonably expected to derive an optimal solution to problems like these on the spot (as opposed to the way candidates are actually forced to prove their ability to "solve" them: by binge-cramming on dozens and dozens of problems like these for weeks on end, so that they have at least a 50 percent change of passing your "filter") -- the you're either very naive, or deliberately kidding yourself.
  • lacker 7y ago
    If you really think anyone -- short of a faculty-level algorithm specialist at places like CMU -- can be reasonably expected to derive an optimal solution to problems like these on the spot Eh, you really don't need to be a "faculty-level algorithm specialist" to solve this problem. I wouldn't even really call it dynamic programming. Just make one pass to calculate the sum of the first n numbers for each n. Call that array prefixSum. Then you make a second pass calculating the lowest prefixSum[i] for i <= n. Call that smallestPrefixSum. The maximum subarray sum is then defined by the largest prefixSum[i] - smallestPrefixSum[i], and you can get the subarray itself with a bit more tracking. I don't know if it's a great interview question but I think most of the engineers I have hired (at Google or Facebook) would be able to solve this problem on the spot, given 15-20 minutes.
    • mercutio2 7y ago
• Nelkins 7y ago
  Honest question, which I can't really answer myself: Do people think the hiring process for developers is more broken as compared to other industries? My personal experience says that interviewing as a developer is often more straightforward and less arbitrary than what my non-tech friends have experienced. Can anyone who has made career changes to or from tech give their experience?
  • SQueeeeeL 7y ago
    All hiring is extremely arbitrary. The reason coding is so bad is because there's this huge myth of lower class workers becoming coders overnight, just by studying for a few months of leet code. There is an essay about the feminist movement in the 70s (https://www.jofreeman.com/joreen/tyranny.htm https://www.jofreeman.com/joreen/tyranny.htm). It makes the reasonable point that people are likely to hire/recruit people similar to themselves. The code interviews are expected to remove this, if you stick a bunch of CS people in a room and tell them to make an unbiased interview process; you'll get the hell world we live in today. To get a job on a sales floor, most of it is just impressing the existing gate-keepers. Coders live in a fantasy world where gate keeping isn't real. Except it isn't possible to remove that from hiring, no one wants to hire someone who doesn't integrate well in their team. So we have this hellworld where people can study for 3 months on leet code and nail the tech interview, they still won't get the job. Even though the "unbias" process says they should.
  • yulaow 7y ago
    Most of other high skill professionals in other engineering fields that I know have a fairly easy hiring process: their degree + their license + their previous working experience is enough. The interview is basically just an hr screening to avoid jerk personalities.
• twblalock 7y ago
  Every time this comes up on HN we see why the problem is so hard to solve: - Nobody likes whiteboarding - Take-home assignments are unpaid work, and candidates who are raising children don't have time to do homework after they get home from work - Pair programming during interviews makes people uncomfortable because of the pace or because it's not how they are used to working - People who currently have good jobs are unwilling to consider contract-to-hire or "tryout" periods - Credentials, including graduate degrees, are no guarantee that someone is a good engineer The current interviewing situation in the industry sucks but all of the alternatives are worse in important ways.
  • shados 7y ago
    If we could just accept that not all companies should cater to everyone, and each can pick their methods that work for them (and if you don't like it as an applicant, go elsewhere), things would be a bit simpler. When Im looking for a job, I make it pretty clear what Im ok and not ok with, which will dictate which companies Ill interview at or not. If we were in a dotcom crash it would be a different story, but right now its definitely something people can do.
  • SQueeeeeL 7y ago
    "- Credentials, including graduate degrees, are no guarantee that someone is a good engineer" Too true, I've started to recruit non-CS people and teaching them how to code. The state of CS education in the US is insanely inconsistent. But I'm lucky, I have lots of time to train people; most companies can't handle months of startup time.
    • somatic 7y ago
      Want to hire me? I’m a reasonably competent programmer already, pretty good designer. Most recently I wanted to familiarize myself with the basics of C++ so I wrote my own big integer library.
  • curtis 7y ago
    I'm OK with whiteboarding. I don't object to take-home assignments in principal, but I do object to them in practice -- they take up way too much time, and then part of the time you get ghosted after submitting them. I think the right answer here, to the extent that there is a right answer, is to give applicants a choice.
• curtis 7y ago
  Last time I was looking for a job (about 3 years ago in Seattle) I had a lot of trouble getting through the initial screening to even get to a technical interview. I didn't have a lot of luck until I started applying through AngelList. One notable thing about AngelList applications is that there was no HR/recruiter screening step you had to get through first.
  • lordnacho 7y ago
    Don't the firms on AL tend to be smaller firms? That would explain it.
• leet_thow 7y ago
  I just went through the interview process with multiple Bay Area startups. Competency and experience don't really account for much and it is much more about the companies internal politics. People are thrown in a room without any evidence based HR training to wing it. The processes are ridiculously bureaucratic, in most scenarios you need approval from 5 different people who at any time can decide they don't like you for their own personal reasons. Given a 50/50 chance with each person, that is a 3% chance of getting an offer. People have no idea what they are doing.
  • dahart 7y ago
    > People have no idea what they are doing Just for some friendly and non-judgemental feedback from a different point of view, to me that sounds like more of your own fear coming out than reality. Everyone who interviewed you also said the same things out of fear before they were hired, and then they got in and didn't manage to change it. That could mean it's not viewed as a problem from the inside... Companies are hiring people onto teams, not to hero-solve pure code problems in a vacuum, but to work together with other people. Communication and personality and attitude are all super important, usually more important than technical skill. (That doesn't mean technical skill is unimportant, it means precisely that people skills are more important, for the average programmer candidate.) It's a feature, not a bug, that team consensus is needed. And there's rarely 50/50 chances, using that to speculate wildly on your chances will prove incredibly inaccurate... the most common case behind the scenes is that more or less everyone agrees that either the candidate is right, or that they're not right, or that everyone is meh on the candidate so nobody is pulling for them. Chances are determined by how many people are applying for the job versus how many jobs are available, with a side of how long the company wants to take to fill those positions. The company has the upper-hand knowledge of what the candidate pool looks like, and they can hire the top 10% of those candidates who apply. As an applicant, you have no idea and no control over that. All you can do is improve yourself, research as much as you can, try many options, and try again when it doesn't work out.
    • bradlys 7y ago
      I'm working at a unicorn. It's a relatively unknown one. They have no idea what they're doing. I've talked to peers across the bay and with my various companies I've worked at - they almost universally don't know what they're doing. I've interviewed at over 100 places in the bay area. I'd say that from internally and externally, most of the companies here have no idea what they're doing. Most don't use rubrics, most don't have a standardized set of questions that have been heavily reviewed and tested, there is either no training or inadequate training, and most are winging it completely. Many ask whiteboard questions to interview candidates and they never had to do them for the job they got (got in through referral or at a different stage when they weren't doing such questions). Resume, referrals, and charisma will get you into positions very easily in many of these companies even if you're very technically challenged compared to others with less resume+referral+charisma. Being liked is one of the best ways to get into positions you are terrible at but compensated so well for.
• jedberg 7y ago
  The problem with hiring in our industry is the lack of licensing/certification that everyone trusts. When a doctor interviews for a job, they don't ask the doctor to perform six surgeries in a day for free and then say, "we'll get back to you". That's because they know that if the doctor holds a license and a degree, they have the necessary skills. We don't have that in our industry. I interviewed countless "senior engineers" with degrees from well regarded universities who couldn't write a simple loop. Therefore I must now conclude that a degree from that university means nothing. There are some folks like Tripplebyte who are trying to solve this by pre-qualifying candidates, but I don't think the problem will really be solved until we form a software engineering licensing board. Take a test once, and then take a refresher course every couple of years to maintain your license.
  • jorblumesea 7y ago
    Be careful what you wish for. I have friends that are lawyers and they talk about how terrible the bar is for assessing real world skill. You need to be fairly well versed in 20+ forms of law (admin, criminal, civil etc) independent of what form of law you practice. Most of the test is irrelevant to what you do, but you need to know it anyways. I guess the advantage is once you pass you don't need to re-certify. Which also seems incorrect.
  • quadrifoliate 7y ago
    > When a doctor interviews for a job, they don't ask the doctor to perform six surgeries in a day for free and then say, "we'll get back to you"...have interviewed countless "senior engineers" with degrees from well regarded universities who couldn't write a simple loop. I think this is fundamental to the discussion. Are we really sure they couldn't write a simple loop, or were there other factors that prevented them from doing so? For comparison with your other analogy, keep in mind that even surgeons who have amputated the wrong limb are defended by their colleagues, saying “Well, it should have been amputated anyway.” (https://www.nytimes.com/1995/09/17/us/doctor-who-cut-off-wrong-leg-is-defended-by-colleagues.html https://www.nytimes.com/1995/09/17/us/doctor-who-cut-off-wro...) I understand that you specifically might not have used that as your only filter, but a lot of people do – and I think a more holistic approach that takes into account education, training so far, and overall experience with tech. Certifications might be one part of this too.
• gopalv 7y ago
  > He has Aspergers and locks up and fails miserably in the interviewing process, but the honest, reality is, he is10 times the developer I am, the guy sees patterns instantly and has a knack for code organization. I don't think I can get hired without a referral - haven't managed to land a cold interview once so far. So at least, there's no evidence of it. Interviews are a performance act, they are the packaging that you throw away after buying a product for the cover. The interview "suit" I wear is actually one of someone who's calm and smiling - instead of stimming with my hair and dead-pan with a smirk (if I was a woman, I'd have resting b-tch face). I feel for this guy, because I figure out how to wear that suit, but I still need to thumb the scales to get hired, because the mask I'm wearing is effort & it does show to the perceptive HR person (& it doesn't matter what you are faking - if you're faking it, it counts against you). However, here's where everything is unfair in this world. I have a pretty decent job because I ran into the right people at the right conference back in 2004, where someone noticed that I might be able to do hard things with minimal effort (and fail at easy things, simultaneously). There must be thousands of people in my state who never got that "come to Yahoo, have a coffee" invitation & get plugged into a network of people who have kept me gainfully employed for more than a decade. I definitely had fewer challenges there because I wasn't an outright minority in the industry - I didn't have anything to prove beyond the performance.
  • itronitron 7y ago
    All things being equal, I'd rather hire someone that seemed nervous in an interview than someone that seemed relaxed, as the former is a good indicator that at least they are excited about the position.
    • rtkwe 7y ago
      That's gotta be a very noisy signal though. I'm nervous in any interview or public speaking thing whether I care much about the thing or not.
    • jameslevy 7y ago
      Nervousness is also often an indicator that you may not feel fully prepared. The best way I find to relieve nervousness in these situations is to be so prepared that there's really no reason at all to be nervous.
• lowdest 7y ago
  Current recommendations on discussion boards for job seeking are to complete 300 medium-to-hard Leetcodes in the 60 days before your interview. This is up from 200 1-2 years ago. If you won't do it there are many others who will.
  • AnimalMuppet 7y ago
    FORGET. THAT. NOISE. If I'm not going to do a 6 hour take-home assignment for you, I'm definitely not going to do 300 Leetcodes to "prepare". I've been doing this for 34 years. That's my preparation. Either you want what I've got, or you don't.
• ionwake 7y ago
  I will never forget my interview at the 2 best fashion houses in London. Both failed for what I still consider was a massive loss to them as I had all the skills they needed and more, but either management or the devs had no idea. Im not bitter for I earn much more now than I would have, it was just crazy to see the disconnect between management and programmers, in opposing ways. Fashion house 1: 2 guys sat me down and ask me to answer a question about some node.js code, which took around 25 minutes to get running on my laptop. Once it was they were hoping for progress, when it took me a few minutes to read through several config files ( over a hundred lines each). After 30 minutes they gave up and asked me what library I should use for a certain task. I said I had built alot of code in that domain didn't recall which library I used for that specific task. Suddenly I was walked out, but not before one of them took pity and tried to explain to me how, when you make a request you can write code which waits for a response from a server (async programming). I ofcourse thanked him and left. This was after I spent 3 years developing a successful networked engine in my spare time ( with a custom 3d engine bolted on it ) which enabled 20 asynchronous connections for a war simulation I built. They both had 30 minutes and hadnt thought of reading my CV or asking me about any of code / experience. Just drank their coffees looked at their mobiles and waited for me to somehow decipher their 10k line codebase. (Management had already OK'ed me but were not around for this part of the interview and blind to what was happening ( or the lack of it.) To this day I dont think the engineers even looked at my CV. Just thought I was some confused kid who didn't understand how basic network code worked. Fashion house 2 I also interviewed at their competitor, who had looked at my CV, lead engineer was about to extend an offer, CEO walked in, not knowing who I was, asked a casual question ( culture fit ) type, but I was unable to answer, I had trouble understanding what he was saying. Failed interview, but that is ok atleast I was not as offended this time as there were no quips. The icing on the cake, was that both companies had a 20+ engineering team, that relied on an app, which just framed a webpage. And I cant help feeling I know the reason why.
  • commandlinefan 7y ago
    A few years back I interviewed for a software architect position at a major US airline. I actually had experience with every one of the 20+ things they listed on their availability description, including the “nice to haves”, some of which was sort of obscure but I had actually done quite a bit of work with anyway. So they phone screened me, I got feedback from the recruiter that the phone screen went well and they wanted to bring me in for a face-to-face. I took a day off of my then-current job to drive out there and spend nearly a whole day (four hours) talking to them. I got word back from the recruiter that things went great, but a week later they asked me to come out for ANOTHER face-to-face, so I took ANOTHER day off to spend the whole day talking to them. I got feedback from the recruiter that things went great, and I should hear back from them any time. A week passed, nothing. I called the recruiter. He said he hadn’t heard back from them. Another week passed, nothing. I never heard back from them.
• avip 7y ago
  Good interview method is characterized by: 1. It hires me 2. It can be used to unhire others thereafter
• jdlyga 7y ago
  I've had some good technical interviews and some bad technical interviews. The worst I dealt with recently was the technical phone interview process for a FAANG company (not Amazon) that only provided a basic text editor (requiring me to tab over after every newline) for writing full working solutions to problems, and unhelpful and disinterested interviewers. This was a couple years ago, so hopefully it's improved since then. But it left a sour taste in my mouth.
• palisade 7y ago
  I once interviewed at a company that had you write a traveling salesman program where you were planning the shortest path of flights between cities. It was a take home test where you were given at least a week to complete it. I completed the test in record setting time (3 days earlier than most), mine was the only one that was fully documented with comments (no one else bothered to do this), they said I had the most visually stunning user interface (most were ugly or unusable; I even animated the plane flying between cities), the program came to the outcome in the shortest runnable time, out of all the submitters they said my program was the most optimized solution (not the best ever made, but the best submitted to this company so far), and mine was the only one that actually worked correctly and ran without flaws. They then proceeded to have me come in for the 6 hour interview in which they asked questions like, "Write a working hash table from scratch on the whiteboard." I got nervous and passed the question, they ended the interview early and rejected my application.
  • rcfox 7y ago
    I once interviewed at a company that had me write a couple styles of matrix multiplication in C as a take home test, as well as give a one-page description of a project I had done. The project I described heavily involved graph searches. Then I had a phone interview where they started off by commenting that I was the only one to include tests and address undefined behaviour. Then I had to write a piece of code to traverse a tree and add numbers, I can't remember what it was exactly, but I got nervous and messed up somehow. Then I waited for 2 weeks just to hear back that they wanted someone more experienced with graph theory.
    • mjevans 7y ago
      Expecting perfection on a white-board test is setting everyone up for failure. At best that's a large napkin exercise. Though having a failure, or a point where for whatever reason production is a bottleneck (if they happen to do it without obvious faults) is an opportunity to identify that either thing is the case in that section and move forward with how they'd react; what should be changed, etc. We're all still human; expect failure to happen. See what happens next.
• throwaway_a0f1 7y ago
  I genuinely don't understand what this industry is looking for in an interview process. Some background, about 2 years ago I started teaching myself to program full time. About a year ago, I felt confident that I knew enough to get a job, taught myself all of this leetcode stuff, and started applying. People told me that if I could crush leetcode, I'd have no problem getting a job. What they didn't say was how impossible it was to get an interview when transitioning fields. I was also told that people would look at my GitHub code, but considering recruiters spend about 15 seconds on a resume screen, this is more of a meme than reality. In the last year in Bay Area, I've managed a total of 2 on-sites with well over a hundred applications, all of them quite targeted. Maybe 8 companies total have engaged with me, and I have not missed a single one of these types of questions at any point in the process, yet it hasn't been enough. It seems that there are so few entry level jobs that that market is extremely saturated. I'm not sure how this industry expects to address it's serious man power shortage if no one wants to hire juniors.
  • lacker 7y ago
    I have not missed a single one of these types of questions at any point in the process The most likely problem is simply that you are getting questions wrong, but you don't realize it. Companies don't often give candidates whiteboard questions, have the candidates nail those whiteboard questions, and then drop the applicants.
    • throwaway_a0f1 7y ago
      I mean that's a fair take, and one I've tried really hard to examine, but I feel as though the questions have a very obvious answer and you either get it or don't. And to reply to that, no one actually gives feedback so you'll never actually know. Looking at your profile, you seem well suited to be able to evaluate this, so let me give an example from an interview I just had. Here's a problem and solution from the last interview I had: https://pastebin.com/LyVYqLv4 https://pastebin.com/LyVYqLv4
      • lacker 7y ago
• tictoc 7y ago
  Am I still hirable as a developer past age 35?
  • brunnsbe 7y ago
    Yes, your age would even be seen as a benefit if it correlates with your experience in the field of software development.
  • cr0sh 7y ago
    I'm 46 and still employed as an SWE - got my current position 3 years ago. The key is to not let your skills stagnate, and to always be playing with something new - even stuff that you may not think you'll use in your career. For instance, for the past several years I've been playing with machine learning with a focus on self-driving vehicles. Do I think I'll ever get a job working in that field? Not likely, but the skills I have learned may be useful down the line (and personally, I've been pursuing such an education for my hobbyist aspirations).
• ThrottleHead 7y ago
  No one wants to address the elephant in the room, and that's that "leetcode" or "codefight" tests have nothing to do with your ability to design and build complex systems of interacting parts. Why anyone puts a high degree of credence into these tests and whether someone can solve one in a high-pressure interview is beyond me. Give them a take-home assignment where they can develop something similar to what they would be at the company, and decide if they wrote efficient, elegant code that's easy to follow. Also, if you're self-taught and applying to a team of CS majors, may the force be with you. No one's more insecure than a CS major interviewing a guy who might have more development experience than he does.
• tombert 7y ago
  I've put a line in the sand that I won't do take-home projects anymore for anything short of a "dream job". They can be extremely time-consuming, and it's entirely possible that they'll decide that they don't like you anyway. If the project doesn't result in an offer, and if I don't really have a need for another "Roman Numeral to Arabic Number" converter, then the time is completely wasted.
  • deleted 7y ago
    [deleted]
  • TrackerFF 7y ago
    I mean, they can be time consuming - yes - but so can "grinding leetcode" for 3 months be too. Have you seen some of the study guides / roadmaps people make for FAANG interviews? I've seen people claim they've coded hackerrank / leetcode / CTCI questions for multiple hours a day, for months.
    • tombert 7y ago
      Well, I actually work for a FAANG company (not going to say which one), and I didn't have to spend hours a day for months to do so; granted, I'm a bit of a math/theory junky. EDIT: Also, at least with the Hackerrank for hours a day, it's not for any specific company. Getting good at these problems is useful for getting a job at virtually any big company. Contrast this to the take-home project, where (in order to make sure you don't just copypaste someone else's from the internet), they make these things kind of specific, making the transferability to other things substantially less likely.
    • NeverFade 7y ago
      Even if you do have to "grind leetcode", at least that gives you the skills to get almost any tech job with very small marginal investment. Once you get very good at leetcode-style questions, just apply anywhere and get an onsite with a one-hour interactive technical screen, that will also tell you about the sort of people and culture that employer has. Conversely, homework assignments can easily take 5-10 hours. There's a lot of desperate unemployed people out there taking 10+ hours for these tasks, and setting the bar really high. A busy professional can be hard pressed to invest 5 hours they can ill-afford coding this task after a full day at work, then get rejected because some unemployed applicants dedicated 20+ hours for the same task. There are also services that solve these tasks for you, so now you - a busy professional - are competing against hordes of people who do these tasks all day every day for a living. So you hard-scramble 4-5 hours to finish a take home assignment to apply to just one place (!), and then you send it in and get a meaningless rejection note. Sometimes you don't get anything at all. These are some of the reasons I'm never completing a homework assignment again.
• tbyehl 7y ago
  2-Column PDFs: Writing is broken.
• vrt77 7y ago
  Curious to know if anyone has had any remarkably good interviews? So good that you'd actually use the approach with candidates you're interviewing?
• vrt77 7y ago
  Curious to know if anyone has had a "good" interview? So good that you'd actually apply that approach to candidates you're interviewing?
  • lacker 7y ago
    In my experience, most people who are hired by Google or Facebook consider the interview process to be good, and generally approve of applying that same interview process to find new candidates. However, that set of people is outnumbered by the set of people who applied to Google or Facebook and got rejected.
    • shivawu 7y ago
      I was hired by these big company before. I don't consider them good. I just know how it works. Probably don't want to go through this process again, unless there's some amazingly good opportunities there.
  • cr0sh 7y ago
    I had one great interview once that worked out very well; it's only downside was the length of time it took. I went to the interview, did a sit-down back-and-forth in-person discussion about my past work and resume; the usual. No whiteboard. Then I was told I had to do a practical exam; they basically gave me a laptop (MBP with MAMP - this was for a PHP/MySQL position), sat me in a cube with the rest of their development team, and gave me a test to work thru. First half was just question-and-answer (multiple choice and t/f - maybe some written too IIRC). The second was to code up a simple CRUD app using PHP and MySQL. They said I could use any resource I wanted - google, etc. This was about 3pm, and I had until 5pm (quittin' time) to finish. During this time I was working in the area I would be normally working, among potential future colleagues, with all the office distractions normally found at this place. Oh - I forgot to mention where: Fender, in their marketing department. So - randomly - people would start to play amplified bass guitars, or a drum solo out of nowhere. At one point, someone rang a cowbell and stuck a triangle. Fortunately, there wasn't any artists being introduced, but that was a possibility too. Various people on the team came up and introduced themselves. Distraction galore! But that was how it was going to be - so that's how they tested you. 5pm rolled around, and they came by asked how I was doing - I let them know things were coming along well, but that if I had another 15 minutes I could get things more solid. They said, sure - take your time, we sometimes stay late - no problem. So I finished, and gave it back to them. Went into a separate f2f with the director of the department and some of the team, chatting about my experience and such. The SWE supervisor and lead SWE came over, shut the door - and basically made me an offer right there. I worked there for a couple of years before they did a downsizing and I had to "move on". But during that time, I found that this kind of test was actually very, very difficult for more than a few people. Some didn't even do anything - they just sat there. One guy sat for a few minutes, then got up and left, never to be seen again. Some would complete the first half of the practical, but completely blank on the second half. All of this, despite having a completely set up system in front of them, plus ability to reference the entire internet. If they didn't know PHP or MySQL, it wasn't for a lack of resources that they couldn't or didn't write anything... Then again - I've heard of people failing to write fizzbuzz, so... But overall - that was one of the top interviews I've ever had for an SWE position. I guess it was partly the practical testing, but also putting you "on the floor" to see how you'd fair in that environment (and yes, the whole instrument playing thing was a daily thing). I guess some people couldn't handle it. Others might've just not wanted to do the practicals feeling it was beneath them or something? And still others might have actually just "frozen up" for one reason or another - or really couldn't do what they claimed. For me, it was one of the easiest and relaxing interviews I had ever done, and I would do again - and would love to give a similar interview to someone, if I were in that position.
• jmharvey 7y ago
  I'm sure I'm not the only one here in a position where I can re-shape my company's interview process. And it's loud and clear in the comments here that people are unhappy with the status quo. So, if you were making a hiring process, what would you ask candidates to do?
  • carapace 7y ago
    > if you were making a hiring process, what would you ask candidates to do? Review code. It would be at least a few pages, in the language they would be working in, with a few bugs that you know of in advance. Depending on what the code does and the particular bugs you introduce you can get a pretty good idea of the candidates' comprehension of the things you need. (Bonus points if they find bugs you didn't introduce.) One problem with this is that both the code itself and the evaluation of the candidates review have to be done by sharp folk who know what they are about. Otherwise GIGO.
    • cableshaft 7y ago
      I'll second this. This is mostly a copy paste of my comment on another one of these interview topics: "One of my best interview experiences was exactly that. The interviewer handed me a printed out class and said "tell me what this does, any mistakes you see, and any little improvements that you think could be made." I got the job and later confirmed it was a class that was actually in the software I would be working on, not some toy class he came up with. He also asked me a handful of technical questions and had me go over some source code I brought in, but that was about it. At one point he even said, "I know enough to know you can do the job, but now I'm curious what you really know." And asked me some no pressure really low level questions. When I said I didn't know the answer to something he'd spend a couple of minutes explaining the concept to me. I walked out of that interview having learned a few new things about my field. A couple of them have stuck with me over a decade later. And the guy was a grizzled veteran who was the lead on some massive mainstream video games I pretty much guarantee you've heard of. He used to code them in Assembly, even. He's probably the most knowledgeable programmer I've ever met. I've never had anyone try going over actual code with me since, in probably a couple dozen interviews, and I don't understand why. It seemed very effective."
• shultays 7y ago
  I am surprised how many people here considers take home tasks as an "unpaid work". You are already doing other interviews with them which costs you time as much as an assignment does. Why it becomes a problem when it is a home assignment. Honestly I would take home assignment over any technical interview. Even if it will cost me 3x time. At least then I will be working in a relaxed state and will do my best, compared to an interview where anything can go wrong.
  • rightbyte 7y ago
    Interviewing is somewhat symmetrical in that the employer also wastes resources if they don't hire you. It's no cost to ask 1000 candidates to submit homework. Homework feels really unnecessary too. If the interviewer would like to see code I have written I have a USB stick full of old university assignments and some public projects on Github.
  • mjevans 7y ago
    Your take-home could actually be part of a useful result. A whiteboard or napkin test usually doesn't cross that bar.
• andrewstuart 7y ago
  Coding tests are completely useless unless the company doing the assessment can clearly explain up front their method for assessing the code. I did a coding test once that was organised, met the requirements of the test spec, was documented, included tests and in identified and solved an inconsistency in the test spec. The feedback from the employer "they didn't like your code" - right there is the point at which I realised that coding tests are, without a quantifiable, systematic assessment method, complete garbage.
• bazooka_penguin 7y ago
  Imo the industry should consider a more cooperative process that involves larger real world problems with the interviewer working with the interviewee to work through the problem, teaching them even, if need be, to get to an acceptable solution. Big tech interviews can already run almost a day long and the phone test is just a whiteboard lite. I feel like the face to face time is kind of wasted on an open ended examination format rather than trying to find out a developer's temperament, behavior, and openness in a real work environment where they will be expected to work constructively with peers. Given a lot of companies have separate design and behavioral interviews, with the former probably being close to my idea already. I just hate the technical beat stick that is the whiteboard test, feels like going up in front of the class in data structures and algorithms classes
• 11235813213455 7y ago
  As a fan of algorithmic problems and websites like leetcode, I'm totally fine with this kind of interview challenges, it's a good way to select candidates, and anyone can prepare for it
  • TrackerFF 7y ago
    But is it any good indicator on future work performance?
    • username90 7y ago
      Yes, not sure why so many believe otherwise.
  • shivawu 7y ago
    Being real, it's a good way to select people like you.
    • 11235813213455 7y ago
      I see what you mean, but totally disagree, the important is not necessarily to pass those challenges, if at least there are interesting ideas presented. You could say, why not giving Sudokus, or chess boards challenges to candidates? It's not totally bad either, it's just further from the context All this is not incompatible with knowing other engineering fields, networking, security, data structures, code patterns, which are indeed more useful in day-to-day work. Students are often selected the same way in exams, which won't really matter in their future job/life if you look at their content. But the process matters, school teaches you to learn mostly, like those small logical/algorithmic challenges trains you to think, visualize, reflect on data and more
• noego 7y ago
  I've read a million "hiring is broken" articles about software companies, so I asked my sister (lawyer) yesterday how the legal industry does hiring. She told me that even at the most prestigious and exclusive legal firms in the nation, the interview success rate is ~50%. That seemed staggeringly high, considering that Google's is less than 10%. So I asked her how these legal firms managed to pull off such a high interview success rate. Apparently, they only ever invite someone to interview, if they are already pretty sure they want to hire that person. And how does that work? They make no attempt whatsoever to judge your competency on the basis of interview performance. Rather, you are judged almost entirely by your resume - the "brand name" of the law school you attended, your GPA, and the "brand name" of the law firms you've previously worked at. If your school or previous law firms aren't prestigious enough, you won't even be invited to an interview. In fact, not only is the above a convention, it's often a firm policy. My sister once got a job offer, through very fortunate circumstances, at an elite law firm. But their HR department blocked her hire, literally because she did not attend a top-15 law school. Ironically enough, I've never heard anyone complain about legal hiring being broken. Perhaps that's precisely because legal firms don't even give most people a shot - they are filtered out entirely at the resume stage. I imagine people get far more agitated when they are rejected after an interview, as opposed to being ignored entirely from the outset. I'm personally glad to work in an industry where even the most exclusive companies are willing to give everyone a shot at the interview, regardless of which school they went to. Is hiring broken in tech? Sure. But it's completely dysfunctional elsewhere.
  • fatnoah 7y ago
    >Rather, you are judged almost entirely by your resume - the "brand name" of the law school you attended, your GPA, and the "brand name" of the law firms you've previously worked at. If your school or previous law firms aren't prestigious enough, you won't even be invited to an interview. Somewhat ironically, I took a brief detour into patent law after my first few years as a SW developer. I had a MSEE plus four years of software experience. I mailed 5 resumes to the biggest law firms in town (Boston). I got five interviews and 2 job offers. Salary was about 5% less than my current salary at the time, but they'd pay for law school and guarantee a job when you finished. There is an "in" but it's fairly unconventional.
• pascalxus 7y ago
  I think most people misunderstand why they were rejected. Most people interviewed are more than qualified for the job. I've interviewed countless people on phone and in person, and I rarely come across a candidate that's not able to do the job. The real reason candidates get rejected is simply this: 5 candidates get interviewed and ONLY 1 can get the job. This is simple math. No amount of studying on the part of the candidates, and no amount of interview hiring competence can avoid this outcome: there is only 1 Job. The reason for all this is simple: a vast oversupply of qualified candidates. As more and more engineers get pumped into the market, this problem will only get worse. You can see from the 2019 developer survey, the ratio of 1-5 year devs vs 5-10 years, indicating the number of senior devs is increasing very rapidly.
• gregrata 7y ago
  I wrote a book on this: https://www.amazon.com/dp/B07FJ6N8P1 https://www.amazon.com/dp/B07FJ6N8P1 (the book will be free tomorrow - would love for you to give me some feedback...) Lighter-weight then this paper - just my experience in using different kinds of tech interviews, and what I found that worked the best for my team and company. Some key points: - Interviews should be as close to what the candidate will do in the job - if they'll be writing a lot of code, that's just basic algorithms - on a whiteboard - then whiteboard interviews are perfect. If they will be doing a full project and interact with others as part of that project, then do something more like that (For me, that's a take-home - with an emphasis on the interaction part, and how they go about creating software... not coding). Treat it like a project, not an interview quiz question. - If doing the takehome, respect peoples time - it needs to enough be close to something they'd do in the job, but something that can be done in a handful of hours (and NEVER treat it like getting free work. I personally would love to be able to do a paid take-home, but haven't had the budget for it) The total expected time of the take-home + onsite should be able what they do for just a full on-site - Understand that not everyone will have time to do this. Have a backup (my backup is "Project Day", which is on-site, but still about creating software) - Try to do the same one for all candidates. At my last company, 80+ people ran though the same take-home. The team really started to get a sense of a good result and bad result.. and not JUST on code. What questions did they ask? How did they go about driving the project? What tools did they use? - I did catch a few people cheating (after 80+, the code was out there, so not hard to cheat). LOOKING at someone else's project for this was ok (if you read the book, you'll see why). Outright copying was not. Part of the process is a friendly code review after the project is done - if the candidate wrote the code, they'll be able to talk to it, and have ideas of how to improve it. If they can't do that and don't see to know the code, they probably didn't write it... which was painfully obvious for those that tried to cheat. Do what works best for your team and company. This worked best for me; I have yet to see whiteboard interviews be a strong indicator of someone being a great fit for a team, but I was able to build a great, happy, very productive team using this method.
• Renal 7y ago
  I refuse to do coding assignments for free and I think everybody should too as well. The problem I have with them is: 1) Malign intentions: You never know whether they are trying to: - Purposely waste your time. - Free consulting. How would this guy do this ?. - Data compilation. Let's see how a bunch of unemployed developers solve a particular problem. 2) Is too easy to reject a coding assignment based on subjective things since there are so many different ways of doing the same thing. 3) It is easy to cheat. You can easily ask/pay someone to do it for you. And the core problem is that is too easy to ask for coding assignments. Companies don't loose anything by asking you to spent a week doing the assignment.
• adamredwoods 7y ago
  After taking take-home or timed coding exercises from these major companies, I'm becoming more and more depressed, compounded by the lack of any constructive feedback. I'm not sure all these code tests are EMOTIONALLY sustainable for a developer.
• aussieguy1234 7y ago
  Given the choice between a technical or culture interview, I'll take the technical one any day. For those that complain about them, are you really as good as you say you are? I support coding challenges, as long as they're reasonable and won't take too long to complete. If you'd spend an hour doing an interview, wouldn't it be reasonable to spend the same amount of time on a coding challenge? The best ones are done during the interview. No more time wasted.
• chovy 7y ago
  https://thedailyshitter.com/heres-a-rediculous-interview-question-i-got-today-they-gave-me-48-hours-to-complete-how-nice-of-them-s/ https://thedailyshitter.com/heres-a-rediculous-interview-que...
• icedchai 7y ago
  Up until the 2009 or so, tech interviews weren't like this. You'd show up, get asked a few easy questions, get a feel for culture, BS a little, and that was it.
• shivawu 7y ago
  I'm surprised how much people hate take-home projects. Companies must've done this very wrong to piss so many of us :) My take on the comments: - We know whiteboarding and algorithms are bad. - Take home assignment is better, but very few companies do this right. - If doing wrong, the experience will be far worse, make you never want to do it again. - The reason is, A. lack of transparency; B. unbalanced time commitment, candidate vs company On the other hand, I think we should give more mercy/time to take home assignment. We know it's better, we know it's in the process of improving. If we don't say no to algorithm, it'll just be there forever.
• deleted 7y ago
  [deleted]
• jackcosgrove 7y ago
  I have never been asked an interview question where I am expected to sanitize noisy real world input, report meaningful errors to the user, or create a few classes that interact in a SOLID way. (I have been asked what SOLID stands for.) Maybe these questions are asked but unfortunately I haven't come across them. I have been asked many times how to solve crazy, weird problems in what is the equivalent of a couple of functions. The first kind of test, which I have not been given, is highly relevant to my daily job. The second kind of test, which is administered in every single interview, is relevant maybe 1% of the time in my job. I try to keep this in mind when I am on the hiring side of the table.
• est 7y ago
  Hiring is no longer about qualification, but a bar for revenue distribution
• llamataboot 7y ago
  I got roasted for this article last week, but I'll post it here because its completely relevant. I think the entire dev hiring process is broken. Not because I had a hard time, I think I had a totally normal (and slightly easy, because was okay where I was while looking) time and ended up getting a large raise and ending up somewhere I love...but I've been on the hiring side as well and I think hiring signals are weak and cargo culting is rampant. It's telling that I can't think of many other fields outside of academia that require so much time interviewing to hire. https://medium.com/swlh/brief-thoughts-on-getting-hired-as-a-senior-coder-94f38998bb08 https://medium.com/swlh/brief-thoughts-on-getting-hired-as-a...
• iMage 7y ago
  I have yet to enter the workforce, but as someone who has done a bit of programming for fun and really liked programming-interview type websites I think I'd be decently prepared for a whiteboard interview. The thing is, I have barely any (read as: no) software engineering knowledge and don't know how to build any sort of programming product.
• unnouinceput 7y ago
  Before going freelancer route I was like everybody else. Send resumes, go to interviews when invited, get whiteboard crap. Usually it resulted in 50% times invited to interviews and getting offer 75% off those interviews. Then a hard time came (2000's EU crisis) and the market was drying, with hundreds of applicants even at small firms that were hiring. So I changed the way I was going about. Whenever a hiring was happening instead of sending a resume to the office@whatever.com and hoping for the best I went proactive and digged further for a phone number, called about their address and went in person there pushing until I was in front of a technical leader that was in position of power to hire. I avoided HR entirely and when in front with that tech guy I asked for real problems that they either have or had and to show him my way of thinking hunting for bugs in front of a PC. This resulted in 100% hire and I kept doing this for the next several firms I worked for. I got to work for Alcatel and Siemens this way. No HR drones, no whiteboard, just good old coding in front of a competent future co-worker/team leader. Alcatel tried to kick me out with security. I went out on one door, entered another in next 2 minutes. I argued with them, I voiced that I will keep doing this until I get a tech guy to interview me. When head of HR came eventually and told me police is on the way I said "so until they arrive can I get that tech guy to do the interview? Because I will pass it in 15 minutes, that's how awesome I am". That line made him reconsider me and guess what, I was hired. My point is if you know you can do the job just push it, regardless of obstacles. Siemens punished me for this type of behavior by interviewing me for 8 straight hours. No bathroom breaks, no eating or drinking this time, just interview with one manager after another, all with hiring power. First of them was actually the head of the entire HW department and he made sure I understood what is going to happen. Later on I found out who he was, and on hierarchical ladder hes was the boss of the boss of the boss of my boss (team leader -> immobilizer division -> BCM group -> HW department). After 6 hours came a group leader (BCM - https://en.wikipedia.org/wiki/Body_control_module https://en.wikipedia.org/wiki/Body_control_module) that was actually in need for guys in one of his teams and I finally got to coding part and at the end of those 8 hours I got a contract to sign and to start next Monday (this was happening on Friday). Their punish made sure that I was actually that good as I was bragging at beginning and that I was willing to do the grinding required for the job. This way I got to work on immobilizer division (this was an embedded SW position). My point is that if you brag, make sure you also can do it, as harsh as it can be.
• rs23296008n1 7y ago
  There is no talent shortage except for corporations favoring low effort hiring using low effort puzzles. They see people as cheap so why bother investing in hiring. One person is as good as another, right? That first question in the paper is an indicator that I literally don't want to work there. Their culture is probably toxic, full of bro coders and likely infested with poor time management and politics. That's my rule of thumb and I'm sharp and harsh since I've seen enough to make this assertion and won't even negotiate on it. The reason they showed me a puzzle is they want interviewing cheap. But I'm not cheap. And I'll see right through it and just see a messy company. No thanks. I have too much experience with messy companies and can spot them from a single question. I'd rather work with professionals with real problems and no time for nonsense. Google etc can't hire someone like me because I interpret stupid puzzles as an indicator of poor work environment. I don't write this out of some sense of superiority: I'm just tired of the correlation between puzzles and environments that are just plain bad. The mentality of people who like pointless puzzles is not one I'd like to work with. The irony of my job being based around production issues that involve uncertainty and require novel solutions is not lost. I work with smart people. Do people on the outside really think we would play with wooden or toy puzzles because we"re "technical?" None of us do. I get my contracts through referrals so interviews are mostly now just "hey are you available in a months time and can you also do X" followed by "do you have a github for this kind of work?" Then a quick 15-30 minute interview with no idiot puzzles. Mostly to expand on experience to explore some portfolio piece. Big corporations can't do this kind of interview. Their hiring is broken. That is why they have thousands of candidates and still shout about talent shortages. I've been interviewed a few times and I usually get to a point where I say "sorry but I'm not happy with the environment you are presenting" then I politely cancel. I can't be alone in this experience. I'm a blip in their radar that rapidly fades away. They probably see me as poor fit. Good. Lower your tolerance. Raise your expectations and actually judge them back. They are presenting their corporation in the best light possible. So using puzzles is their best light. Ouch. Any code or project example that an interviewer presents to you are demonstrations of how their best practice development process works. Best or worse or an examination or discussion of why not either way. Evaluate them. If its "from scratch" then they simply do not use libraries and suffer from "not invented here". If its not commented, they hate maintaining code and they want you to fix their mess. Is the time limit too short by your experience? Then they expect miracles and likely won't pay for it either. What about a 8 hour home project as part of the pre-interview that you could probably sell? They expect free labor and no compensation for it. These are assumptions but when firmly applied your opinion will be suitably sharp enough that puzzles no longer seem so reasonable. Judge the interviewer on what they present. That code will be production ready or they will ask why it isn't. Each question is an example of how they specify real problems. Judge them on their method. Is there enough information? Why not? How is that acceptable? The interview process is two way. Anyone who says otherwise is someone you want to avoid. They are likely toxic. Don't work with or for anyone who thinks interviews are one way. If the process is not win-win then avoid because other nasty surprises are hiding in your near future. My personal experience shows genuine horrors await if you stay. Why is that particular technical question so bad? Because it shows the answer will not be production ready and the culture around it accepts that. The design specification is indicative of bad design. They even showed the shape of their preferred answer. Consider the implications: what was missing from the question? Why would I care about what was missing? What is the maximum run of numbers it can search? A million numbers? How often does this code run? Is it part of an interactive flow? I hope the user has coffee and a lot of patience. When does it time out? No answer in the design. It never does because it is not specified. The interviewer likely won't even answer that question. No context and you now seen as incompetent for asking. Instead you can ramp up the assumptions: So the entire system hangs as it searches. You could also say that the company is likely bad at operations and they don't specify their problems clearly or thoroughly enough. They have multiple mysteries in their systems they just can't solve. Systems fail for no reason and asking why is "being difficult". What a painful place to work. No thanks. I can make these assumptions because the question they showed me is seen by me through the lens of a production example. An example of a problem I'd likely see if I accept their contract. This is an inter-view. Two views. I expect them to show me a serious example of how they would frame a problem and how they would specify the preferred shape of a solution. They didn't show me a toy problem because they wouldn't want a toy solution. That would be disrespectful: so what was presented is a serious question to be solved. It is to act as a demonstration of what I would be presented with and then they want to see how I'd meet and solve it. Now look at the question again. Its so simple. Just answer it. Ignore everything. It will be fine. Now clean up our codebase. Have fun with all those puzzles. We need it fixed in 30 minutes, all 200000 lines. Oh well. Back to work. I've got money to make and this system is 1.5ms too slow, and that is costing the business 100k per month in lost opportunity. How would I solve this? Perhaps a bubblesort algorithm I saw in an interview question awhile ago might help? Thats fast and best practice isnt it? Perhaps I could write it from scratch... on a whiteboard. With only 5 minutes. Sounds great doesn't it? Should a company bet their livelihood on that kind of decision making? Interview carefully. You could end up working with these people.
• dep_b 7y ago
  I had quite a nice interview for a contractor position building a larger fairly well-known mobile application and they surprised me by giving me one of their stories and asking me to ask questions about it (like: "where are the comps?", "is this also supposed to work offline?" and so on). That was so refreshing.
• deleted 7y ago
  [deleted]