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.

  • varsock@programming.dev
    link
    fedilink
    arrow-up
    25
    ·
    edit-2
    1 year ago

    fantasize of all the ways I can hand in my resignation.

    Then 3 months go by and still no offer, lower the bar and fantasize of all the ways I can hand in my resignation - but nicer

  • cmbabul@lemmy.world
    link
    fedilink
    arrow-up
    17
    arrow-down
    1
    ·
    1 year ago

    If it’s a video or phone interview I take a shot 10 minutes before start time, loosens me up and helps me to be less in my head. Hate encouraging alcohol use to anyone, but it’s always worked for me

    • skybox@lemm.eeOP
      link
      fedilink
      English
      arrow-up
      9
      ·
      1 year ago

      HAHA I wonder how many people do this. Does sound kind of useful.

      • cmbabul@lemmy.world
        link
        fedilink
        arrow-up
        6
        ·
        1 year ago

        Booze lowers inhibitions, that’s not always a good thing, but in a situation where you really want to impress it’s not uncommon to be stiff and visibly nervous, which is counterproductive. Smoothing that edge a bit when the situation calls for is using alcohol as a tool, just remember any tool can be dangerous if used improperly

    • MonkCanatella@sh.itjust.works
      link
      fedilink
      arrow-up
      5
      ·
      1 year ago

      Hate alcohol but some klonopin an hour or two before is magical. I swear it’s been the reason I’ve gotten offers. CBD tincture or a joint with like 9:1 CBD:THC can also do wonders.

  • Hillock@kbin.social
    link
    fedilink
    arrow-up
    13
    ·
    1 year ago

    Head over to the website of the company go to the about section and read about their values. They usually list something like teamwork, communication, working autonomously, speed, or quality. You pick 2-3 of these values and that’s what you talk about when they ask about yourself.

    For the actual technical part it’s hard to prepare for. Most people don’t actually care about you being perfect but just want to see if you actually are familiar with what you said you are. So as long as you have an idea what you are talking about you will be fine.

    Even if you don’t know the answer, just come up with something that could work. Don’t just say you don’t know. Explain your train of thought as to why your solution could work. And any other ideas you might have.

    • squirmy_wormy@lemmy.world
      link
      fedilink
      arrow-up
      9
      ·
      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
        3
        ·
        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.

      • deeroh@lemmy.sdf.org
        link
        fedilink
        arrow-up
        2
        ·
        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
        1
        ·
        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.

      • JackbyDev@programming.dev
        link
        fedilink
        English
        arrow-up
        1
        ·
        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”

  • squirmy_wormy@lemmy.world
    link
    fedilink
    arrow-up
    9
    ·
    edit-2
    1 year ago

    I generally read through my resume and prepare extended blurbs about the projects/responsibilities I’ve written about - after all, that’s really all they’ll know about me at first.

    Then I think of more detailed things throughout my career so far that wouldn’t be resume-worth, but that I’m proud of or learned from or whatever. Just to have a bit of a script for that side of things.

    I make sure I’ve got good enough answers for the basic interview questions: biggest strength, weakness, hobbies, projects outside of work (and why I don’t do them), best project, worst project and why, etc.

    I try to have 2-3 questions to ask them at the end. Sometimes I don’t really have many good ones, so I make a note to make some during the interview itself - asking about tech stack details is usually a good springboard. And I genuinely will make a note to myself to remember that because I know that I can flip into autopilot and not be very chatty.

    The rest for me honestly is just rehearsing that basic script enough to let it flow casually so that I can spend my energy on listening and interacting with the interviewers (and being in a good headspace for any technical questions that pop up).

    When I’ve not done that step, because of the nerves from being on the spot and with new people, I tend to come off kinda stuttery and unsure of myself. And it’s all about confidence, babyyyyyyyy

    *Edit: this is interviewing for a job where I’m comfortable with the roles and responsibilities. If I wasn’t as confident in my abilities, I’d also spend significant time doing general studying on those parts. But I’d also be ready to say that I didn’t know something yet, but I have a track record for being a fast learner, such as when I blah blah blah…

  • Marek Knápek@programming.dev
    link
    fedilink
    arrow-up
    14
    arrow-down
    6
    ·
    1 year ago

    The interview starts … the interviewer asks me “Tell me about yourself.” … I respond “Did you receive my CV? I put all important details about me … right there. What questions do you have about my past jobs?” The interviewer encourages me again to tell him about myself, my past projects, etc. … Me: Awkward silence. … Me to myself: Dafuq? Should I read the CV from top to bottom OR WHAT?

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

      I’d rather they ask me a question on something for which I’m an expert (myself) and that I can prepare for, than to fire off leetcode question.

      Yeah, it’s a little bit redundant, but it can break the initial tension and get the conversation going. You can also use the time to emphasize some specific aspect of your work history that you think matches up with the job req, or shows why you actually want to work there.

      If they don’t ask this question/prompt, what question would you want them to ask?

    • A_Dude@lemmy.ninja
      link
      fedilink
      English
      arrow-up
      1
      ·
      1 year ago

      They’re asking not for the info, they are asking to see how you communicate (ie “soft skills”). Your response immediately demonstrates that you do not like people, are probably a PITA to interact with, and will have a hard time collaborating with any other humans who do not think exactly like you do. The good news is that soft skills are skills, and as such they can be learned and improved on.

    • varsock@programming.dev
      link
      fedilink
      arrow-up
      3
      ·
      1 year ago

      when you say whiteboarding do you include programming tests or take home problems?

      I stay away from FAANG like companies but my experience is everyone asks them. I’m curious what kind of roles don’t - how can I keep an eye out for them?

  • MonkCanatella@sh.itjust.works
    link
    fedilink
    arrow-up
    6
    ·
    1 year ago

    I have a couple. The first one is the easiest. Absolutely not a god damn thing. I just chill. That’s gotten me offers. That works for me because when I over think it or over prepare, the part of me that’s actually good kind gets buried under all the shit I’m trying to remember.

    I’ve never once had slamming leetcode shit do a god damn thing for me.

    For the “culture fit” aka behavioral interviews, they almost always just ask you to describe some projects, and then poke around so to speak. Sometimes they ask dumbass questions but it’s fine, it happens. This is where preparation is helpful if you’re anything like me, because for me, once a project/feature is done, it’s on to the next thing. I don’t spend time writing down my accomplishments and I think it’s gauche. But if I did, it would be very helpful for these interviews. What I’ve begun doing since the market has been so garbage is organizing using a note app (logseq). I make an outline with sections for types of projects or type of positive attribute the project/task would showcase. then I write myself a little story (they basically just want to hear a story that confirms what they’re looking for). I have examples for being able to “hit the ground running”, mentorship/leadership, and projects. For projects, my most comfortable flow is to describe the business practice before hand, the goal or reasoning behind provisioning the feature/change, the part I had in it, and the impact it had. Here’s the trick. Just make it up if you don’t remember. Embellish. Don’t be moron because they will ask clarifying questions. for example they love to hear concrete specific numbers. They’re not gonna check but it adds that extra something. Just btw make sure you’re very comfortable with the embellishments you make. Like don’t make up that you invented a compiler for rust that improve efficiency by %2,000. But don’t diminish your own accomplishments just because every last detail isn’t crystal clear to you several months or years after the fact.

  • manapropos@lemmy.basedcount.com
    link
    fedilink
    arrow-up
    5
    ·
    1 year ago

    I’m here because I’m interested. I’ve put in so many applications but have had no interviews despite 3 years of experience and a masters degree. Y’all let me know

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

          I think you can phrase a lot of these more strongly. For example,

          Provided 24-hour production support resolving issues with said system one week out of every month. Resolutions involved checking production Splunk logs, issuing bug reports, and pushing bug-fixes to production

          • Receive alerts and triage issues with Splunk to identify problems in a timely manner
          • Perform root cause analysis of production issues and apply hot fixes to production to ensure timely delivery of critical notifications so customer value is not impacted
  • JackbyDev@programming.dev
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 year ago

    I usually skim the Gang of Four design patterns because that’s something people love to ask about despite it not necessarily being something folks need to memorize for work.

    I think the most important thing is to think of or look up interpersonal questions like “tell us about a time you got negative feedback” and have moments ready to talk about. If someone is asking me about HTTP verbs I know a lot off the top of my head but things like that I usually have to actively think about to remember.