I'd certainly consider you for an interview (you show actual development ability and an understanding of some important concepts in your work, which is much more than many interviewees), but speaking frankly, the profile is a little weak - it consists mostly of experimental or toy stuff without any kind of evidence of real-world application, no tests, nothing that's been packaged up for use by other people. These aren't bad, by any means, but by themselves they aren't something I'd look at and say "I want this guy working for me".

You don't have a lot of collaborative work (read: contributions to existing projects) or original work that others are using, which is one of the things I look for in candidates. I'm not just interested in a candidate's ability to write code, but in how they write code in the context of large projects, how they produce deliverables for consumption by other developers and stakeholders. Your Github profile isn't just a chance to showcase your ability to write code, but a chance to showcase how you write code with other people involved. A candidate who is actively contributing pull requests to other projects is very interesting to me, because they demonstrate an ability to collaborate with other people on a codebase they didn't originate, which is obviously necessary in business.

Your commits are clean, though, which is very good. I see way too many candidates with message after commit message like "stuff" and "changes" (anecdotally, I've found this to be pervasive in newly-minted CS majors and academic repositories). That's a major negative for me, because it suggests a lack of desire or ability to communicate the essence of your work.

A strong history of open source participation and/or a strong history of development of a personal project that is actively used somewhere are the biggest things I look for, because they speak not just to your ability to write code, but your ability to ship deliverables. After that, I look at code quality (cleanliness/use of idioms/lack of obvious bugs or errors) and commit quality (how disciplined are you in your commits, how well do you communicate what each change is for). The lack of those things isn't a "no" for me, but their presence is a big "yes".