I certainly can’t speak for every situation - only from my own experience being a technical interviewer.

Open source work is a way to say “Hey, I know what I’m doing” - as far as projects, honestly, just work on stuff that makes you happy.

If its the right fit, the team has taken a lot of time crafting the technical interview experience. For us, our technical interviews weren’t designed to trick you and assumed you were nervous. The most critical part, for me, is that you worked through the issues, and discussed them, using me as a peer to bounce things off of.

Our interview process had 4 issues to work though, I’ll just describe what each was about

1. Can you find and correct a spelling mistake
2. Could you look at a partially completed unit test and complete it.
3. Could you filter out a piece of erroneous data.
4. Would you be able to spot an inefficiency?
   • If you didn’t, that’s actually OK. There was a harder way to complete the problem. It just told me what you might need to work on.

And honestly, that’s it. As analytical people, we often overthink things. You’ll do great!

we did tell you what the correct spelling was!

May I present to you… … GitHub - crate-ci/typos: Source code spell checker (I am not the author).

I should give some more context around it. Genuinely, IDC how you solved it. I just wanted you to open your IDE of choice or tool of choice to show me you know how to find something.

The issue goes something like “hello in Y module is misspelled as helyo. We’d like to correct the spelling to be hello”.

Yeah I get it, was just messing with you here.

I’ve gotten a good amount of compliments for knowing a lot of tooling which as you point out is just one more way to solve problems. The idea is to be able to solve the problems, mostly regardless of how.