9 ms·

While (live) code challenges have a lot of problems, I don't see it as a possibility to get entirely rid of them. As someone who hires engineers, I do want to v

• rkagerer 2y ago
  When I went to my first job interview after years building my own software product, I brought all kinds of examples of code I wrote which I felt showcased my talent (including an effective API I created for one of their services that lacked one, and code examples of mine that had been published in a textbook). The interviewers had zero interest, and just wanted to discuss superficial / artificial whiteboard-type problems and (in retrospect) how to hose more ad revenue out of users by upending expected browser behavior. I can appreciate how some of it offered a glimpse into how I approach problem solving, but the process (not just that aspect) left a sour taste, and over a decade later I'm so glad I didn't wind up in a career position there. If you want to attract top tier talent, as an employer you should also work to make your interview process fun and challenging, and showcase what sets you apart from you competitors. Too often firms loose sight of the fact that in the interview, they are being evaluated too.
  • theogravity 2y ago
    I'm absolutely terrible at interviews, especially whiteboarding, and the best ones either involve taking a tour of my own code, or them showing parts of their codebase and me asking questions around it; or, take homes and I have a chance to explain what I built. I don't have the memory capacity that others do to just stuff leetcode challenge algorithms that I'll never use in my head.
    • aoeusnth1 2y ago
      In my experience leetcode is not really memory heavy (except in the competitive programming scene). It’s about being able to think of a naive solution to a problem, recognize why it is inefficient, and figure out how to make it efficient, usually with DP or graph approaches.
      • theogravity 2y ago
        > DP or graph approaches I don't use either in my day-to-day. I also have memory issues around just memorizing these things. I can probably do it if I can look up how it works and then translate it. I have a really bad memory and I don't know if it's related to being aphantasic or not (no mental imaging capacity).
        • aoeusnth1 2y ago
          Again, it’s not really about “just” memorizing them, it’s about internalizing how they work to the point where they are second nature. Like being able to apply calculus to everyday life, once you have internalized it, it changes how you think about things and analyze problems. Learning calculus through memorization will not help with that.
          • theogravity 2y ago
            > internalizing how they work And how long do you expect that to take? Do you think I haven't tried doing that before? It just doesn't register unless i'm literally doing it every day. And with so many algorithms out there there's not enough time to internalize all that. I don't have that kind of memory everyone else seems to have.
            • Izkata 2y ago
              > And with so many algorithms out there Their point is that this is wrong. They're saying there's a few underlying principles that apply to most of these, and those are what you have to internalize.
  • parpfish 2y ago
    I see two problems with bringing in your code for an interview: - I don’t know how long it took you to do it, and being able to do things in a reasonable amount of time is part of all jobs. Also, I don’t even know if you’re the one who wrote it or if you are passing off somebody else’s work - it’s unstandardized across interviewees, so how do you compare? Person A wrote a more elegant solution, Person B solved a more challenging problem, and Person C did all their best work on propriety stuff they couldn’t share so they had to share show you a throwaway side project they did in one weekend
  • TN1ck 2y ago
    Absolutely agree, I'm always afraid of loosing out on someone great. Even the screening of CVs themselves is an incredible hard task as the best engineers are often humble and maybe not portray their strengths enough. What I do to make the live coding challenge a bit nicer: * I use codesandbox.io (not affiliated) as a live coding environment which is a VSCode editor that executes your code whenever you save. This makes it much more realistic how one would solve it real life. * I have them share their screen and make it clear that they can google whenever needed and that it's expected (who remembers the exact incarnations for reading a file or some API) * I only do one challenge, which most candidates finish in less than 30min. We then talk about refactoring it, building an API design around it etc. * The challenge itself is building a solver for a text based game, which imho is a fun task and is literally reading a file and filtering the content with some ifs. Any recommendations for improvement are welcome.
    • nomel 2y ago
      I think executing code makes things too strict, and can lock up/shut people down, since forgetting a library function name means you're completely stuck, which causes a feedback loop of nervous. Interviews are high stress. Absolute precision, required to run code, is not a good fit for high stress, in my opinion. You'll filter people that haven't don't a lot of interviews more than anything. I keep the problem relatively simple. I tell them that they can use whatever language, don't worry about silly typos, or exact syntax, and if you forget a library name just make one up. It's trivial to see if someone can code without executing the code. If I notice obvious problems, I'll describe the incorrect behavior, like if there's an infinite loop: "I see a problem. When you run the code, you see that it never ends".
      • jgwil2 2y ago
        > forgetting a library function name means you're completely stuck Just let them use Google to find documentation, as they would in a real job setting.
        • nomel 2y ago
          No need. I explicitely tell them that I don't care if they remember exact library/function names, and to just make them up and tell me what they do, if they don't remember. If you require specifics like that, you'll filter out anyone who hasn't worked on that specific very recently. Those sorts of things aren't something you should need to worry about keeping in your head for long.
  • Aurornis 2y ago
    When bootcamps were first becoming popular, I started inviting graduates of a nearby bootcamp to interview. The first candidate had a few small but impressive sample projects in their GitHub, including some API development and other things that surprised me for someone with under a year of experience. I was impressed! Then the second one came in, who also had a GitHub portfolio with the same sample projects and the same API design (with minor differences). I felt dumb when I realized that those sample "side projects" were actually something that the bootcamp trained them to develop and put into their GitHub profiles. Obvious in hindsight, but remember this was when bootcamps were supposed to be the next educational revolution and everyone was on the "college bad" train. In a different interview, I mentioned one of my hobbies. The candidate boldly explained that he wrote a certain package for the programming language we used. I asked some more questions before realizing he was literally describing a project I had published! He immediately changed his story and claimed to have misspoken when he realized that we were on to something. These aren't equivalent to your story, obviously. However, these are some of the reasons why interviewers still want candidates to go through the standardized testing that every candidate receives. Comparing candidates on equal testing is also pushed very hard on us by HR. If you start judging different candidates based on entirely different standards, people get extremely fussy
  • nomel 2y ago
    > The interviewers had zero interest I used to think the same when I started interviewing. Now I'm into the hundreds, and in my experience, that is the correct approach for a peripheral interviewer (not the direct hiring manager), and it's for your benefit. We have 45 minutes to prove to ourselves, and our managers, and their managers, that you are the right hire. No "feelings" or "hunches" allowed: clear tangible demonstration of competence for the requirements listed, that everyone can read, and be convinced. Where I am, unsure terms like "team fit", "feel" and "think" will get your feedback rejected. If I spend 30 minutes going over what you did, there are two problems: 1. Figuring out if they actually did the work, or maybe played some small part in a team, takes considerable time. It's not easy, because people are often running with inflated resumes, with the most interesting things usually being the inflation. People can have a good understanding of a project, without doing anything in that project, claiming the whole project for themselves. The path to being convinced that they actually did it ends up being very different for every candidate, and any exaggeration/lie you catch them in makes you question all of it. 2. It only gives a short amount of time to get some deterministic proof that represents the work: typing actual code to solve a problem. If something questionable comes up during then, in the little time left, you're not going to get a chance to prove it's not an issue. If that same issue shows up in anyone else's interview, without me being able to defend you, then that's it. So, I immediately jump into my "standard" interview. It's easy. An average person will finish on time. A great person will fly through it. It checks all the boxes, gives me the proof, and even expands out into a few things that I know are sometimes questionable for others. It gives a clear yes or no for the job requirements. THEN we go into the projects with the remaining time. If you're competent, you'll have a bunch of time left, but you'll also be a strong "yes" anyways. Any cool stuff you show me will change it from a "yes" to "we need this guy, throw money at him". If you don't like interviews, you have to blame the liars that make them the way they are. There are so many liars.
    • ryandrake 2y ago
      > Where I am, unsure terms like "team fit", "feel" and "think" will get your feedback rejected. This is a very good thing because it helps to prevent bias from sneaking in, either positive or negative. Too many interviews are vulnerable to rapport and charm. "I really like and want to work with that cool bro" should not be enough justification to hire someone. Also, (at least at larger companies), when you provide feedback, you need to also reference evidence from the interview. You can't just say "Candidate X can definitely code." You have to say "Candidate X showed, through their implementation of the Linked List Reversal problem and the Towers of Hanoi problem, that they could think through a problem and express it effectively in code. Here are some examples from the code itself that show this...."
• nomel 2y ago
  I once gave an interview to a PhD with 15 years of experience. He couldn't write a for loop at the end of the interview, but had great knowledge otherwise. We needed someone who could actually code. I had my boss join late, because it was so unbelievable. I was the only "no" for him. I was the only person that tried to make him type something. I keep my question very light and completely work related. They're allowed to ask as many questions as they want. They don't even have to remember any algorithms (I have a review slide for the relevant ones they might pick). They just have to be able to think and be "seeking" in their mindset, asking questions to fully understand the context, then convert that to code. That's it.
  • lapcat 2y ago
    What's more likely? (1) The candidate was a criminal mastermind who somehow managed to fool everyone for 15 years. (2) The candidate was just super nervous during the interview and experienced a kind of test anxiety. I've personally been (2) several times.
    • jahewson 2y ago
      This totally happens, but keeping the questions simple and the atmosphere friendly goes a long way to mitigating it. One thing my previous company did was to have a short take-home replace the live coding, then the candidates simply answered questions about it. A surprisingly large number of candidates plagiarised their submission from various blog posts online. Others were unable to answer any substantial questions about their work. All these people were senior and employed in big firms. These kinds of candidates outnumbered the obviously anxious candidates by maybe 10 to 1.
      • lapcat 2y ago
        > All these people were senior and employed in big firms. Which big firms? I find it curious that a BigCo on one's résumé brings cachet, because BigCos are able to hide incompetence, even at the executive level, to a vastly greater extent than a small company. If you find someone who for example has around a decade of experience at a company of around ten people, it's going to be almost impossible for that person to have done nothing of value. > These kinds of candidates outnumbered the obviously anxious candidates by maybe 10 to 1. Anxiousness is not necessarily obvious. My stomach could be churning and my mind racing, but a stranger probably wouldn't be able to tell.
• dheera 2y ago
  > I do want to verify that people can actually code. My best advice here is allow them to bring their own laptop and use their preferred editing environment. If their way of working is to run small pieces of code through the compiler/interpreter to spot errors, they should be able to do that, rather than pointing fingers at a whiteboard and saying "oooh that's not the right way to initialize a std::vector". If their way of working is to write inside out, outside in, top to bottom, bottom to top, that's all easy in an editor, but not on a whiteboard. They should be allowed to search for references or even cut-and-paste the boilerplate part of whatever it is, and edit it to complete the task. That is more representative of how people actually code. Dealing with unfamiliar hardware, let alone a whiteboard, hugely, hugely gets in the way of thinking about coding and is not inclusive of all coding styles.
  • deleted 2y ago
    [deleted]
• theideaofcoffee 2y ago
  > never thought about obedience in any aspect. What demonstrates obedience more than having to solve a problem against the expectations of someone holding something of value over your head? "If you don't do as we say in the way we tell you to say it, you don't get this <thing>." No matter you may have a different perspective on solving the problem, even going so far as to dismiss it outright, it's all about the rubric. No subtlety, no interpretation allowed. Make it easier for your interviewer masters.
  • whimsicalism 2y ago
    this is an alien way of looking at the world to me
  • xigoi 2y ago
    Who said anything about not being allowed to have a different perspective?
    • alex_lav 2y ago
      The nature of an interview...
      • xigoi 2y ago
        Just because some interviewers are bad, it doesn’t mean that it’s an inherent property of interviews.
        • em-bee 2y ago
          when the majority of interviewers are bad it does become an apparent property of interviews
• SirensOfTitan 2y ago
  The whole meme of “coding interviews” can illuminate how a person thinks is based on an entirely false theory of mind. When people are experienced in a particular skill, they often have reduced inner voice and experience inner quiet as the work just comes to them. Asking people in these circumstances to vocalize their thought process is to take people out of flow conditions into hyper conscious states and perform a metacognitive task, reducing their ability to focus cognitively. When you ask someone to do something they’ve never done in an interview before, you’re creating a contrived environment that doesn’t exist at all on the job. When I’m creatively working through a problem I often take big breaks after framing the problem so my subconscious can work on it. I often solve hard problems from the prior day first thing in the morning, often with the solution immediately on my mind as I awaken. You can’t do that in a coding interview: if someone doesn’t have the answer in mind readily it’s unlikely the pressured environment is going to encourage its production.
• austin-cheney 2y ago
  In my experience interviews do read code whether on a whiteboard or in a github repo. Instead they gloss over the details for than vanity of it. It’s an exercise in fashion for the sake of conformity. That is incredibly unappealing. I would rather be in a hostile deposition because then at least I would understand the opposing party’s motives and intent.
• wakawaka28 2y ago
  The trouble with open source is that it can be faked. You could pay someone to write a contribution in your name or else to accept some BS contribution. Also if you contribute to a solo project, that could be pure garbage or a ripoff of something else. Open source also favors students who have time for it. Once you're working a regular job, time tends to dry up.
• marklubi 2y ago
  Had a pier group interview at a company once where I was asked how to form a grouping SQL statement. I rattled it off and then was told that I needed to write it out on the board. Wrote it out, turned and asked how they would like it sorted (they hadn’t specified) since you should almost always have a sort on a query. The entire room busted up laughing except for the guy that asked the question. He just stood up and left. Figured that I had pissed off the wrong person. After I was hired, I was paired with him. I later asked him about it over drinks, he said that he walked out because he didn’t need to waste any more time interviewing me, that he went to the manager and said that they better hire me. He was definitively one of the smartest people I’ve ever worked with and a good friend now.