What can I do as an amateur hacker to get the best programming job next year?
I spent about a decade on a different career path but have always done small python projects for fun (making games, writing bots for games, doing coding challenges). My current career is coming to an end and I have about a year to prepare for a programming job hunt. I was thinking of doing a portfolio piece since I don't have any real credentials, something like a full stack website that does some memey gpt stuff since that sounds fun but I'd like to hear any other ideas or advice
68 comments
[ 3.4 ms ] story [ 131 ms ] threadInstead, if you want to show your coding prowess, pick one or two repositories and link to those on your resume.
However, you'll want to be careful with this, especially never having written code professionally before.
I certainly didn't know what "professional" code _really_ looked like until I started getting reviews from folks much my senior and learned from them.
Another tangent to this is applying to software companies who target your previous career's industry.
EDIT: I see people recommending you not link your github. I disagree with this. Link the particular repositories you're interested in, no matter how developed or good. You're a self-taught programmer... nobody's going to expect you to be amazing off rip. Show something you're proud of for where you are now. Own it. You walk into an interview and you have one thing totally in control: you. Own yourself entirely, and your products. Explain your reasoning. Explain why you did things a particular way. "I don't know," or "I need more experience to better answer that question" are always valid responses. (DISCLAIMER: I am not an interviewer for any org and have never conducted a professional interview, this is just what works for me.)
But I think a Github portfolio from a relatively inexperienced developer says "I'm an inexperienced developer" first, and requires a recruiter or whoever to actually click into repositories.
Linking directly to work you're proud of avoids that.
Having a relevant degree from a prestigious or at least well-known university gives them confidence. Being able to come off as confident and knowledgeable in an interview gives them confidence. Having relevant work experience that shows you've done the job for other companies gives them confidence.
Generally, the better the job is -- more pay, more interesting work, better-known firm -- the more applicants they get and the more confidence they can demand before taking a chance on hiring someone [and it's always taking a chance, no matter the candidate]. Conversely, you find a smaller place, boring work, bad pay, they can't demand a lot of confidence because they don't get a lot of applicants to be choosy about. So you can walk into those places with nothing but your coding skills and get a job, and if you can do it, you can parlay that into a better job now that they have a little more confidence given your resume.
No job is the best job, but you will learn a lot about tech and software engineering at these places. Doesn’t mean it’s right for everyone. But it is worth having an unbiased view on this.
Other buzzword red flags:
mission, vision, teamwork, team spirit, offsite, messaging, team building, culture fit (more in startups), etc.
Many, if not all, of those buzzwords are corporatespeak or startup speak for "we want people to think and act (just) like us", or, IOW, "the nail that sticks up gets hammered down.
Get a mentor in that field.
Arm yourself with patience and perseverance.
Network regularly. Events, online communities, open source, whatever.
Complete some software engineering curriculum or two directly related to that field.
More or less in that order.
- A working website they built themselves that captures some personality for who they are.
- A small-to-large project they wrote or contributed on with others where I could view the source.
- Small edits to libraries (Documentation counts!) of things they use.
- A video of them explaining something (anything!)
An interview lasts one-hour. Getting as much across BEFORE that one hour is important. My easiest interviews were the one where I could skip the script and ask the person about some project I could see they were working on.
There will be lots of comments to say that none of these things are needed. They will be technically correct, but you asked for things that would make you have the best shot. A year is a nice long time to build up the above.
If I'm looking at a dev in a corporate environment, the meme-related toy projects are a good start (everything else being equal) but I'd rather compare apples to apples.
If I was interviewing you, here are a few points that I'd likely bring up if you showed me your code (again, this is just my opinion and I'm going to assume you're looking at junior dev roles here):
1. Show me how you handle malicious input (assuming forms on your site)
2. Show me how you ensure you don't add errors to previously working code (here, I'd be looking for an example of tests - they don't have to be comprehensive, or even all that good, just that you are thinking about it)
3. Do you have a datastore of some sort? Show me how you read/write to it (again, doesn't have to be a clustered Postgres infrastructure, it can be a text file but I want to see how you handle the thought process of reading/writing to a data store. So if it was a text file, you'd likely have some sort of lock when writing so do you handle errors when another user wants to access it, for example).
These are just things spewing out my head as I write this but I'd be looking for someone who is thinking correctly and perhaps has an idea of the kind of things that would be required in a corp env, not necessarily how to do them. So if your single unit test is a bit shite, but you actually have a unit test, I'd call that a big win (I'm sure I'm not the only one that's inherited multi-thousand-line codebases with no unit tests!!!). Likewise, you'd wrap certain code blocks in try-except blocks and so on.
Oh, I may ask you to code something simple, fizzbuzz for example too and, in all honesty, if you can do that, you'd be an ideal candidate!
Any/all of these things would put you high up on any candidate list I reckon.
Anyway, just my $0.02
I'm struggling to think of a scenario where this would be better than using sqlite, but I'm stumped!
It was more about getting him to think deeper than surface level: if I open a file, that means it locks so I need to then think about what happens when someone else tries to open the file etc.
It was a contrived example tbh.
If you're like me, I'd look for a job or open-source project that would let you work on those kinds of problems. Then your skillset grows naturally with each completed feature or bug-fix.
This requires you to build efficiently and securely. Build a real system, which you intend to acquire users. Even if you don't finish it, you will learn a ton. But if you do finish (you never will, but you know what I mean), and your project is solid, you may not even need to apply for a job (the most likely scenario is you get no users, but you still have an awesome project to showcase).
Add it to your resume:
domain.com | Developer & Founder
* Developed the entire system in modern languages
* Acquired 50,000 total users in 6 months
* etc.
Being an engineer != being an entrepreneur. They are disjoint skill sets, and one does not imply the other (nor should it).
Engineers do not necessarily care about managing a startup themselves, acquiring users, etc.
You do not need to present yourself as a "founder" of anything in order to land a programming job.
You can do all of these things with free and/or nearly free platforms. Currently playing with Cloudflare and Deno, which both have some cool factors/features.
It's a much better approach than lots of small projects.
Getting interviews after the first job I think is pretty self explanatory. Still spam applications but at that point you've already done this before.
FWIW, when I'm actively looking for work I will apply to maybe 10 or 15 places a day, often with cover letters that sound fairly bespoke (it is pretty easy to customize a generic template in a way that doesn't sound forced). It is not uncommon for me to have applied to 100 places by the time I'm busy enough with interviews to be comfortable stopping the application process.
I would also keep up with side projects and coding challenges. It will boost confidence and may help in interviews. Ultimately though it's believing in yourself and grinding to apply to enough jobs which will make this dream into a reality. Once you land your first job where you are actually coding you are basically set. It will open a ton of doors for you.
BTW a slower more reliable approach would be to start taking coding classes at a college.
If so, national labs in the US hire “graduate research assistants” who don’t get paid much but hey you’ll be working at a research lab which isn’t necessarily a good job but it can lead to good jobs.
For the above mentioned verbal argument to be more convincing, it does help to have some kind of undergrad degree, even if unrelated.
Not sure if they also hire non-grads but I wouldn’t rule it out.
Even if no sane person would implement a linked list in C during work, its still important to know how it works. As well as having a basic understanding how a computer works, how assembly roughly looks like and how this correlates to the abstract machine model of C (pointers mostly).
Then get some understanding of object oriented programming in typed languages (e.g. Java, C#). Check out the "gang of 4" design patterns, imo they make a lot of sense (in the rare case you need it). Although in my controversial opinion it is used way to often.
You can go further and think about how this actually works. Like Java classes are actually pointers to heap allocated objects. They python runtime is implemented in C too as far as i know.
You can check out the difference to dynamic languages like python and javascript and think about upsides and downsides.
Try to improve your coding style so it can be easily read by others. E.g. structure your datatypes in a senseful way and use many small functions. Uncle Bobs clean code book can be good for that (although probably controversial).
You could try to make a small project for everything you learn, and in the end select something you like and make a bigger project.
That's how I got my start in software. I automated a bunch of stuff at a small company I was working for, and used those examples when looking for full time work.
1) Shore up your formal learning in at least data structures, databases, and architecture. I took night classes at the local community college, but there may be better ways now.
2) Find something to hack on where you get useful critical feedback both on your design approach and code. Critical feedback on your work hurts, but it is necessary to grow. Open Source can work well for this, as long as it is some project you actually use for something real(ish) so that the contributions you make are driven by your actual usage.
3) Network -- join local user groups, go to meetups, be curious and engage with people there. Folks are usually thrilled to rattle on about the stuff they are interested in, listen, ask questions, care.
If you have a decade of experience in some domain, look for ways to leverage that experience in a transition into tech. My first job in this career was as a technical writer and trainer, because my previous career involved a LOT of writing, and I was good at it. My next job was at a company where I had a lot of domain expertise in their target market, so despite having limited technical experience in the role, I brought a bunch of domain knowledge to the table.
If you enjoy programming a lot and have time on your hands, you might find Recurse Center (https://www.recurse.com/) interesting. It's a retreat for self-directed programmers and I'll be joining the upcoming winter cohort myself.
I had no credentials when I started programming for work, but after several years in industry and learning in my own time, I think it's really worth finding a community to be a part of. Not only do many great opportunities come through chance encounters/personal relationships, it's simply a lot more fun to learn & build alongside others.