Seriously, been working as a software developer for 9 years now and never passed a single coding test.

The jobs I got were always the ones giving me weekend projects or just no coding test at all.

I have a job opportunity that looks exciting but they sent me this coding test link and I know I’m gonna fail for sure. Any tips aside from the obvious (practicing in advance on leetcode etc)?

  • tealeg@programming.dev
    link
    fedilink
    arrow-up
    98
    arrow-down
    15
    ·
    7 months ago

    What I’m about to say might come off as smug. I don’t mean it to be a flex, it’s just for context.

    I’ve been programming since i was 6 years old, and have 26 years of continuous professional experience. 30 years of open source contributions. You are almost definitely interacting with code I wrote on a daily basis.

    7 years ago I was caught up in a round of layoffs and I was scouting around for jobs. I got an interview at a startup - it wasn’t a huge tech challenge, but I needed a job.

    I did an initial technical interview with the tech lead for the company. All went great. I did a “final HR interview” , again great. Then the CTO stepped in and said that he would need me to complete a coding test before I could be hired.

    I failed that live coding test despite producing code that outperformed the code in the “correct” solution by several orders of magnitude.

    The CTO was clearly upset by my solution, which he got very angry about and insisted was wrong, without explanation, and despite it beating the spec and passing all the predefined tests.

    2 days later the tech lead, who was also present in the test, told me there was nothing wrong with my code. Better still they had actually taken it and put in into production in place of the code that CTO had written, and which was the basis of the “correct” solution.

    He also told me that he’d quit after an argument with the CTO about this and asked if I found a good place to work, if I’d let him know.

    Sometimes tests are not about what you can do, but how smart they make the person testing you look.

    • Exec@pawb.social
      link
      fedilink
      arrow-up
      52
      arrow-down
      2
      ·
      7 months ago

      Better still they had actually taken it and put in into production in place of the code that CTO had written, and which was the basis of the “correct” solution.

      The test was just a set-up for free work.

      • huginn@feddit.it
        link
        fedilink
        arrow-up
        27
        ·
        7 months ago

        No, not if they already had a “correct” solution.

        It’s normal to know the answer you’re looking for before you ask the question, and they thought they did in this case.

        • wewbull@feddit.uk
          link
          fedilink
          English
          arrow-up
          10
          ·
          7 months ago

          Yes. The problem was the interviewer wasn’t prepared for a different correct answer.

      • tealeg@programming.dev
        link
        fedilink
        arrow-up
        2
        ·
        7 months ago

        I hear that accusation a lot, but I’ve never really seen a company do that. Having been in the other side of the equation many times, the effort required to review code that’s submitted, especially when you don’t know the author is probably not worth it.

        The case I detailed above was a fairly isolated subsystem that didn’t really require any knowledge of their system to work on. They probably chose it because A. It was a readily available problem with an existing solution that you could reasonably expect to be solved within a couple of hours , and B. the CTO thought he had a cool solution.

      • tomatol@lemmy.worldOP
        link
        fedilink
        arrow-up
        18
        arrow-down
        3
        ·
        7 months ago

        Yeah idk why that comment is being upvoted so hard… It sounds very weird like a copy pasta or a bot. He didn’t even answer anything 😅

          • tealeg@programming.dev
            link
            fedilink
            arrow-up
            1
            ·
            7 months ago

            Really, it isn’t meant to be. I’m Just trying to say it’s not always the candidate at fault.

            This is one example from a great many interviews I’ve had in my time, most of which went much better.

    • wildbus8979@sh.itjust.works
      link
      fedilink
      arrow-up
      24
      ·
      7 months ago

      I’ve been coding since I was around 12. I’ve been doing it for around three decades now…

      On the opposite side of the spectrum, I work for a company that has a pretty strick no assholes policy. We’ve passed on a number of “rock stars” because we knew how personally toxic they were to a team. I do some of the culture fit (which we do first) and tech interviews.

      We don’t care all that much if you get it right or wrong. I mean if it’s all wrong and the candidate has no clue why sure. But sometimes candidates get stressed out being on display, being pressed for time, trying to come up with the most optimized answer instead of just completing. If it’s all wrong and the candidate can tell me exactly why and what they’d need to do to get it right, that’s mostly a pass for us.

      Ultimately wanna see a) how you think, what is your thought process and b) that you can grow.

      • thesystemisdown@lemmy.world
        link
        fedilink
        English
        arrow-up
        16
        ·
        7 months ago

        I’m trying to wrap my head around the CTO writing code unless it was from long ago when they were a developer. If that is the case, the CTO should understand that a better or more performant solution is likely over time. I’d say that was a bullet dodged. That’s very poor executive behavior.

        • wildbus8979@sh.itjust.works
          link
          fedilink
          arrow-up
          9
          ·
          edit-2
          7 months ago

          People have big egos. I’ve been in similiar situations as OP where the owner/CTO wrote a lot of the legacy code and weren’t particularly receptive to criticism. No acknowledgement either when said criticism turned out to be a client facing vulnerability later on.

          • tealeg@programming.dev
            link
            fedilink
            arrow-up
            2
            ·
            7 months ago

            Yeah. Owning code is about taking responsibility for it being in a satisfactory state, it shouldn’t be overly personal and you also shouldn’t attack people directly when the code has problems. Everyone makes mistakes, learning from them is there important thing.

        • tealeg@programming.dev
          link
          fedilink
          arrow-up
          3
          ·
          7 months ago

          It was a really small startup where the CTO was one of the founders and had written the first version of everything. I don’t mean to belittle what he did, I have a lot of respect for people building thins from the ground up.

          It was just a very odd episode and illustrative that you don’t always fail because you’re bad at coding.

  • DudeDudenson@lemmings.world
    link
    fedilink
    arrow-up
    55
    ·
    7 months ago

    If you’re doing it live with another person what’s most important is explaining your reasoning and speaking through your solution. When the test is being supervised by a qualified programmer then the objective isn’t to see how you solve that specific problem but rather how you reason trough stuff

    If it’s just an unsupervised timed test just cheat as much as you want since the test is bullshit and most likely has nothing to do with the job you’re actually applying for.

    • grrgyle@slrpnk.net
      link
      fedilink
      arrow-up
      23
      ·
      7 months ago

      If it’s just an unsupervised timed test just cheat as much as you want since the test is bullshit and most likely has nothing to do with the job you’re actually applying for.

      That’s not cheating - that’s doing the job. Whether that involves looking everything up, asking for help, brute forcing it, hell (not recommended, but) even copy+pasting code.

      If that’s how you’re going to be working, then it’s an accurate representation of what kind of results your employer can expect.

  • walter_wiggles@lemmy.nz
    link
    fedilink
    arrow-up
    26
    ·
    7 months ago

    If the job market around you sucks then you may have to just practice until you get good enough.

    However that does not mean online code tests are accurate or properly reflect your skills and ability to do actual job work. They’re a tool used by companies that don’t respect the candidate’s time and you should see that as a mini red flag.

    • tomatol@lemmy.worldOP
      link
      fedilink
      arrow-up
      9
      ·
      edit-2
      7 months ago

      Yeah it really does suck. Literally every company is sending me an online coding test. Only one so far had a problem that was related to my daily job.

      • TrickDacy@lemmy.world
        link
        fedilink
        arrow-up
        4
        ·
        7 months ago

        Never heard of a countdown timer. Usually I’ve seen these either as whiteboard problems in which interviewers will help you if you’re struggling and be forgiving of the stress the situation creates, or you get days to complete a task you turn in later.

        The ticking clock is weird and unnecessary

  • huginn@feddit.it
    link
    fedilink
    arrow-up
    19
    ·
    7 months ago

    What worked best for me was taking notes on some common algorithms and patterns. Dynamic programming is a really common domain of algorithms that you’ll find in coding questions, but you’ll need to know a bit of everything. Major graphing algorithms like Kruskals and Dijkstra’s, BFS/DFS and maybe the Bellman-Ford algorithm etc etc etc.

    But most importantly as you take notes on what each of these concepts or algorithms are - write in your own words how to choose them from the list of possible solutions.

    Here’s a sample of notes I wrote on backtracking algorithms:

    The basic idea of backtracking is that you permute based on a given state, iterating it forward by 1 then removing afterwards to check the next state. It is faster than using a hash table because you’re not constantly creating objects.

    For example, when trying to do combinatorial sums:

    [1, 2, 4] goal 7

    You have the following correct answers: [[1,1,1,1,1,1,1], [1,1,1,1,1,2], [1,1,1,2,2], [1,1,1,4], [1,2,2,2], [1,2,4]]

    You can quickly see a repeating pattern of values, which is a clear sign of backtracking being an efficient solution.

    The point of all of this is to get it into your head how to choose which algorithm, then you work on the speed with leetcode practice. So my regimen when I was searching for a job was to take an hour a day to study an old concept or learn a new one and then run some leetcode questions. This worked much better than unguided random grinding.

    The other issue with coding questions is defining the parameters and other communications skills. That’s a bit trickier - but ultimately Programming is a collaborative field. The stereotype of the aloof genius programmer who doesn’t talk to anyone is noxious: those kinds of people destroy programming teams. The best programmers are collaborative and have good communication skills. They know when to ask questions and when to interpret ambiguity on their own.

    That’s the harder part to get if you don’t have it (it took me more than a decade) but it makes a massive difference in the results.

    Good luck and God speed.

  • BurningnnTree@lemmy.one
    link
    fedilink
    English
    arrow-up
    14
    ·
    7 months ago

    Every time I do a coding test, I always overlook certain optimizations because I’m too stressed to think clearly. After the interview is done, I quickly realize what I did wrong. When this happens, I send a follow-up email where I tell the hiring manager that i made a mistake, and I provide my corrected code or explain what I should have done differently. I’ve landed two different jobs before by doing this. (One was a live coding test and the other was a take-home test.) So don’t be afraid to follow up with corrections, even if the deadline for the take-home test has passed.

  • Dandroid@sh.itjust.works
    link
    fedilink
    arrow-up
    12
    ·
    7 months ago

    I conducted coding interviews for a few years at a startup before moving to a bigger company where I had a smaller role.

    For me, I never cared about if someone got the right answer. I have actually said no to people who got the right answer and yes to people who got the wrong answer (or didn’t finish). The purpose of the interview is to see if I want to work with that person. If someone can write a perfect program, but can’t tell me why it works, that gives me no insight into how they solve problems or if they even know how to solve problems. What I want to hear is their thought process.

    First repeat the question, and emphasize the key details. Speak an example input and output of the function so the interviewer (and you!) knows you understand the problem. Then start talking about what kind of algorithms or data structures you might use to solve this problem. Reference other common problems that might be similar, and how they differ. Specify patterns that could be used for this problem or even your comparison problem, and whether or not that will work for this one.

    Doing all of these steps with spoken words helps your interviewer understand how you think, and they may give away hints to mistakes in your thought process, or even point out that you are misunderstanding the question entirely. And that’s okay! It’s better to work out the details when speaking about it before writing any code.

    Treat the interview like you are solving a problem with a colleage in pair programming. Bounce ideas off them and see what they think. They are very likely to give hints if you talk to them in this way. If you are stuck, tell them! They might be able to reword a part of the question to help you think about the problem in a different way, leading you towards the solution.

    AFTER you and the interviewer are both confident that you understand the problem, and you have discussed all the algorithms, data structures, patterns, etc. that you need, maybe spoken through a some pseudocode, or maybe written down a table of example inputs and outputs, only then start coding.

  • Hyacin (He/Him)@lemmy.ml
    link
    fedilink
    English
    arrow-up
    8
    ·
    7 months ago

    I had coding and k8s tests before my current role. As they role is platform engineering, it may not be quite the same as if you’re going for an actual coding job, but - it was open book, and you could pick your language - they weren’t trying to test “do you know [language]”, they were trying to test your analytical and thinking skills.

    The only part of it I remember now (vaguely) was something about flipping a coin. It wasn’t actually a coding test so much as a logic and problem solving test. The only thing I actually brought to the table was knowing most languages have a modulo function and how to make use of one for various thing (from experience, I’ve never actually been formally taught any coding), and I basically then Googled the pieces to put it together. They know that’s what you’re going to do on the job anyway, as literally everyone does, so why keep you from doing it in an interview?

  • Sagar Acharya@sopuli.xyz
    link
    fedilink
    arrow-up
    14
    arrow-down
    7
    ·
    7 months ago

    Don’t give the test. Tell the examiner to first be able enough to test you.

    Let me tell people that most HRs are purely professional and don’t budge 1 bit till they receive money. Simply say to them, I’ll code as much as you want me to after we discuss the payment terms.

      • MajorHavoc@programming.dev
        link
        fedilink
        arrow-up
        5
        ·
        7 months ago

        The market is very competitive right now.

        True.

        It’s such a weird time, though.

        The market has the strongest availability of developer talent right now that it ever has, largely because C suite executives have bought the snake oil that AI is doing to solve all their problems.

        The ‘fuck around’ timer is ticking fast, and the ‘find out’ phase is not going to be cheap.

        This is a great time for employers like me to remember that employees have long memories, and not to push our luck.

          • Sagar Acharya@sopuli.xyz
            link
            fedilink
            arrow-up
            1
            arrow-down
            7
            ·
            edit-2
            7 months ago

            Currently, we have no open positions.

            When we have, we simply look for old projects which people have done and ask them some basic programming questions in interview.

            As for the interrogation, if the cops call me instead of a hiding oversmart ass, I will answer them about my ‘statistics’ of employees!

        • huginn@feddit.it
          link
          fedilink
          arrow-up
          4
          arrow-down
          1
          ·
          7 months ago

          Yeah and how many applicants do you have a day? Hundreds? Tens? How long is your average posting open?

          Cause I do interviews as well - the candidates are many and the positions few.

  • wewbull@feddit.uk
    link
    fedilink
    English
    arrow-up
    6
    ·
    edit-2
    7 months ago

    Depends on the setup, but if these are tests where the interviewer is present then maybe that’s because they expect you to ask questions.

    One of the biggest problems that happens in companies is that people get given a piece of poorly defined work and the developer doesn’t clarify what is required. They make assumption about what is required and end up producing something that isn’t what’s needed.

    If you’re just launching into the problems without clarifying what’s needed, you may have failed before you even start.

    • tomatol@lemmy.worldOP
      link
      fedilink
      arrow-up
      2
      ·
      edit-2
      7 months ago

      It’s just a link to an online test and I can do it whenever I want. There’s no interviewer present

  • bloodfart@lemmy.ml
    link
    fedilink
    arrow-up
    5
    arrow-down
    1
    ·
    7 months ago

    Coding tests are there to present problems from the computer science side of things and rank people on how well they are able to solve them. The whole point is to judge applicants on their understanding of the knowledge they would have gained in university programs. Universities became accreditation factories during a boom in programming and technology hiring and employers needed some way to filter people who just skated by.

    You are failing them because you don’t have or cannot express formal training.

    Short term, cheat. Use a second computer and look shit up, form an llc and register on all the test websites (they often have free trials just like anything else) so you can send dummy applicants to learn their tests, etc.

    Long term, audit some of the many university programs available online up past the 200 level.

    One of the examples in this thread looks like the calculator problem (I might be wrong, it’s been 25 years!). They say “you can’t use these libraries, write a pocket calculator, no ui required” and provide a picture of a pocket calculator as the reference. The student is supposed to learn that even stuff that they thought was simple isn’t and that their language has unique quirks that many libraries work around.

    Someone who solved this in 102 would crack their knuckles and knock it out. Someone who never had to do something so inane would find it very hard.

    • where_am_i@sh.itjust.works
      link
      fedilink
      arrow-up
      6
      arrow-down
      1
      ·
      7 months ago

      The begining is correct, the rest is bad advice. You can learn how to solve leet-code stuff in a few weeks.

      • magic_lobster_party@kbin.run
        link
        fedilink
        arrow-up
        4
        ·
        7 months ago

        Yeah, those kind of questions are silly and don’t reflect problems that happen in real life.

        My advice when you get a question similar to this is to have a pen and paper at hand. Draw a few easy examples and find a solve those systematically by hand. From there you go to harder and harder examples and adapt your system for those examples. Try to find examples where your system fails.

        Once you’re confident you’ve found all corner cases you can start to write down the algorithm.

        That’s the advice I can give. Hope it helps!

  • Pandantic [they/them]@midwest.social
    link
    fedilink
    arrow-up
    3
    ·
    7 months ago

    I’ve only been seriously coding for about 2 years (and not full-time as I have another full time job that I’m trying to get out of) and I almost passed 4/5 of the coding tests that I took for one interview (I did pass one, but realized my solution wouldn’t pass all tests - though it did pass the ones given - so I was working to retool it when time ran out). The 5th one was in C++ and I don’t know shit about that syntax. Idk if it was legal, but I have two monitors and used a cheat sheet for the JavaScript and C++ one.

    I think with your experience, you’ll probably do fine unless you get anxiety from the clock ticking down.

  • wuphysics87@lemmy.ml
    link
    fedilink
    arrow-up
    1
    ·
    7 months ago

    May or may not be a formality. Take it and don’t sweat it. What’s the worst that will happen? It’ll rip your leg off?