Hacker News new | ask | show | jobs
by linuxlizard 2653 days ago
I am not a recruiter but help with software/firmware interviews where I work. When interviewing someone, any and all signals are very useful. For someone fresh out of university, they can show me their student projects. But an experienced engineer, their contributions are usually property of their previous employer and can't be shown.

To me, being able to see an interviewee's code is like being able to see an artist's portfolio. Alternatively, if an interviewee can point to mailing lists, code repos, etc, for open source contributions, that also is very valuable.

Some other folks in the comments are saying they use Github, etc, as a dumping ground for projects. Still valuable. In my opinion, that means you're interested enough in the project to at least save the code. Plus, even quick and dirty code can have valuable information. Does this person understand, for example, the common idioms in C, C++, Python, etc? (Specific example, using malloc/free/printf correctly, new[]/delete[], not using for i in range(len(foo)). Simple stuff like that.)

Note a repo containing "this is code where I'm learning this language, this library, etc" won't have the best use of the language, obviously, but will be a good sign this person is learning something new. It's another signal.

Just my opinion.

1 comments

Noob question: Why is it bad to use for i in range(len(foo))? Because you can just use for bar in foo?
It's mostly a bikeshed and a signaling thing. Only a "noob" wouldn't know about enumerate(), right? The program could be brilliant in much higher level ways, but mid/senior only-knows-Python hot shot will jump on your anti-idiom like a dog on a dropped hamburger. Including such anti-idioms in your public code can filter out people like that.
Where are you meant to learn this?
Python's list of built-in functions is fairly small https://docs.python.org/3/library/functions.html#built-in-fu... (but to be clear, I wouldn't ding somebody for forgetting about one of them).
Reading other people's code (usually while improving it)
https://docs.python.org/3/

Consider that your iterable may not be a list, and may not actually have a "length" prior to its being consumed

Yes. Iterating over a range of integers equal to the length of an iterable is really clunky compared to iterating directly over the iterable. Plus, if you actually want to use one of the elements of the list, for instance, in the body of the loop, you would have to do foo[i] instead of referring to it as bar.
And when your actually need the index, generally you use enumerate(foo).
It's not "bad", but it's generally unnecessary. And breaks on generators.