Programming

Bad advice in this thread. As someone who spent half a decade building what (was) a quite impressive GitHub (github.com/dginovker), no interviewer or recruiter ever looked at it. This was after ~600 applications.

I also volunteered to be part of resume screening at two major companies. Not a single person in either company looked at GitHub repos.

To answer your initial question, use a library. Make cool things, learn good tech that is useful in the real world. You will never have a job where you have to reimplement a hashmap.

It's better that you don't use resume driven decisions. Just do whatever you are interested in.

I've had to review resumes when we were trying to find someone else to bring on the team. My boss dumped hundreds of resumes on me and asked if any of them looked promising -- that's after going through whatever HR bullshit filters were in place -- on top of all the other work I was already behind on since we didn't have enough staff. That is the state of mind you should expect someone to be in while looking at your project.

If anyone looks at your repo, they're going to check briefly to see if you have any clue at all what you're doing and whether your code likes like it's written by the kind of person they can stand working with. Don't make any major blunders that someone would notice with a quick glance at the repository. Be prepared to talk about your project in detail and be able to explain why you made the choices you did -- you might not get asked, but if you are you should be able to justify your choices. If it gets to the point of an interview and your project looks like something that could've been done easily in 100 lines of Python you'd better believe I'm going to ask why the hell you wrote it in C in 2025... and I say that as someone who has written a significant amount of C professionally.

If you say you have multiple years of professional programming experience and send me a link to a repo that has .DS_Store in it... your resume is going straight into the trash.

If you’re trying to demonstrate real world programming skills then selecting and using an appropriate library is the best move (unless this is an unlikely case where there is some really compelling reason why a custom implementation would be preferable).

But if you want to make your own hash table for funsies or for educational purposes or whatever, you could add a note or comment stating that, if you’re concerned that prospective employers might get the impression that you will write everything from scratch even when it’s a bad idea.

Personally (as a dev), I wouldn't particularly care that you know a specific library (the chance of us using the exact same library is pretty slim and will probably change when the project changes). But I would care to see that you are using a library when it makes sense.

So, if you implemented a hashtable yourself and I spotted that, I'd remember that as you either not knowing that that's called a "hashtable", so you didn't find a library for it. Or I might think that you're potentially stuck-up, thinking you can do a better job implementing it yourself.

The aspects I'd look for, starting with the most important:

1. Does it seem like you have fun when programming?
   I don't need you to be writing humorous commit messages, but if it looks like you just specifically coded some portfolio applications three years ago and then never touched them again, that wouldn't leave a good impression on me.
2. Do your projects fulfill an actual need and look like they've seen real-world use?
   Writing out some example applications is a whole different shtick than actually making it work in the real-world.
3. Do you have unit tests? Is your commit log clean? Is your project reasonably documented?
   I can teach technologies and architecture, but it's much harder to teach a drive for good code quality.

I've only ever given a cursory look at personal repos when they're volunteered. I'm most likely to just look at a readme and maybe look at a small section just to see what the style looks like and if any characteristics stand out, then maybe use discussion of the project (with standard topics I ask everyone unless I happened to see something interesting) as a discussion starter.

In summary, at least from my perspective, I would recommend just doing whatever interests you and being ready to discuss, if you volunteer a project. I also generally think the impact of presenting a portfolio of personal projects tends to be overestimated.

Use a library if it fits your use case. Build your own if you enjoy it, or require some specialty features

Ermph, this is C specific and shouldn't be extrapolated to other languages. Since you're writing in C you are trying to show your chops as a low level programmer. Therefore, showing that you know how to implement a hash table is worthwhile, so you should do it yourself. You could add a comment to the code saying something to that effect. Again that's just for C. Implementing your own hash table in Python instead of using the built-in one would be crazy. Implementing one in C++ instead of using the stdlib or some other one would have to be carefully justified.

I do have to wonder what you are up to in this day and age, pursuing what sounds like junior level C projects. I would say that whole approach is something of a dead end. You're more employable with higher level languages than with C these days, I would have to say. Or if you write something in Python that incorporates some C functions that you write using Python's C API, that shows you can operate at multiple levels at the same time, which is even better.

How do you intend to present your GitHub portfolio to your potential employers? Nobody's going to do a full, in-depth, or even basic analysis of your repos unless maybe with automated tools or what GitHub itself provides.

Your CV and interview are much more important. Solutions [and projects] matter much more than details. Experience and that you can talk about your work or experience is much more important than technical details.

A hash table library doesn't sound like particularly noteworthy expertise. Adding a dependency and calling simple documented methods on it in a simple, standard behavior manner isn't noteworthy.

If you're implementing your own, I wonder if "simply" implies a non-noteworthy implementation, or in-depth exploration of hashing and storage indexing. The latter would be a different project though, putting your other on hold.

I don't see it making a difference for employers what you pick here specifically.

If you're interested in implementing one or learning about the technicalities of it go ahead. Otherwise use a library and continue with your project or other interests.

Disclaimer: I'm not in the recruiting space nor do I have that much or recent experience being interviewed/the broader companies hiring processes.

Think of your projects as a black box. I think it's rare people look at how they do things. Only what they can do. From that perspective, I think using libraries.

I disagree with most people here. The interview is the most important thing, so build it from scratch and make your own libraries. You will learn how to design good APIs which will make you infinitely more likely to get hired and promoted too.