Can’t just be me, can it? Currently 0 for 3 on interviews because I can’t seem to get past the technical interview/test. Usually because of some crazy complicated algorithm question that’s never been relevant to anything I’ve ever had to do on the job in all my years coding.

Also, while I’m ranting: screw the usual non-answer when given feedback.

  • falsem@kbin.social
    link
    fedilink
    arrow-up
    5
    arrow-down
    2
    ·
    1 year ago

    “Here’s an icky piece of code, tell me what it does and what you would do to improve it” seems to have fallen out of style, though it’s not clear to me why.

    Because reviewing code is easier than writing it, unfortunately.

    • SirNuke@kbin.social
      link
      fedilink
      arrow-up
      15
      ·
      1 year ago

      I disagree with that as a rule of thumb. I’ll take writing 1000 lines of code from scratch every time over deciphering 1000 lines of bad code.

      However, I do you think are right if limited to the ~100ish lines that fit into an hour sized block of interview time. I suspect the other half of the answer is (good) job postings have largely gotten away from hard language requirements. It’s perfectly reasonable to hire someone that will need to familiarize themselves with Go or Python or Typescript or whatever. It’s not fair to expect someone to analyze code in a language they haven’t used on the spot.

      • szczuroarturo@programming.dev
        link
        fedilink
        arrow-up
        4
        ·
        1 year ago

        Even deciphering 1000 good lines of code is hard . I work in abap and 95% of my time is going through old ,or very old code written in diffrent programing styles . The rest is usualy writing a one or two lines of code.

    • floofloof@lemmy.ca
      link
      fedilink
      English
      arrow-up
      8
      ·
      1 year ago

      Maintaining a code base is definitely harder than writing new code, in my experience.