52 ms·

Ten years of experience, still failing phone screens

• vanusa 5y ago
  This post ought to be the final nail on the coffin of the cult of leetcode/whiteboard style inverviewing. Just looking at this guy's repo and his writing style -- you'd be foolish to waste his time or yours on leetcode-style hazing. Your conversation should be strictly high-level. If you must, pick a file at random from one his larger projects, and ask a few straightforward quetions ("I'm new to Go - can you explain why I would use this datastructure here?") just to make sure the repo isn't a copy of someone else's, and he isn't outright trolling you. Apologizing as you're doing so, of course ("Sorry, but do you mind if I ask a silly-sounding question or two about something in your repo?"). That's all you need to do. Most candidates won't have work samples that are quite as slam-dunk, of course. But still, your own "smell test" can save you tons and tons of time (and the candidate, agony). It's really, really hard to fake one's way through questions like these -- and really easy to tell if someone is trying to do so. Put another way, your basic mindset should be: "Trust, but verify". Not: "Joel Spolsky wrote that post 20 years ago claiming that 99.5 percent of all candidates are utterly incompetent. Therefore I need to torture this guy until he confesses." At least as far as answering the "can he/she code?" question is concerned.
  • redis_mlc 5y ago
    > This post ought to be the final nail on the coffin of the cult of leetcode/whiteboard style inverviewing. Looks like he has ADHD. Maybe somebody with more time can go through his blog post line-by-line and figure out what's going on. Most of my Coderpad stuff compiles and runs the first time, so I don't use his incremental test method, or see a need for it. Maybe he learned programming on heavy-weight IDEs and got trapped mentally in those?
    • MrStonedOne 5y ago
      So a screening system that only allows devs with your writing style in is valid why? I'm just like them, only my ide is notepad++. My code never compiles on first attempt, and never runs correctly on the first attempt.
      • disgruntledphd2 5y ago
        If my code compiles and runs correctly the first time, I spend an inordinate amount of time looking for bugs in it ;)
    • kevinburke 5y ago
      I use Vim, it's just different learning and development styles, I think. I’m very capable of focusing when there is a lot of money on the line.
      • redis_mlc 5y ago
        Thanks for the followup answers. I also use vi (no syntax/color highlighting, no plugins, original vi commands only.) I think you should talk to some other developers and see what's going on with your ability to focus. (I'm one of the top application developers in a particular language and can actually think in that language, so that level of familiarity helps me.)
    • vanusa 5y ago
      Looks like he has ADHD. That sounds ad-hominem. I found the post perfectly readable. Maybe he learned programming on heavy-weight IDEs and got trapped mentally in those? Maybe he just thinks differently than you do? His body of work is not suggestive of someone "trapped" in an IDE or other dysfunctional midset.
      • redis_mlc 5y ago
        > That sounds ad-hominem. I found the post perfectly readable. I wasn't referring to his blogging style, I was referring to his description of his "struggle" development process. > Maybe he just thinks differently than you do? He certainly does. He might want to find out what's going on by talking to other developers. One of his comments in this thread says he uses vim, so it's not an IDE issue.
    • willcipriano 5y ago
      I generally write some naïve code and if it doesn't work, get out the debugger and fix it from there. I can work a lot faster when everything is laid out and I don't have to guess about what the data structures are going to look like. If it's performance sensitive like some tests I've seen, I'd use a profiler. I often use the jetbrains find and replace tool, as well as the search tool, I also like that I can click into the source code for libraries that I use, so I don't have to guess about the interface or implementation. Stuff like coderpad takes away a good portion of my tools that I would use day to day, I taught myself to code in notepad, but I purchased the full suite of jetbrains tools years ago so I wouldn't have to fumble around with inferior tools.
      • google234123 5y ago
        A profile can’t suggest a better algorithm.
        • GoOnThenDoTell 5y ago
          and a better algorithm can often be over-engineering, so it needs context in the question-giving
        • nitrogen 5y ago
          A profiler will tell you whether a O(n log n) algorithm with a very high constant factor is better or worse for your situation than an O(n²) algorithm with a very low constant.
    • duxup 5y ago
      His description of how he works sounds heavy weight…by his own design to work efficiently. That’s a good thing.
    • EdwardDiego 5y ago
      A lot of devs have ADHD.
      • Kye 5y ago
        There's even a subreddit: https://www.reddit.com/r/ADHD_Programmers/ https://www.reddit.com/r/ADHD_Programmers/
    • zaptheimpaler 5y ago
      Maybe you're trapped in mentally simulating a compiler and those of us with good dev setups can dedicate brainpower to other concerns?
      • wiseowise 5y ago
        It's the other way around, from my experience. People who can write a program without any setup can solve it even on paper, while people that are hardwired to specific setup or IDE quickly froze when you ask them for something.
        • sofixa 5y ago
          > People who can write a program without any setup can solve it even on paper, As someone who had courses in C on paper, i can only say that it's a colossal waste of time. Tooling exists to make lives easier, gain time and productivity, why avoid it? It'd be like saying only the farmer who can do everything by hand without any tools increasing their productivity is a real one. Or an accountant refusing to use Excel/calcuators/ERPs and writing everything on paper. And before anyone jumps to conclusions, i often write small scripts with vim with a minimal setup, but when I'm doing anything complex i prefer to use an IDE
          • wiseowise 5y ago
            > It'd be like saying only the farmer who can do everything by hand without any tools increasing their productivity is a real one. Or an accountant refusing to use Excel/calcuators/ERPs and writing everything on paper. You're trying to map manual work onto engineering. And absolutely I'd rather work with accountnant who can write me on paper without Excel/calculator/ERP his logic. It's like you're being obtuse just for the sake of the argument. Someone who can clearly express themselves without specific medium, be it paper, IDE or whatever is strictly superior to someone who is tied to one specific medium.
            • sofixa 5y ago
              When one of the mediums actively helps and avoids small human errors, I'd prefer the person knowing using it instead of sticking an old and imperfect method out of pride.
  • nijave 5y ago
    Im not a huge fan of leetcode or work samples but on the receiving end it weeded out a huge number of bad candidates. We'd get tons of copy/pasted together infra as code from top Google results that wasn't even close to runnable (usually being close to runnable with a few small bugs was a good submission and runnable with no bugs was a great submission)
    • vanusa 5y ago
      On the receiving end it weeded out a huge number of bad candidates. Along with (as was the main point of the original blog post) probably quite a few false negatives, Like the author of that post, for example. Meanwhile, you can achieve the same filtering benefit by far less obnoxious and more accurate means (a cursory glance at their repo, fore example).
      • kevinburke 5y ago
        People say this but then they reject answers that e.g correctly code the brute force solution or they don’t provide an algorithm to code for, so it’s not just “can you code,” it’s can you find the optimal algorithm and also code it, and usually the algorithm isn’t trivial or one you’d ever run into at work.
      • wiseowise 5y ago
        I'd rather filter out good candidate than let bad in. It's a domino effect. You let one bad, he will hire more in the future.
        • klipklop 5y ago
          I always hear this but never seen proof. If they are bad how do they get into a position that lets them make hiring decisions? Everyone likes to think they are the good candidate and not the bad one that slipped through…
          • wiseowise 5y ago
            > If they are bad how do they get into a position that lets them make hiring decisions? We have flat hierarchy. Just volunteer to interview because your voice is on the same level as others.
  • deleted 5y ago
    [deleted]
  • aydwi 5y ago
    Your mention of Joel's post made me curious to find and read it. I assume this is the post in question: https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guide-to-interviewing-version-30/ https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guid... I'd say much has changed since he wrote that, and even for the time it contains some odd advice which he tries to force down the throat of the reader, but I'd be more interested to hear other's thoughts on the article.
    • rightbyte 5y ago
      To Joel Spolsky's defense, leet code questions where probably a great idea for him, when it was not an industry wide thing. He also had this, what seems to me, nightmarish, dev. speed and progress estimation tracking app he made. I don't remember what blog post, but he described it and jokingly wrote that Lisa needed to get the speed up, or something. Fast forward to today and it is a predecessor to our agile nightmare. But I don't think that was his intent.
      • chiph 5y ago
        I remember when he made that post ("Evidence Based Scheduling"), and was also appalled. Yet, here we are today and programmer velocity is a now a measured metric in Agile. https://www.joelonsoftware.com/2007/10/26/evidence-based-scheduling/ https://www.joelonsoftware.com/2007/10/26/evidence-based-sch...
        • rightbyte 5y ago
          Oh ye thank you that is the one. The general problem with Scrum like velocity tracking is that devs will start to lie to hit the estimates to keep the commissars of their backs. The best liar gets the straightest graph. And as devs learns to lie, you get the impression of improved estimation. "Some developers (like Milton in this picture) may be causing problems because their ship dates are so uncertain: they need to work on learning to estimate better." I mean ... why God. I don't know but maybe poor Milton has the hardest tasks, does not cut corners or what not. Brandon seems to "get it" and has silly narrow error range - I wonder how ... (I am not bitter. Pinky swear)
  • treis 5y ago
    >Just looking at this guy's repo and his writing style -- you'd be foolish to waste his time or yours on leetcode-style hazing Perhaps it's just me, but I took a look and I'm not convinced. Nothing jumps out to me as overwhelming proof of programming ability.
    • bogwog 5y ago
      Can you explain why? To me it's obvious that this guy knows how to code, and he's probably better at it than most of the engineers I've met.
      • treis 5y ago
        Hard to explain the absence of something other than it's just not there. The list of projects/accomplishments are fine but the reality is that people lie about stuff like that. I poked around their recent GitHub commits but it was mostly bug reports. Nothing really that points to being obviously great at coding. I see that on paper they're a great candidate, but the reason that companies do these tests is that often the candidate doesn't measure up to the resume
    • vanusa 5y ago
      Nothing jumps out to me as overwhelming proof of programming ability. Are you suggesting that leetcode tests provide "overwhelming proof of programming ability"?
      • sangnoir 5y ago
        Not gp, but obviously yes. I'm yet to meet someone who can pass a leetcode-style interview with sober and conscious interviewers, but can't code. Have you? Leetcode and coding ability is an A -> B but B -/-> A situation: failing leetcode doesn't mean you can't program, but the reverse is absolutely the case. Leetcode can't filter out other potential issues that may impact success (e.g. poor anger management, or poor judgement).
        • vanusa 5y ago
  • creamytaco 5y ago
    Your post ought to be ample proof that subjective opinions (like the one you display here) are not solid grounds for hiring decisions. When looking at this person's Github page, I -unlike you- see a vast number of trivial projects that can best be described as regurgitations of other people's work. Even worse, if you actually look at his first pinned project (https://github.com/kevinburke/nacl https://github.com/kevinburke/nacl), you'll see that it is nothing but a wrapper with trivial changes/updates... an anti-project. In the end, I see code that provides the illusion of competence but, when actually inspected, is actually telling me not to hire this person. The fact that pretty much anyone can declare oneself "a software engineer" today and easily present a veneer of competence together with powerful financial incentives, makes it absolutely necessary for any serious engineering team to have objective measures in place in order to evaluate candidates. There are so many terrible engineers out there (and some even slip through the cracks and land at places like FAANG) that doing anything less is irresponsible.
    • vanusa 5y ago
      I never said you should just hire someone on the basis of their repo. But rather, if you're looking for a basic smoke test which can answer the question "Can this person actually code? Do I want to spend more time engaging them?" -- there are better ways to do that than expecting them to cram on a list of algorithms to recite over the phone. Like looking at an actual work sample. The fact that you looked at this work sample -- and came to your own conclusion about whether they would be worth engaging -- validates this very simple and basic point. Which is your call of course. He may not meet your bar, but it would be absurd to say this guy can't code, and hasn't been around the block in terms of general CS concepts. That said -- my own subjective opinion is that you're being exquisitely savage in your assessment of his NaCl implementation. Yeah, it's wrapper -- like it says in the Readme, and like a lot of working code out there. It's a pretty established way of solving a problem, in fact -- in some cases a very efficient and elegant way. It's not the same thing as writing 20k of primitives from scratch, of course. But that's not what he's presenting it as. He's not saying it's a "tour de force". He's saying "I think this shows we can talk about other things besides FizzBuzz". And then other things you're like saying... like "an anti-project"? Wow.
• Justsignedup 5y ago
  I have 15 years of experience, and seem to woo teams every time we do screening calls. Could be how he describes the problem. Most of the time during code screens they don't want you to perfectly solve it. Talk it out. Someone who feels that perfect or bust is the only way to go will fail most of the time. Idk feels like something is missing. He's right, feedback loops suck. Question is... Can he practice doing a phone screening with a friend? Does he know anyone who interviews? Does his current job allow him to interview or sit in some? Just being part of it can give great interview experience. Around 10 years of experience is when I learned a ton of interview skills. Interviewing is indeed a skill in itself.
  • thr0wawayf00 5y ago
    > Talk it out I personally hate this approach. Solving programming problems requires my full focus and vocalizing while trying to think is a challenge (partially due to my stutter). I can either focus on communicating clearly and professionally or I can stfu and code, not both. I’m happy to solve a problem silently and talk about it after I’m done, but I won’t do a phone screen that asks me to word vomit in the middle of coding.
    • xyzzy_plugh 5y ago
      How do you feel about collaborative problem solving? A big reason talking-it-out is popular is because it provides signal on your communication, problem solving and collaboration skills. If you sit there for 30 minutes banging out a solution in silence, I get a bit of signal. If you sit there for 30 minutes in silence doing nothing, then you're stuck and you've failed the interview as I didn't get the opportunity to assist. Talking through is so important.
      • soneca 5y ago
        In every real world work problem that is solved collaboratively had some time before where people understood the context and the problem by themselves before. At least they know the codebase, the business goals, the colleague. There is no situation where a boss call two random engineers, throw a completely new problem at their hands and ask them to solve it in 45 minutes.
• properdine 5y ago
  I conceptually like the idea of dropping coding screens, etc - but how do you objectively identify what you're looking for in a candidate without adding bias to the process? I.e., at least with a coding question, you can set up objective criteria. If you ask someone about their work, it might be a good experience but you're also setting yourself up to bias towards people who talk/think like you.
  • autarch 5y ago
    If you really want to test someone's coding, let them do some coding in their own time with their own tools and send it to you. This isn't ideal, since it can be time consuming, but I think it's more humane than live coding in some weird environment.
    • nawgz 5y ago
      I would argue that using less of someone's time is strictly "more humane" than using more of someone's time, because an individual's reaction to a situation is... individual
      • tfehring 5y ago
        There's no reason an asynchronous coding assignment needs to be more time-intensive than a synchronous coding interview - that's the convention but it's not a necessary one. Lots of companies do 4 hours of technical interviews, it's not hard to come up with an effective programming assignment that takes less time than that.
    • wiseowise 5y ago
      This is subjective.
      • autarch 5y ago
        Maybe the best option is just to give people a choice.
  • 5y ago
• thr0wawayf00 5y ago
  One thing I realized recently while interviewing candidates at my company is that it’s one of the few opportunities that individual contributors like myself have to exert significant power over someone else, and not everyone is prepared to handle it well. Recently, we had a candidate come through that wasn’t a good fit for us (he claimed to be a cypress expert so we asked him to set cypress up in a dummy react repo and he floundered the entire time). One of my coworkers took some pot shots at the candidate, being deeply critical and rude, cutting the candidate off mid-sentence, etc. I was honestly embarrassed to be on the call and I thought it reflected poorly on my company. I’d never seen my coworker act like this before and it changed the way I felt about him. I wonder how much of the leetcode interviewing culture is rooted in this desire to dominate candidates, since ICs rarely have opportunities to wield such power over others.
  • civilized 5y ago
    Those ICs are either sociopathic or they're channeling the sociopathy of their managers.
    • ryandrake 5y ago
      They could just need training and feedback. A lot of places just throw any rando engineer into an interview with no coaching on how to behave, how to set guide rails for the candidate, how to empathize and pace the interview, what the evaluation criteria and rubric is. And then after the interview, the person has no idea if he conducted the interview properly. Totally open loop. Just yeet him at candidates untrained and then wonder why he can’t interview effectively.
      • xyzzy123 5y ago
        I've been that person :( I still cringe when I think back on some of the early interviews I did.
        • ushakov 5y ago
          at least you acknowledge your past mistakes and learn from it some people don’t
• nasalgoat 5y ago
  I have 25 years of experience and I spent a year looking for a job, getting rejected after complex, time-wasting tests and endless voice interviews that went nowhere. At one point I had to take a cognitive test which I actually failed. I eventually found something but it was really discouraging there for a long time.
  • ryandrake 5y ago
    23 years here and at this point I consider interviews to be 1d100 random dice rolls. No matter how much you prepare there is no way you can predict how sensible the interviewers are. I figure just deal with it and interview more. If each interview is 1% independent chance of getting an offer, and you interview 50 times, you have a 40% chance of getting an offer.
    • nasalgoat 5y ago
      You're right, it seems totally random. For one they had the Scrum Masters interview me and they felt I didn't have enough scrum experience. For another I had to try and compile a video encoder on a three generations out of date VM and it took all day and I got $100 for my time. Madness.
      • kafkaIncarnate 5y ago
        What was that interview for? That seems like an odd interview... What software were you compiling, ffmpeg?
        • nasalgoat 5y ago
          Some other ffmpeg knock-off. System admin work.
  • sneak 5y ago
    Companies are really bad at interviewing. They toss the task to programmers and engineers who have never been trained in it, and expect them to not suck. The best way, as always, is to connect with people you already know and have them short-circuit the broken process via existing trust.
• autarch 5y ago
  I really love those suggested questions. I made a note to come back to this next time I have to do some interviews.
• pengaru 5y ago
  It's tricky to interview people lacking experience, but with >=decade of experience just do deep dives into past projects. You're basically talking to one of if not the authority on whatever it was they worked on, let them tell you all about it, down to the weeds. If they can't, then you've probably got a problem.
• ushakov 5y ago
  at this point of my career i straight out refuse technical/coding interviews i have a GitHub account with 7 years worth of contributions, multimillion dollar exit, projects online and previous senior roles on my cv if they still don’t trust me to do my job, the one i’ve provably done about a decade, their loss nowadays it’s easier to find high-dollar consulting gigs than deal with dysfunctional hiring processes advice: get jobs from people you know
  • zimmertr 5y ago
    I've been starting to refuse 4 hour technicals myself and they all immediately drop me. I don't have your seniority but I have some. As well as a powerful online presence across Github and LinkedIn. At what level of seniority did you start doing this and what is your success rate?
    • ushakov 5y ago
      they drop me too, but those companies are not worth working at to begin with they’re not interested in hiring employees, their interest is to get candidates through the loop and to see you fail this is fine when you’re applying to FAANG, but a terminal sickness when the company is barely known rather than spending weeks on interviewing, i’d suggest making a open-source contribution or reading a book the companies, especially startups have a bigger problem than you - they need to show the growth so they can attract more investors. Therefor, if they’re not getting people, they have harder time growing. If they see you as a potential candidate, but you refuse, they’ll bend their back over backwards
    • eckesicle 5y ago
      There's not really a seniority level where this happens. The outrage around the technical interviews shows a lack of understanding for the situation companies face when hiring. The reality is that something closer to 99% of the pool are applying for jobs they're not qualified for (not the same as saying 99% of developers aren't qualified - there's extreme survivorship bias in the pool). At company X we would hire ~1/400 applicants who applied, and about ~1/20 referrals. At a smaller company I worked for we hired perhaps 1/200. The thing is, many of these applicants have five to ten years experience (some at FAANG), but can't code at all. It's simply not possible to trust anything on a CV without verifying it. How do you verify this at scale? A pair programming exercise. Now the training of most interviewers is often poor, but it's far better to go down this route than the HN alternative: hiring without technical screening.
• adamzerner 5y ago
  > I'm not fast at reasoning about code, and I often make trivial mistakes just trying to get a "first draft" of a program out. If I get behind or the interviewer starts interrupting to ask about the bad code I'm writing I get very stressed and have trouble both listening to the interviewer and trying to address the issues with the code. Sounds to me that the author likes to program by "sketching". I do too! Paul Graham recommends this in Hackers and Painters. > For example, I was taught in college that one ought to figure out a program completely on paper before even going near a computer. I found that I did not program this way. I found that I liked to program sitting in front of a computer, not a piece of paper. Worse still, instead of patiently writing out a complete program and assuring myself it was correct, I tended to just spew out code that was hopelessly broken, and gradually beat it into shape. Debugging, I was taught, was a kind of final pass where you caught typos and oversights. The way I worked, it seemed like programming consisted of debugging. > > For a long time I felt bad about this, just as I once felt bad that I didn't hold my pencil the way they taught me to in elementary school. If I had only looked over at the other makers, the painters or the architects, I would have realized that there was a name for what I was doing: sketching. As far as I can tell, the way they taught me to program in college was all wrong. You should figure out programs as you're writing them, just as writers and painters and architects do. On the other hand, as the post describes, interviews are geared towards a more waterfall-y approach. I find this frustrating as well, but I think that there is something really important to keep in mind that this post misses, and that most conversations about coding interviews miss. The question is whether something is _predictive_ of job performance. For example, consider the question "What is your favorite number?". Imagine that the larger the answer to that question, the more likely you are to perform well as a developer. You might object "But I'm never doing anything relevant to my favorite number on the job!". IMHO, it doesn't matter. The goal is to predict who will perform well on the job, and if having a large favorite number does this, it should be incorporated. Now consider the question of how well you perform on waterfall-style interview questions. Like "What's your favorite number?", it isn't something that you will find yourself doing on the job. But that isn't the right question. The right question is whether or not it is predictive of job performance. Of course, it seems unlikely that "What is your favorite number?" would predict job performance. And it seems unlikely that if you never code in a waterfall-style on the job, that coding in that style during an interview would predict job performance. But maybe it does. I'm skeptical, but who knows. More importantly, I think that this is the question that needs to be asked. And without strong data, it's hard to be too confident in the answer.
• dkarl 5y ago
  > I often make trivial mistakes just trying to get a "first draft" of a program out In my experience, it's helpful to add simple tests as you go. I have done some live coding tests in Python recently, which I'm not super familiar with, and the first couple I did, I made a lot of trivial errors that caused my solution to fail until I went back and cleaned them up. Luckily the interviewers kept their mouths shut while I was coding, and I was able to clean up quickly afterwards, but I could tell it wasn't a great look to say, "Okay, I _think_ this solution is correct," only to have it flame out spectacularly. After those first two, I started writing simple tests for everything I did. Not only did it avoid embarrassing fails when the solution was supposedly complete, not only was it quicker overall, but every interviewer I've done this with has commented approvingly about it.
  • kevinburke 5y ago
    I address this in the post and part of the problem is that this is more difficult on Coderpad, and also interviewers (n=~8 out of 10 or so) discourage writing tests.
• pugworthy 5y ago
  > Most phone screens involve implementing some fairly complex algorithm3 in one or multiple steps on Coderpad, an online text editing tool Well OP, you lost me there. That's not my approach interviewing, nor is it what I've experienced.
• gilbetron 5y ago
  Interviewing is really tough. The OP replaced some coding questions with other questions and if he were to interview a bunch of people with them, we'd get another set of blog posts complaining how ridiculous his interview questions were. "Why is it bad to write a file to the disk one byte at a time?" What are they interviewing for, low level disk experts? "Here's a stack trace from an open source project, can you tell me what went wrong?" Oh sure, print-based debugging is awful, you just have to read stack traces from unfamiliar projects in the blink of an eye. "Here's a CRUD app, copy existing code patterns to implement a new CRUD endpoint" Ah yes, the reductive "everything is a CRUD app" - this interviewer doesn't understand that most applications don't fall under the simplistic "CRUD" moniker!!!!
  • EdwardDiego 5y ago
    > What are they interviewing for, low level disk experts? Why would only low level disk experts be able to answer that?
    • eklavya 5y ago
      That’s not their point. Point is, it’s really subjective and there is no standard answer. As much hate as leetcode style interviews get, you at least have a standard interview process as that point but yeah don’t overdo it and make sure the loop is varied in the areas it covers.
      • kevinventullo 5y ago
        I believe “Writing to disk one byte at a time will be slow” is the standard answer, with varying levels of detail depending on the role.
        • eklavya 5y ago
          I am being misunderstood, let me elaborate, point is, there is no standard answer to the question “what to ask in an interview”. They are just giving an example of how somebody will always have problem with the questions being asked and they could be right in their perspective which is just different.
• EdwardDiego 5y ago
  At last company we used an online tool to screen junior/intermediates and the whole point of that tool was "Here's the task, here's the tests that need to pass when you're finished, feel free to write more", and someone writing more unit tests to exercise their code was a big positive. Asking someone to implement stuff without running it sounds counterproductive to me. About as effective as asking them to write syntactically valid code on a whiteboard.
• pugworthy 5y ago
  So here's my read on this, based on the post. The author is focused with technical review, and as such he probably fails to see just how important personal review is. Yes, you are being reviewed technically, but you are also being reviewed personally. You may know a lot of technical things, but do I want you on my team? The phone interview is what i'm going to use to make that decision. Technical we can work over later, but only if you sound like someone I want on my team. I'm always willing to say, "They look like a great fit for the team and our goals, and let's give them a chance to learn the tech" versus, "They know a lot of technical stuff and let's give them a chance to see if they can learn to work with other people."
  • kevinburke 5y ago
    I worked as a sole proprietor/consultant for several years, which involved lots of “personal review” during the sales process. I am well aware of how important that is.
    • pugworthy 5y ago
      Then address it and be willing to evaluate and discuss how you come across in your post.
      • kevinburke 5y ago
        I’m very confident that I come across in interviews as someone that you want on your team.
        • pugworthy 5y ago
          And yet...
  • colmvp 5y ago
    > "They look like a great fit for the team and our goals, and let's give them a chance to learn the tech" I wish more were like you. I've definitely had my fair share of interviews that bombed so I feel like I have a good bearing of when I don't leave a good impression, but it's always the worst feeling to have an interview that you think went well based on the overall mood/feeling, only to receive the eventual rejection later in the day that they went with someone more senior or that they wanted someone with more experience in x. My mentor who didn't got to a well-known college once told me he joined a very solid company not knowing anything about the frontend framework they used but they gave him documentation and let him learn it for weeks without touching the code base. He said it was honestly one of the strongest engineering teams he's worked on in his career. The idea of managers seeing potential in someone and thinking "let's go with that person who has never done x" seems so foreign to me.
• MathMonkeyMan 5y ago
  Your code on github is pretty slick. I love the documentation. Leetcode is an exam that you can study for. For me, it's pretty damned hard and I dislike it. I can think of three reasons why someone might be good at those kinds of problems: • You just have a knack for it. • You are very intelligent. • You practiced a lot. Which one of those can you do something about? Every time I force myself to grok a new leetcode trick, I've truly learned something. Something irrelevant in my ten years of programming, but allegedly an indicator of someone who might be good at what we do.
• phendrenad2 5y ago
  Hold your head high. Being good at algorithms is a life hack to get a tech job. You did it the hard way. Companies are full of people who do well at a whiteboard. You're the rare variety that companies NEED MORE of (even though they don't know it).
• slibhb 5y ago
  I have sympathy because I program in a similar way as the author. Not so much with tests but with some kind of fast feedback loop where I do lots of guess-and-check. I don't know how I'd do in this kind of interview. However... > If I get behind or the interviewer starts interrupting to ask about the bad code I'm writing I get very stressed and have trouble both listening to the interviewer and trying to address the issues with the code. My sense is that 90%+ of these interviews is maintaining your composure, asking questions and generally coming off as well-adjusted and personable even if you don't know the answer or get stuck. > Certainly there are a lot of confident, mediocre tall white men in the tech industry That's some chip on his shoulder.
• cebert 5y ago
  Companies are missing out on tons of great, talented individuals who are frightened to endure Leeetcode-like interviews. Are there any firms that give candidates choices on how to demonstrate they’re a good fit for open positions? Maybe you do like grinding Leetcode algorithm questions, maybe you want to create a new service that satisfies requirements and discuss the design choices, perhaps you’re really good at contributing to existing projects.
• briandw 5y ago
  I worked with Kevin at a startup (Otto smart lock). He's a solid developer that I'd be happy to vouch for.
• questiondev 5y ago
  yeah and if you are an anxious person like me, (i may be on the spectrum, i have some social issues), writing code in front of people makes me very anxious, it takes me back to my childhood when my dad would scream at me for being dyslexic, i got my b’s and d’s mixed up. i know that is not what is happening during an interview but, it’s how i feel. and this prevents me from getting ahead in an industry i am madly passionate about
  • deleted 5y ago
    [deleted]
  • adamzerner 5y ago
    I'm really sorry to hear about those traumas and your current difficulty. Shoot me an email, maybe I can help: adamzerner@protonmail.com. https://adamzerner.bearblog.dev/ https://adamzerner.bearblog.dev/ if you want to internet-stalk me first.
• mrkentutbabi 5y ago
  I think it is fortunate that great engineers like OP are rejected in Leetcode style interviews. The benefit is twofold: - It makes fresh graduate noobs (or even just noobs in general) able to compete on equal ground on high-paying job prospects. Think about it, if every high paying jobs out there value experience over leetcode style of interviews, then young noob programmers won't be able to rake great salary because all of those jobs are filled already by experienced engineers - Great engineers should just use their talent somewhere else in startups, create more innovation, create more wealth rather than helping the big tech giants become bigger
  • klipklop 5y ago
    Not so great if you are jobless and got bills to pay. “Create more innovation” is a good thing, but sometimes people need to cash those big tech giant’s checks to care for their family. Experienced engineers and college noobs should not be competing for the same jobs. Tech co’s seem to prefer the college grads for rank/file for many reasons. Maybe because they are easier to exploit?
  • tester756 5y ago
    why startup == more innovation? >create more wealth rather than helping the big tech giants become bigger should I care that some startup will become relatively significant and then sell itself once big offer appears?
• cwp 5y ago
  Heh. I have 25 years experience and I fail phone screens too. :-D It's fine, though. TFA goes into ways to improve the hiring process such that this sort of thing doesn't happen. But I don't mind it at all. I want to fail fast; if the company decides I'm not the right candidate, great, I'm glad it happened before we wasted time with more extensive interviews. There are two possibilities. If they're right and I'm not a good fit, I don't want that job because I won't be successful there. If they're wrong, I don't want that job because the company isn't being successful at hiring me. The hiring process is looking for the wrong attributes, or the interviewer isn't properly trained, or... well, something, somewhere has gone wrong. There are no false negatives. A company that's firing on all cylinders does a lot of hiring, and is good at it. They source solid candidates, and interview them thoroughly but quickly. If they're not hiring effectively, well, they're probably dysfunctional in other areas too.
  • ngc248 5y ago
    Totally agree with this. One may want a Job at a prestigious FAANG or a hot startup but may not clear for culture fit whatever even tough you answered all technical questions. I say don't despair. just as you mentioned even if you got in it may not have been a good team/good manager. We should strive to find teams/managers who can appreciate what we are and do and vice versa.
• georgeburdell 5y ago
  Today's interview process seems eminently gameable by grinding LeetCode and watching YouTube videos on system design. In the last 4 months of job searching I've gone from barely being able to get past the question (reading under time pressure stresses me out), to convincingly passing about half of my recent phone screens. All I've done is one LeetCode per day and interviewed a couple of times per week. I'm not fundamentally any better of a software engineer than 4 months ago. The current system is great for zero-knowledge people with the time and mettle to study, and awful for accomplished but time-poor senior engineers. And, why all companies have decided upon almost the exact same methodology, I can't understand that either. It seems to be the same double edged sword as the Common Application for college: you get more applicants because the incremental effort required to apply to college n+1 is low, but it drives down college admit rates as well as matriculation rates: the signal to noise ratio probably goes way down.
  • Jensson 5y ago
    > Today's interview process seems eminently gameable by grinding LeetCode and watching YouTube videos on system design. That is a feature. You look at what they worked on before to see if they are senior material. Then you do leetcode and system design to see if they are smart. A smart person would most likely learn whatever tech and problems they worked on, so if they do well on leetcode you just assume they did well in their past jobs. If they can't learn leetcode then you assume they did poorly in their past jobs. If they didn't practice leetcode then you got no signal on their smartness, so no-hire due to unpredictability. So we get these possible results and what you do with it: - Good leetcode, great and relevant experience: Hire at high level, this guy is smart so he likely learned a lot of things during his past experiences. - Bad leetcode, great and relevant experience: no-hire, he might be smart but we don't know so we don't know if he actually performed in his past jobs. - Good leetcode, no/minor expereince: hire at junior level, this guy will likely learn fast - bad leetocde, no experience: don't hire, there are no positive signals. This works really well actually. The only bad part is that some experts needs to brush up on this when they want to find a new job, but for a well paying company that isn't a problem as millions of candidates gladly brushes up for the pay bump.
    • 5y ago
• buzzwords 5y ago
  Quite honestly, if the job description says "we are looking for the best of the best" or "we are looking for a talented java developer" I know this job isn't for me. Same with algorithm questions, if the interviewer asks me an algorithm question, I will switch off and politely put a cross that this role isn't for me. I don't have cs background and my CV is clear that I've not done anything like that. Edit: I am not a great coder by any means. I just don't like to waste my time when it's clear I am not a fit for the company or the role.
• LanceH 5y ago
  I preface my interviews saying that I'm we're going to have a conversation rather than a list of trivia questions. The goal is find out what the candidate knows, rather than if they know an answer to any specific question, or specific version of a technology. If I ask a question that is too easy, it's not a trick, it's a segue to more conversation. If I ask a question that's incomprehensible, it's because I don't have a prepped list in front of me and I'm making some questions up on the fly, and the candidate should just ask for clarification. Also, that a lot of my questions are open ended, or have multiple right answers and any of them are acceptable. It's not really a pattern of interview I expect most people can implement immediately, but it really gives a good idea of fluency. I just have to home in on what they do know. The easy questions get some momentum going and provide context for the follow ups. When they don't know an answer I'll tell them the answer. Sometimes this leads to them adding some depth beyond that answer as they know what's going on but haven't worked with it formally, or have worked with it in passing, or maybe know it by a different name.
  • jrumbut 5y ago
    I've only ever done this style of interview and I've never hired someone who was downright awful. I also suspect it makes candidates more likely to accept because you can develop a bond and have a relatively enjoyable time in interviews like this. Several times I've had the interview process be so unpleasant I lost all interest in working for the company. I try to be considerate and withdraw so I don't waste everyone's time but once I did get an offer from a company like this.
  • b3morales 5y ago
    Very much this. Leetcode is terrible, but the checklist of trivia suggested in the essay is equally terrible, because it's too easy for a genuinely good programmer to simply not have experience with topic X. Or, for more experienced candidates, to not have dealt with that topic for several years and not have the knowledge fresh.
  • iAmAPencilYo 5y ago
    Would give some example questions for this? New manager here, trying to figure out hiring!
• kstenerud 5y ago
  It's important to remember that it's also YOU interviewing THEM. The coding interview is an opportunity to get to know the company culture in a very feet-on-the-ground fashion. How the interviewer behaves and how they expect you to do things reflects upon them as managers, mentors, and in general people you'll be working with for potentially a long time. - If they're forcing you to go against your natural flow, that's a red flag. - If they're preventing you from building or explaining things as you'd normally do on the job, that's a red flag. - If they don't allow you to consult the resources you'd normally do, that's a red flag. - If they prevent you from testing your work and assumptions as you'd normally do, that's a red flag. - If they're only looking for work and no conversation (all questions to you and none to them), that's a red flag. I've had times during an interview where I've had to pause everything and explain that this is how I work, and how I would work if I were hired. Usually the interviewer will stop, reassess, apologize and we move on no harm no foul. I've also had occasion to stop the interview and say that we're not going to be a good fit, sorry and goodbye. It's on YOU, the interviewee, to make sure that you're not getting bullied or coerced (either accidentally or deliberately). This is not a one-way street. If you don't push back, at best you get hired into an abusive or incompetent environment, and at worst they reject you after toying with you, wasting even more of your time and sapping your morale. Yeah, it's a bad time when one hires a bad employee, but it's MUCH MUCH worse to get hired into a bad company! You're taking a bigger risk than they are, so make sure you interview them well! Breaking off an interview is not a bad thing; you're assessing THEM as much as they are assessing you, and eliminating the deadwood early is in your best interests, because YOUR time and resources are precious too. Remember: THEY can fail phone screens, too.
  • drclau 5y ago
    > It's important to remember that it's also YOU interviewing THEM. I agree with what you said in the rest of the comment, but I'd like to go one step further with the idea of "YOU interviewing THEM". Let's add some symmetry! Let's make the interview double the usual time, and half of it I get to ask the other side to solve LC problems that I pick at random, or design systems I made up the day before, or behavioural questions about their past experiences. According to companies, that is the only way to assess if a person is good enough for the job, so I'd like to use the same method to find out if I want to work there.
• 5350-uiop-1130 5y ago
  I have 15 years of experience and have found unless I'm contacted directly by the internal recruiter of a company it's pretty much impossible to even get a reply to a job ad. I don't know how people who are new to this industry are managing to find work. Pretty sure I'm getting filtered near 100% of the time.
• bitwize 5y ago
  As Jensson points out, smart people can grind leetcode, so if you have good experience, grinding leetcode shows you're smart enough to get the job. If you don't grind, there's no signal of how good you are at coding, so it's a no hire. Really, it's on you if you don't do what needs to be done to get the job. So get grinding! Or remain unemployed.
  • inb4_cancelled 5y ago
    Can't tell whether you're being sarcastic.
  • tester756 5y ago
    >If you don't grind, there's no signal of how good you are at coding hardest and most important thing in software engineering is (imo) modeling systems, it's definitely not kind of skill that can be measured by LC. Strong understanding of OOP itself makes you top% programmer/software engineer. Add strong understanding of functional programming to it and you're probably 0.x%
• Brajeshwar 5y ago
  About 11-years ago, I was in a bad shape after a disastrous Startup failure. I was looking for a job and out of many prospects, I had an interview with bookings.com. It started with a phone interview and they wanted to go technical right away; so started asking me the basics of CSS. I was taken off-guard because I don’t remember what is the default value of float, or the list of default values for many CSS objects. I explained that I don’t remember those as they usually pop up in the IDE when I start typing. However, if they want, I can show my open-source bare-bone drop-in grid framework I wrote sometime back or I can walk them through CSS Box-Model or even explain how I can help bridge the gap between designers and engineers. Unfortunately, it ended as their time ran out. I got a rejected reply because I could not pass the basis of CSS on a phone call. That was the incident I promise myself that any candidates I interview in future will always get a chance to explain/prove their worth in the ways they know best.
• soneca 5y ago
  > ” I'm not fast at reasoning about code, and I often make trivial mistakes just trying to get a "first draft" of a program out. If I get behind or the interviewer starts interrupting to ask about the bad code I'm writing I get very stressed and have trouble both listening to the interviewer and trying to address the issues with the code.” That’s exactly what happens to me. The thing is, I am not as fast or experienced as the author. I don’t do well on those Triplebyte quizzes because they put data structures and algorithm question among even in the frontend quiz. And also ask trick questions that I usually run the code to see what happens, not spend 3 minutes imagining what the outcome would be. I much prefer take-home tasks even if I take 4 to 5 hours when instructions said I should take two. So, I am just terrible at technical assessments in general. And I don’t have that solid CS knowledge that some positions require or people think is the minimum necessary for me to be called “engineer. I don’t care. I am happy being called a “developer”. The challenge is: how do I find a job post that would hire for what I am good at? I am good at shipping things. I am good at communicating with non-engineers in general. I am good at scoping, understanding the problem that people want to solve with code and proposing the fastest way to get there. I am good at creating simple code that it’s easy to understand and do what’s needed to be done with good performance. I am good at writing tests that make sense. I am good at focusing and organizing my time to deliver working code in the agreed deadline. I am good of delivering good work with autonomy. I am good at working as a team. I am quick to learn new tech. I am quick to understand legacy code and to improve it. Despite my poor technical interview skills, I was never fired for poor technical skills. On the contrary, I was always complimented for what I ship, how quickly I learn and contribute when dealing with new tech/codebase, and how I quickly improve upon feedback. So, how do I find a job whose hiring process value those, not the former? I am considering not even trying if the process has a mandatory live-code step or leet code.
  • michaelrpeskin 5y ago
    It’s hard to find those places because they’re usually small companies outside the valley without name recognition. I work for one of those places and am the lead technical interviewer (no “a” lead, “the” lead, that’s how small we are). We do have a very easy take home code challenge that’s very related to the kind of work we do. But we only specify the language to use because that’s what 99% of our code is written in. We don’t care anything else about structure of the project and you do it on your own time (it’s really only an hour or two of work - or at least it should be) I’m not sure of the rate of people returning the challenge to us (I hear that it’s a bit less than 50%). I interview all of the folks who return code. And pass about 2/3 of those on to the full day interview. (No-pass is usually code that doesn’t compile or gets the wrong answer on the test case that we provide - we give them the correct answer for the test case, so they know what they’re aiming for). And we hire a pretty high percentage of the folks who do the full day. Granted, we’re in a bit of a niche field and we don’t have big-tech name recognition so we don’t have the volume of applicants that other places have to deal with. I always try to be respectful in the interview and we only talk big picture stuff. There are no quizzes or gotcha questions, we talk about the code and just have a conversation. I hope that everyone who leaves my interview feels respected and like their time wasn’t wasted. Sometimes I include one of my junior engineers on the technical interview so they get experience with it. Usually they start off peppering questions and trying to be smart, but I just set a good example and they calm down quickly and realize it’s about a conversation and seeing if the candidate would like the kind of work we do. I can’t think of any bad hire we’ve make in my years of doing it this way.
• unbanned 5y ago
  You're probably just "not a good fit" and lay the blame on a technical interview.
• intellectronica 5y ago
  The best interviews are designed not to filter out bad candidates but rather to allow good candidates to demonstrate that they are good. The best companies know that and design their interviews in that spirit. Some technical test interviews appear pointless to experienced candidates because they are designed to give an opportunity to someone without any experience to show that they know enough to get started. That's how some companies can hire people without work experience. Many (most?) companies are simply bad at hiring and use poorly designed cargo-cult test interviews. They have a vague notion that more successful companies use test interviews so they try to do the same, only without designing an actual effective hiring process. As a result, their hiring is essentially random - they interview some people, which they put through a test interview ritual, and then hire a random selection of these people. Even if you can get a job at such a company, would you want to work somewhere where you'll end up with randomly selected colleagues? These also tend to be the companies that have high employee turnover - they have to let underperformers go to compensate for their random hiring, and the best people leave because they don't like their randomly selected team. If you have a realistic view of your own skill and fit for the role and the interviews don't make sense then either you're overqualified or it's just a bad company or both, and you wouldn't want that job anyway.
• ZanyProgrammer 5y ago
  From a labor perspective, the typical dev interview process is profoundly anti-worker.
• chrisseaton 5y ago
  It's great when senior people admit they're no good at interviewing. I've never passed a technical interview. I got my internship at a company that thankfully valued informal broad technical discussion over a conventional technical interview, then from there I slid into a full-time job at the same company with no additional interview. By the time I applied for my second job I was senior enough not to be asked to do a technical screen. I've attempted conventional tech interviews in between and absolutely crashed and burned! So I'm impressed by anyone getting through these interviews, because I can't do it!
• throwaway984393 5y ago
  You don't need to have someone write code to find out if they know how to code, or how well. Simply ask a series of increasingly deeper questions about a range of coding topics that elucidate both technical expertise and experience. If you don't know all of that yourself, find someone else that does and have them do the interview. I've always been able to conduct interviews and find out someone's strengths and weaknesses without seeing them write code or fix a broken thing. Maybe I'm just some magical unicorn and this is a super rare skill? But I doubt it. I'm just looking for the tell-tale signs of someone who has done real work and learned things in that process. The other thing is, as someone hiring, my main concern is just making sure the candidate has the specific skillset or experience I need. The person may learn quickly, but I probably don't have time for them to learn the one technology I need them to use ASAP. A lot of candidates end up getting rejected because they put something on their resume that we really need but they don't know well enough. And some just seem to be trying to reach and do a job they don't have experience in. It's hard to find someone who has just done the job I need done and isn't trying to get some other job.
• tkiolp4 5y ago
  Good candidates do not apply if leetcode is involved; good candidates know they can code and they want to have interviews where they are asked, from a high level perspective, about past projects and the like. On the other hand, bad candidates know they cannot code nor talk about past projects in a decent way, but it’s easier for them to cheat by submitting copied pasted code than to talk about software. By using leetcode in your interviews you are giving bad candidates an opportunity to apply for a job in your company.
  • MathMonkeyMan 5y ago
    Yes, but bad candidates are going to apply anyway. How many depends on the size and visibility of your company. I suspect that for FAANG, leetcode is a much better filter than random (or going by shoe size). And there must be a filter. Also, think about the cost of the time employees (developers) spend interviewing -- let's come up with something quick, standardizable, and programming-related. Leetcode.
• codingdave 5y ago
  > In theory a phone screen is supposed to evaluate whether a) this person would be good at the job being hired for and b) whether it's worth investing another five hours in trying to hire this person. They also screen whether or not you communicate well, your motivations for looking for work and whether that matches the role and future growth of the role, whether there are any logistical or compensation-based blockers to the role... Frankly, getting all the deal-killers out of the way is the point of the phone screen. Figuring out whether you can actually do the job, and do it well, is for later phases of the interviews. I feel like the hiring process is often misunderstood. The first screen is one of two things - if you are working with a company directly, it is just a screening for deal-killers. If you are working with an outside recruiter, it is them trying to understand you to know how to market you to the hiring manager. In either situation, though, if they are getting into remote coding of algorithms on an initial phone screen, something is really off in their hiring process.
  • kevinburke 5y ago
    > whether or not you communicate well So whether you would be good at the job being hired for, then. The whole point of the post is that the phone screen isn't just screening for deal killers. If it was you wouldn't flunk people for not nailing the optimal Big O runtime for your custom algorithm.
  • Jach 5y ago
    It's hard to get meaningful answers to these really general properties you're after: > communicate well This has so many elements and is really only fully visible after you work with someone for a while. Sure you'll catch some red flag issues, but such issues likely to be caught are also likely to be caught no matter what you're talking about, so this can't be the primary purpose of the screen. > motivations for looking for work Is not wanting to trade services in exchange for money in a valued environment enough? But sure, aspects of this for most people can be an important subgoal, it's just important to set expectations on how easy it is to game and how unreliable the signals will be. I've sometimes found it useful to probe seriousness and a sense of longevity commitment (if that matters, and can be incentivized without needing to probe), and some of their values, and whether their idea of your actual environment matches your reality and how much that matters (the candidate should be actively participating in this with their own questions though), but again reliable signals are hard. Once I helped screen a manager who was thinking of coming back (he had previously left a couple years prior) to the company to manage a new project, and got out of him when asking what might stop him from leaving again in a year the vague (if true and agreeable) "you never know what opportunities life will bring" and concluded he wasn't that committed for the role I felt needed someone willing to put at least a few years at it. It surprised another guy who talked to him, but he hadn't probed into that. > logistical Seems this could be handled before any conversation takes place by clear communication about whether the role is remote or not, how much office time is required, whether relocation support is offered, and so on. > compensation Also can be handled before any conversation by having salary ranges for the role. If they're too low, a good candidate might go through with things anyway and try to negotiate beyond the range. > getting all the deal-killers out of the way is the point of the phone screen Ultimately I agree with you on this, but I think the biggest deal-killer for a technical role is: the candidate cannot actually program at a level you require. I'm a fan of Yegge's process (https://sites.google.com/site/steveyegge2/five-essential-phone-screen-questions https://sites.google.com/site/steveyegge2/five-essential-pho...) and warnings and have used my own variant for what we cared about more, but frankly if your screening doesn't require some level of coding at least on the level of fizzbuzz or easier (but adjust to requirements/expectations), sooner or later you're going to bring someone in for a full round and discover they can't program, wasting possibly considerable time (more than five hours when adding it up for everyone involved) as well as the opportunity cost.
• saxonww 5y ago
  I read about three paragraphs in and then stopped. Coderpad tests where you're encouraged not to write tests, can't hit the run button, and can't use reference material? Worthless. Most people - not just the author - are going to fail those, and they are not representative of the work environment, so what's the point? We use Coderpad for one of the 3 interviews we give candidates. We do a tech screen first, then the coderpad, then a panel interview; the author is right in that it's about a 5-6 hour process overall (for the candidate). The coderpad is as much about watching how you go about solving a problem as it is you getting the right answer, although that certainly counts. We want to see if you pay attention to the question and implement what we asked for (not brain teaser 'gotcha!' stuff, simple stuff like "write a function that does ... and returns a boolean" - a lot of people will have their function print an answer and return nothing, or won't write a function at all, or will ignore other key requirements), that you can explain your approach, that you can think of some test cases, and that you can accept help/coaching if you're clearly stuck. We want people to do it in a language they are comfortable with, and looking up syntax is OK. Overall I'm not sure how much value we get out of coderpad. It's manufactured pressure, just like a whiteboard exercise in an in-person interview. You can tell candidates what I wrote above, and try to convince them that it's not about getting the right answer as much as how you get at the answer, but that doesn't really work. Some people are not going to do well in those interviews regardless of their ability.
  • joelbluminator 5y ago
    > Overall I'm not sure how much value we get out of coderpad Well so you're pretty much in agreement with the author it seems. He's just more convinvced than you that coderpad is actually more bad than good that's all, you have a bit more doubts.
    • saxonww 5y ago
      Maybe. I know we've hired people who did objectively poorly on our coderpad and they've been effective - although in one case not as an IC, IMO - while other people who did objectively great were just not. I think my feedback is that the coderpad is not about whether you can solve tricky brain teasers correctly. It's just one signal along with several others: can you understand directions, can you demonstrate familiarity with a coding environment, and does it seem like you can think through (again: simple) problems in a way that we can compare to more real-world stuff. Personally, my favorite challenge stuff when I was last interviewing were take-home problems that were more representative of the type of work the position would be doing. I could take my time, and idk I felt like I was doing something meaningful and holistic instead of implementing an algorithm. I've brought this up enough to realize that it's a controversial idea though; a lot of people either want that scheduled hour coderpad because they are taking their personal time for it and that's what fits in their schedule, or I've also heard people say that if they are going to do work then they expect to get paid for it, so a take-home assignment doesn't work for them. Of course there's also the possibility that someone will just copy an answer from somewhere and submit it.
• joelbluminator 5y ago
  Everything he said is spot on. I suspect algorithm interviews are optimized for FAANGS - e.g if you can do the whiteboard and coderpad under pressure and interruptions you'd statistically do well in FAANG. I suppose that's true otherwise they wouldn't be doing it. But this hiring process is extremely broken for most everyone else; FAANGs don't really care about false negatives; they have so many great people wanting to work for them its ok for them not to hire some great people. But this whole process seems problematic to me for smaller companies who are in great need of good people and aren't drowning in great resumes. You can't really afford to miss 50% of great people if you're a startup, and this process will do just that; it will let you hire good people but also not hire good people on a really bad margin. Companies who are not FAANGs, especially startups, are better off coming up with some hiring process like the author described; it's not perfect but it will have less false negatives.
• treeman79 5y ago
  Had a guy with 20 years experience at UPS or One of those come in for an interview. He had spent the 20 years copying and pasting the same bit of html and changing the text. No clue what an array or anything was.
• sdiupIGPWEfh 5y ago
  > Coderpad must work for some people since companies are able to hire a nonzero number of engineers, but it is definitely not a good fit for me. Seems everywhere I've applied recently has been using Coderpad. Lately I've been accepting interview requests for principle roles from on-site recruiters, and I've been consistently rejected after these Coderpad tech screens. What's bugging me, however, is the "challenges" have all been softball questions. Reverse a string. Demonstrate an understanding of closures. Write a function that tests if two strings are anagrams. Write some basic React. Create an interactive form. I breeze through well enough, then it's either an immediate rejection or else they ghost me. Not once do I get farther than that. I'm not even mad, just confused as hell. This is coming from the perspective of someone who was getting used to offers from the first job they applied to. If there's something off-putting about me lately, I wish I knew.
  • MathMonkeyMan 5y ago
    I've never done this, but you might consider getting an experienced interviewer to do a mock interview with you (of the same sort you've breezed through before). It might be a coincidence that you have been rejected multiple times, or it might be some small behavioral thing that someone could tell you about. Alternatively, you can say "screw this," and I wouldn't blame you.
    • sdiupIGPWEfh 5y ago
      Huh, I like that idea. Thank you. Possibly a good excuse to get in touch with some former colleagues as well, which I suppose couldn't hurt either. Mercifully, I'm not quite yet desperate about leave my current role. But I do feel like my career (and salary) progression is stagnant; not seeing much opportunity where I'm at. I'm thankful for what I've got, but I think it's smart to be looking. Just found it weird to face rejection so much from people reaching out to me in the first place, in a supposedly hot market.
• jdblair 5y ago
  I don't ask candidates to code on a phone screen. For coding proficiency, I show them code with flaws and ask them you do a code review. To break the ice I just ask them to describe the program behavior line-by-line. For a good candidate, it's a jumping off point for a deeper discussion.
• anewguy9000 5y ago
  coderpad interviews test performance anxiety. there is a set of programmers without performance anxiety and there is a set of programmers with performance anxiety. whats interesting is that the cargo culting of coderpad interviews from google on down means google takes the best programmers with acting skills (thanks to infinite money) and everyone else takes the second tier of programmer with acting skills. the best programmers without acting skills (like kevin here) are left out. the plus side, for them, is they may find the set of companies who arent cargo culting and might really have a clue.
• stjohnswarts 5y ago
  The secret to these is to not play the game. If you send me to a website like coderpad I'll just say thanks but no thanks. If my code portfolio and extensive experience isn't enough to get me to talk to one of your real engineers and find out what I know (that I'm not bullshitting) then we should both stop wasting our time and you can find someone else.
• jcoder 5y ago
  I was in agreement with most of the article, but the final footnote came out of left field for me: 7. I have a bunch of ideas around testing how quickly and how accurately people can type, or accurately transcribe text from a second screen, that I think could be decent predictors of job performance but I'm not sure are fair to test out in a professional context without academic research that could validate them at least a little bit. Can anyone explain how including such a thing in an interview is relevant at all?
  • kevinburke 5y ago
    Attention to detail and recall, mainly, but again I don’t think you can justify screening for it at all without additional academic research.
    • jcoder 5y ago
      Maybe the accuracy of the final work product would be a fine filter for attention to detail, but as a sibling comment points out, “quick and accurate” transcription is likely to just discriminate against otherwise fine candidates.
  • foerbert 5y ago
    I assume the author thinks that would be a good proxy for some hard-to-measure quality, and is not actually aiming to hire the best typists because of their typing skills. As for what that quality is, I don't see any hints there. It could be anything from general tech-mindedness to even basic diligence or who knows what.
  • baobabKoodaa 5y ago
    This would be highly effective at filtering out people with physical disabilities that affect typing. For example, I have chronic issues with my joints. On my personal computer I use an ergonomic keyboard (Advantage2) which has keys in weird positions. My typing speed on this keyboard is much lower than it was earlier when I used a normal keyboard. Nowadays when I use a normal keyboard, my typing speed is also slow because I am used to typing on the ergonomic keyboard, not on a normal keyboard.
• shiohime 5y ago
  I truly despise the leetcode style of interviewing. It comes off as completely lazy and ineffective for most companies, and is a terrible indicator of how talented individuals are. I've been in the field for about a decade and have been on both sides of the interview table more than I can remember. I'm at the point where if I get asked these kinds of pointless questions at a screening phase, it is a signal I probably don't even care to work for them. If they don't care enough to actually create a meaningful interview process rather than copy+pasting the dumb Silicon Valley company pointless leetcode interviewing template, then they're clearly not somewhere I want to work. The worst experience I had was applying for a couple of large companies like Peloton and Compass. They outsourced the leetcode interviewing process to some arbitrary company in Russia. Not only did I not have the chance to ask any questions of the company, but I had to do absolutely pointless trick questions for an arbitrary third party. It was an absolute waste of time that I only did once and told the other company basically to fuck off. Seriously, if a company can't even run their own interviews what is the freaking point?? It's an absolute absurdity and I cannot believe that this practice is so common.
  • rileymichael 5y ago
    The outsourced interviewing company was Karat I assume. Pretty terrible experience as you said.
    • shiohime 5y ago
      Yep, that was the one.
• Hakashiro 5y ago
  I feel this differently. I too can pass on-site interviews, but my problem is I don't even get a first phone screen to begin with, they discard me without even spending 5 minutes on me. You Americans (even afroamericans) have absolutely zero clue about how racist your companies actually are. "But Google and Microsoft CEO are Indian!" Yeah, but not really. By the way, I'm Southern European, with a Southern European sounding name.
• windex 5y ago
  Yeah well, I recently flunked a role I had years of experience doing. The expectation I assume in some of these phone screens is that you will lie to get the job. I refused to tell them that I had done something I hadn't and laid it out to them why something they were asking for wasn't possible in an IC role. I refuse to play these games.
• no-s 5y ago
  I think I would prefer to work with someone who optimizes their strengths the way kevinburke describes in his post. However as a manager I would structure phone screens to quickly filter out candidates who would never work out, no matter how optimal they seem. This is an art and odds are candidates are never going to have the perspective to appreciate the aesthetic of the completed work…
• ChrisArchitect 5y ago
  Didn't open this post/article because I assumed it was about mobile phone display technology. Couldn't have made just a tiny bit more effort on the title wording?