I'm in the middle of sending out applications and considering all the things I should refresh on. Does anyone have some good resources or practices they run through to get refreshed or otherwise prepared for technical and skill/personal interviews?

Ex. Sites, blogs, yt videos to refresh on data structures and algorithms. Checklist of things to look for when researching companies. Questions to ask recruiters during an interview. etc.

  • squirmy_wormy@lemmy.world
    link
    fedilink
    arrow-up
    15
    ·
    1 year ago

    I disagree with not saying "I don't know". I've interviewed people who refuse to say it and it's pretty easy to tell. And I've worked with people who don't know something and are afraid to admit it - often at the 11th hour, they have to be rescued. It's pretty aggravating IMO

    Ultimately, I'd want a team member who was comfortable with admitting that and then had methods to find the answer.

    • thelastknowngod@lemm.ee
      link
      fedilink
      arrow-up
      7
      ·
      1 year ago

      I had this just the other day actually. I am in SRE and the overwhelming majority of the code I write is terraform, instructions for a Dockerfile or CI pipeline, or just some random ass bash to compile information… I don't actually do that much coding at all and what I do end up doing is pretty rudimentary.

      EVERY job interview I go on though wants to do some leetcode style code puzzle. The one I got the other day I just said to the guy, "I honestly don't know how to do this. The code I write isn't fancy or clever. It's mostly just to get things done." We worked through it together though and I understood the logic by the end but they were mostly holding my hand. What I was doing was throwing out ideas and trying to work out pros/cons with the interviewer. That was enough apparently because he green-lit me for the next round…

      These type of interview questions really annoy me because they are not representative of the job in any way. In addition to work, I also have a life that does not involve computers. After putting in a 40 hour week on engineering stuff, grinding leetcode over a weekend is a hard sell.

    • JackbyDev@programming.dev
      link
      fedilink
      English
      arrow-up
      6
      ·
      1 year ago

      They said "don't just say" so they mean like "I don't know but I think I've heard of that and blah" or "I'm not certain but I've worked on X which is similar so I think I could pitch in easily"

    • deeroh@lemmy.sdf.org
      link
      fedilink
      arrow-up
      3
      ·
      edit-2
      1 year ago

      I'm sure individual interviewers have their own styles, but yeah I'm with you here. Few things are more frustrating for me during an interview than wasting 30 minutes going in circles on something because the candidate isn't being honest with me.

      Our role (low level software) is going to be full of things they haven't seen before. I would rather have a candidate who can quickly identify that they don't understand something, and likewise quickly try to fill that gap so they can move on to the next thing, than have someone try to bluff their way through.

      I understand that there's a level of "fake it til you make it" during interviews, but the goal of the interviewer is to get as much signal on you as a candidate as possible. Admitting you don't know something may not feel good, but then it gives the interviewer the opportunity to test you on different things that could really highlight your skills. For example, we ask questions on multithreading during our panel. If you don't know how a semaphore works, and you tell me that upfront, that gives me the opportunity to explain the concept to you and see what your process is like working through new information.

    • atheken@programming.dev
      link
      fedilink
      arrow-up
      2
      ·
      1 year ago

      I take what they're saying as "don't just give up/refuse to answer" - it's fine to say "I don't know, but I have a guess on how I'd start/find out" and try to work through that. In a real working environment, this is more how it'd work, and if someone truly didn't know where to start, usually the co-worker would try to help, which is not always how interviews go.