High-pay or high-reputation jobs where the employer can be selective (FAANG, quant finance) seem to test for high IQ with interview "puzzles" (computer science puzzles of course).

Good employers, but who do not have more qualified candidates than they know what to do with, are already very happy with someone who simply has an interest in his job, as this is already rare enough. They pay attention to personal projects as signs that you actually belong in IT.

Government and, by extension, the consultancies that cater to them, pay attention to diplomas. Bureaucracies recognizing the stamp of approval of another bureaucracy, is one way of looking at it.

If you're going for a bigger tech firm, they're more likely to ask you to do the interview puzzle format.

Learning how to do those is a useful skill in its own right, even if they're "toy problems", because what you're learning is a process to break a problem down, and then make a choice based on your knowledge of data structures and algorithms about how to approach it.

Getting good at those puzzles means you flex muscles related to:

- Problem breakdown into logical steps, or what I now call "the useful thing CS50 actually teaches"

- Data Structures

- Algorithms

- Communicating your thought process on all of the above

Those skills are going to help you in any developer job, but might also give you more confidence to take on side projects you wouldn't otherwise. You might look at something out there and think "woah, I want to go figure that out", and now your mental muscles are slightly better trained for it.

What I want when interviewing isn't necessarily a good guide, but typically the technical skills are a baseline and then I want:

- People who can be mentored and aren't know-it-alls. A touch of humility about them. Finds pairing whilst driving scary but will try it.

- People who want to mentor others. Finds pairing whilst not driving scary or frustrating, but will try it.

- Able to work within a team towards a common goal

- Will take ownership and accountability of their own individual tasks

These are things you're more likely find from previous work experience and maybe in side projects, at a push.

I had side project and nobody cared when I was looking for job. Like, it did not seemed to matter or do difference.

One hiring manager let me talk about it more, but in retrospect he was basically nice to me and let me talk about it because I wanted to.

I agree with the people who answered before me. The smaller the startup the more important your side project could be. The bigger the company, the more streamlined the hiring process and the more likely that you would encounter puzzles etc.

I'd say if you're going for FAANG-type companies, definitely prepare for the puzzles and quizzes, but for a more smaller one (let's say sub-100 people) go for the side project approach.

Exceptions do apply obviously: I've had friends who got hired at FAANG because of a side project that grew and got the attention of the engineers at said company.