• 0 Posts
  • 17 Comments
Joined 1 year ago
cake
Cake day: June 20th, 2023

help-circle

  • Thinking about it a bit more, I think it’s more like the metrics used to get in front of a human (the automated/hr part) aren’t well matched to the actual goals. We end up interviewing a lot of people who are good on paper according to the first sort, but actual good hires within that aren’t as common as we’d like. But none of the engineers ever know about any of the people who were disqualified due to having an unimpressive resume…

    So in the end, the initial sort does indeed end up wasting time and money, but no one’s gotten around to making a good solution for this yet. The alternative so far is to interview a bunch more people, which is also really expensive anyway.

    Basically, we have no efficient way to find people who are bad on paper but are actually quite skilled.


  • That… Isn’t what I’m saying? I’m saying they won’t bother to go to the interview phase with those people most of the time because they have higher probability options to try instead.

    Usually getting in front of a human for an interview is the hardest step. Once you’re talking, you can generally show your expertise, and most interviewers I’ve known are receptive to any sort of past experience that’s techy and related enough, or even just problem solving related.


  • Just to put out the other side of this, you’re competing with a lot of people with more visible credentials. If the hiring manager can look through the stack and pick out 10 people to interview all with easily understood credentials, they have no reason to consider anyone else. Interviewing isn’t free for the company, every additional candidate to consider is probably at least an hour or more of time the company is paying someone for.



  • The Adobe photography plan costs me $120 a year, and honestly includes more useful updates than not. Their AI masking upgrades the last couple years are saving me hours to days of editing time per photo session.

    $120 a year is worth maybe one hour of my free time. Even just migrating to Darktable would take me weeks or months of dedicated time to migrate my existing catalog.









    1. Setup my vimrc.
    2. Clone the project, and realize that whatever repo managing system they started using 3 years ago requires setup steps not in the README and breaks everything at the slightest touch.
    3. Build the currently relevant project in whatever build system they started using 3 years ago (CMake is quite nice).
    4. Fix my vimrc to be compliant with whatever tabbing they use.
    5. Realize that for some reason, someone made a commit in the file I’m reading that uses 3 space tabs. And worse, someone approved that PR.
    6. Make changes via vim.
    7. Debug via print because setting up gdb or JTAG on embedded systems is usually more effort than its worth.
    8. Realize it’s a timing issue and reluctantly go find the JTAG debugger.