Ask HN: How does a hobby programmer get hired?
I've been tinkering with code since a young age and I like thinking my way through problems and understanding the way computers work, but I've never had a programming job. For the longest time, I went in other directions even though I enjoy it a lot, because I was told that I shouldn't spend my life in front of a computer. It turns out that I do that anyway, just not being paid for it.
Without any programming jobs on my CV, what is a good way to penetrate into the market? I've had job interviews where I did a bunch of coding challenges (and passed), but didn't get accepted because of lack of experience. I considered that maybe I need to do a bootcamp as an initial way to back my skills up.
258 comments
[ 3.1 ms ] story [ 161 ms ] threadAnother option is to figure out an area that interests you and build something interesting (even if simple) and release it online. It's ok if it's released for free with no way to monetize it, your goal is to show you can program something non-trivial from 0 to 1.0 (both in terms of skill and wherewithal).
I had used a few other languages before but hadn't done much in the way of web stuff (this was almost 15 years ago)
I'd say try to find places that are looking for people that know things that you've been playing around with. Bring code to show them and be prepared to demonstrate what you know but don't pretend to know anything you don't.
Good luck!
1) Ship something. "App Stores" make that easy. Interviewer can easily download your app(s) and have plenty of material to ask you about during the interview.
2) Get hired into "QA" — preferably for a position that allows you to write (code) tests. Many of our "testers" where I worked moved into engineering when they were seen as willing and able to make the move.
In my experience, this never happened.
I strongly suspect that was because they had already decided they weren’t going to hire me (I was 55, when I was interviewing), and didn’t want to waste the time.
Here's my GH ID: https://github.com/ChrisMarshallNY
You can easily see that I faked over a decade of checkin history, dozens of repos, in multiple organizations, over 20 shipped apps, lots of blog posts, tutorials, class modules, etc.
I know that my generation (and the one before) have caused many issues, but I'm not your typical "OK boomer."
But it is not enforced. Tech companies don't bother to hide it at all. They run job ads that all but say "Bros only."
When money is being made, the authorities tend to look the other way. That has been going on in the finance industry for decades (and don't get me started on crypto).
There good cause for "the law" in daily reality (as opposed to "The Law" as an abstract good) not to be held in any esteem by ordinary folk.
I don't know the context of how that came up, but I'd probably let the recruiter know of their unprofessional behavior if that happened to me.
In my case, since I had been experiencing veiled insults and condescension from almost every interviewer (and being "ghosted" by recruiters, when they find out my age), I just said "Bugger this for a lark," and decided to retire early.
I doubt anyone misses me, but I am pretty sure that I could have helped at least one of the companies from going titsup.
However, I gave the opportunity to a few, and they ignored it. In at least one case, their ignoring it was a fairly blatant move to get me to give up. It worked.
Other than that, you could try building out a successful product or freelancing for some time.
How do you find opportunities?
Go to LinkedIn, search for staffing companies, and message their recruiters letting them know you are available. They will ask for a resume. However, a contractors/consultant resume is different than a salaried resume. You are open to include projects you’ve worked on in detail without them being part of a “job”.
Do you have a portfolio? If not, a small simple one works.
Bootcamps won’t help.
Feel free to email me. Happy to support you through the process.
Personally I'd just ship some crapware on the app store of your choice and spin it as a 'venture'. As others have noted always nice when they can play with your skinner box rather than glaze over when they see a Makefile.
Over time I kept some good contacts from there and supplanted the low paid jobs with better clients.
Many developer-types seem to have personal sites these days that cover that kind of stuff.
I'm not a hiring manager, but I've led lots of interviews and this, IMO/E demonstrates competency in a few areas (this varies depending on how the site was deployed):
- basic comprehension of "web stuff" - what "hosting" means in practice (registering a domain + setting up DNS, some sort of service/server to host your assets) - some means of deploying it
It's often a good conversation starter too--you mention experience (maybe something on your "blog"), interviewer asks about it, conversation pivots to how you set the site up in the manner you did:
"I chose $FRAMEWORK/simple static assets and hosted on $SERVICE as I felt this was a straightforward way to host a site, and I like how $OBJECTSTORE makes hosting easy opposed to setting up a server to just serve static assets."
Personally, I like talking about that stuff so it's always a good talk when that comes up during a candidate interview.
There's a lot of potential in those conversations, especially given a large portion of software-type jobs are web-related today.
Also, regarding the comment above, this is likely helpful if you're a consultant where you can advertise your services more explicitly.
Next, consider getting a certification or two. For someone with no experience or formal education in development, it can help.
Finally, if you're losing out to more experienced candidates, then maybe consider applying to true entry-level jobs to get your foot in the door, where experience is not required.
The other way around applies too: if a job simply needs you to show them that you can do the work, a portfolio can be enough, just like getting a contract job with a supplier can be (technically that'd be like a portfolio with internal stuff they already know about).
For jobs where you primarily need to be able to do the work:
That last bit can be hard since contract work usually doesn't allow you to talk about what you did in detail.You don't need to do a bootcamp (and I'd argue it would not help at all) rather you need to ship something and then layer that with previous non-programming job experience to demonstrate that you can deliver things as part of a team. My greatest value (as a software engineer) is in the non-code value I bring to my team. Given the choice between 2 candidates, 1 with only experience as a software engineer, and 1 with experience of non-programming jobs, I'd be giving strong consideration to the person with a broader range of experience. Leverage your non-programming work experience to show that you can deliver value.
Regarding passing coding challenges: coding challenges are a very lazy method that companies use to filter out candidates. Passing a coding challenge is easy and doesn't mean much (they're also just as easy to fail) so don't focus on them at all. Your focus should be almost exclusively on interviews, and you should work towards giving the interviewer as much confidence as possible that you'll be a valuable member of their team.
Also, don't assume that levels (junior, mid, senior) correspond to the amount of programming job experience you have. If you can ship code yourself, you're already mid or senior level at most companies.
Then you also need to be able to get your boss, stakeholders, etc. tasks and needs into account to build something for them. As advice here, you could probably try freelancing to get more knowledge. As a hobby, now you get an idea and have self-learned how to implement it. With clients or bosses, you need to get them to explain the idea, and go back and forth enough to understand it well enough without becoming annoying/more trouble than it's worth. Some clients will delegate more and give you more creative freedom, some will delegate less, and both might have different abilities to express their thoughts. It's your task to make sure you understand it all and are able to execute on their idea, complementing it with your creativity when needed.
If you are in a good enough position, I'd start trying freelancing for family and friends small business at a discount, then try to get more and more real-ish clients. Once you have become good enough at freelancing that you are ready to find a job, you might even be able to convert some of those freelancer jobs into part or fulltime jobs, or at the very least showcase your work so far. I did that with a couple of internships and then a bit of freelancing.
Note: this advice won't get you in Google, but IMHO it's a good path to get in the industry.
Completely disagree: in plenty of other jobs people learn to get things done, and how to work with peers/bosses/reports. There is not much signal about the OPs soft skill level so you are making an assumption.
Interpersonal skills tend to be strongest in people that are always working with others (particularly clients and peers) rather than sitting in front of a computer. I would rather work with a cook/hairdresser/etc that became a software programmer than developers completely lacking in motivation or lacking interpersonal skills (I have had the distinct displeasure of working with plenty of low-EQ developers in my past).
There are specific interactions in software that are somewhat specialised. However the generalised interpersonal skills are what it is difficult to be good at, and the specialised software soft skills are learnable. (Edited: clarity)
Neontomo wrote in comments (perhaps after you commented): “I'm 29 and started working at 18! I've worked outside the service industry too (recently at Apple) but yes that's my main experience.”, and “I did some work for a hotel and sped up their marketing and IT stuff quite a bit with automation”.
And georgyo wrote “There is a lot of comments, but no one took a moment to look at your profile and visit your website.” —— I always forget to do that! Even though I sometimes backtrawl all comments by a particular hn user (which might have been useful in this situation).
> without resorting to the internet
Asking for “expert” (?) advice on HN seems like a reasonably skilful approach, if used with other information sources (hard to know given we don’t know their context). It looked to me that they got heaps of really valuable feedback, validating their approach?
To me your second comment seems to repeat the mistake of the first. I hope I don’t come across to you as foolishly critical - I think we are all trying to help!
In my previous job I was highly respected, both technically and as a technology PM, but I still failed to sell many candidates without a good paper background.
"Her degree is in music? That's not great.", even though it was science focused, she had several acoustics and waveform analysis projects, strong math background and would fit well in our signal processing group.
Something must be wrong with me then because I've been programming for decades in multiple areas productively, but successfully completing three leetcode medium/hard within 45 minutes while also talking through my thought process is not something I'd call easy.
> so don't focus on them at all
I'd suggest most people aren't going to get past the first level if they follow this advice.
As for the OP though, since they already passed coding challenges, the advice might be appropriate for them. I'm actually surprised that there was no offer on any of the interviews where "a bunch" of coding challenges were passed.
> If you can ship code yourself, you're already mid or senior level at most companies.
I'd go with this idea. Make it clear that you can ship. If you can complete coding challenges, then you should be able to make a small game. And a decent website. And a SaaS project. And so on. Get a portfolio going.
If you're consistently failing coding challenges, you have a couple of options.
1. Find companies that don't use them. 2. Push back against any coding challenges and instead offer to complete a small project for them that you believe will represent the way you work in totality -- advocate for the pointlessness of coding challenges and encourage the company to change their practices. 3. Cheat (and in the unlikely situation in which you're caught, just say "I solve problems by googling, like any good software engineer") 4. The worst option is to waste your time grinding through leetcode etc. and become good at passing these dumb coding challenges. I can see why that option appeals to us (it feels like a video game, like we just need to practice more to level up) but it has nothing to do with software engineering.
The fact that no offers were received by the OP after passing coding challenges should show how little they're thought of by hirers: they're a lazy half-baked way to exclude a bunch of applicants and feel like it was helpful / fair / meritocratic. A company using coding challenges may as well just randomly select 20% of applicants to go through to interview.
Imagine you work at a company that uses coding challenges as part of their interview screen. Imagine they need to hire someone for your team. Imagine you worked with someone in a previous job who is an amazing software engineer and you know they would provide incredible value to your team. Imagine that person fails the coding challenge. Would that person get the job or not? In any rational company, you would just discard the coding challenge result, because you have a much stronger signal: one of your team is vouching for them. Any company willing to disregard a candidate because they failed a coding challenge is a company that is falling far short in their ability to hire the best people. For some companies, they don't care about hiring the best, they just need a bunch of people who can meet the bare minimum coding challenge requirement, but that's not a company worth working at.
They’re not meaningless. I worked as a technical screener for a recruiting company a few years ago. We interviewed thousands of people and had good data on this stuff. Programming challenges had high signal - doing well at ours was positively correlated with all the other parts of our quantitative assessment (knowledge, software anrchitecture, etc) and ultimately with getting hired.
There’s a reason they’re popular. It’s not all cargo culting.
The problem with coding challenges is that they do not require the same skills that software engineering requires. The value of a hired software engineer is measured over many years, you can’t possibly measure the success of a prospect based on whether or not they get hired.
You could hire a dozen people who grind leetcode all day to be one team, and hire 2 people who wouldn’t pass a coding challenge screener to be the other team, and the latter team could very plausibly out perform the former team over 12 months.
My experience is that a company that has designed a hiring process that does not require a coding challenge has a much higher quality team because they’re not relying on something as arbitrary as a coding challenge. Instead, they’re assessing candidates on what is actually relevant to the company.
They’re popular because they’re an easy way to cut down numbers, which makes them feel effective.
Great question - what is relevant to the company? This is the #1 purpose of technical screening: To assess whether the candidate can do the job you're trying to hire them for. If the job involves programming, one of the things you need to assess is whether the person can program.
Telling me your job history, verbally solving hypothetical architecture problems, or pointing to a github repository with some code in it does not assess whether you can program. All of these things are good signals, but past experience can be misleading, and github activity is trivially easy to fake.
I've interviewed over 400 people. All of them passed an automated screening process before they talked to me. About half of the people I talked to failed to solve a simple 1st year programming problem, using their own computer and their favorite language in the half an hour we allotted to the task. Beginners I understand, but its shocking the number of people who have somehow worked in the industry for 20+ years yet only seem to be able to paw ineffectually at eclipse when you ask them to write fizzbuzz.
Any interview process that doesn't screen these people out is useless. Its harsh but, if you are one of these people I love you but I don't want to hire you.
Lots of people seem to hate programming challenges. But I've yet to hear a viable alternative. Whats yours?
And coding challenges... have integrity? If someone goes to the effort to fake GitHub activity (whatever that means?) then why would they not also go to the effort to cheat in a coding challenge?
You can learn more from past experience, job history, hypothetical contextual problems and GitHub repositories than you can from a 45 minute fizzbuzz exercise. If you cannot assess a candidate by having a conversation with them then how on earth do you expect to be able to work with them? If you need a fizzbuzz exercise to trust that they actually know what they're talking about (which, again, proves absolutely nothing other than their ability to do fizzbuzz) how can you trust them in a collaborative setting?
The success of a screener cannot be measured by how many people in screens out, otherwise, the perfect screener for Software Engineering would be the ability to jump 20ft in the air from sitting down.
> its shocking the number of people who have somehow worked in the industry for 20+ years yet only seem to be able to paw ineffectually at eclipse when you ask them to write fizzbuzz.
So either there's an epidemic of people who can wax lyrical and provide meaningful insight into software engineering in a professional context but haven't actually worked in the industry... or you're churning through a dry checklist exercise of common interview questions that anyone who does the bare minimum preparation could answer.
The point I make (to technical and non-technical people alike) when I'm involved in hiring is that if you cannot qualify a software engineer in a conversation then you're asking the wrong questions. Most people interviewing software engineers have no idea how to effectively assess someone, and in my experience end up reading off some list of "software engineer interview questions". The reason supposed experts can pass these interviews and then fail at actually programming is that the interviews are terrible, and they're just being asked questions they've heard a dozen times before because someone half-assed the process and found them via a "software engineer interview questions" blog post.
If you need to know that someone can write code and you cannot confidently assess them in conversation, that's fine, not everyone has that ability, but the solution is to have them tackle a small contextual problem as a project (and pay them for the day of work) and not give them some arbitrary challenge that does not represent the real world.
Coding challenge fans make the mistake of believing that there needs to be some step where you have an applicant do a little dance to prove that they can write code, and so a coding challenge is a natural and necessary part of the interview process and that anybody objecting to coding challenges has to provide an alternative that will have an applicant do a little dance to prove that they can write code.
I've attended lots of interviews in my career, on both sides of the table, and I know exactly why coding challenges are used: because the rest of the process is so bad that someone who couldn't write code could easily get through. If you need coding challenges to prevent that, so be it, but it's because your interviews are bad.
The fact that there's an entire cottage industry of leetcode training and people who spend months "grinding leetcode" should be evidence enough that coding challenges test a candidates ability to... do coding challenges.
And, for the record, when I interview software engineers, I send them the questions I am going to ask in advance so they have time to research and prepare because that's what the real world is like... and I remain confident that even then I can still assess them effectively.
I think doing some Leetcode type challenges are important at some point - they open a door in your brain around problem solving, but that door tends to stay open thus grinding those challenges to me offers diminishing returns - if people get more out of them and enjoy them that is great, but I think anyone who has had the thrill of solving hard problems to contribute to a high quality project with real application has a unenthusiastic feeling towards Leetcode type challenges and the hollow achievement from finishing them relative to real work.
Leetcode has zero correlation to your practical working life, code challenges are what you would do in a normal day at work.
I never prepared for code challenges; if I had to prepare for leetcode I'd need a few months to have any hope.
I prefer more realistic scenario type coding interviews (ie implement a new feature, fix a buggy function, etc), but in any case it is impossible to actually verify what a candidate actually coded in their previous jobs.
I think technical assessment needs to assess lots of skills, but obviously one of the skills to test is how good someone is at programming.
There’s a few ways to do that - my personal favourite is to have a few hundred lines of buggy code with failing tests and ask the candidate to debug it for you. But from the data I’ve seen, asking someone to code something from scratch also provides a lot of signal even if you also get them to debug something. (If you were going to pick one test, coding from scratch is a better assessment for juniors and debugging is better to assess seniors).
But I think some form of practical programming assessment is necessary. You won’t learn if someone can program well by talking to them. And take home programming tasks are too easily gamed.
I do think you should make the programming challenge relevant to the job though. If you’re hiring a frontend dev, get them to make a webpage. A backend dev? Get them to make a set of rest endpoints wrapping a simple database. Algorithm challenges make sense for systems programming, or when you’re hiring generalists at FAANG and such.
(Source: I’ve interviewed over 400 people and worked with data scientists who looked at the per question results.)
Whenever I encounter that at work I research the topic extensively and learn or re-learn whatever it is I need.
I completely agree on testing on real tasks, given some candidates who perform terribly on those manage to squeeze by (even thanks to them passing leetcode bs interview without having real world experience).
Algorithm problems are based on the philosophy that if you can implement a binary tree in 20 minutes, you’re smart enough to figure out just about anything else that comes up. They were popularised by Google, who hire with the goal of never hiring incompetent people even if it means missing out on some good people.
There’s two problems with algorithm problem interviews:
1. All the people who do great at this stuff can make $300k+ at cashed up companies. There are not many people like this who want to work for you.
2. There are plenty of people who will do a great job fixing issues and adding feature to your web app who don’t know what a B-Tree is. You probably still want to hire them.
So yeah, I agree generally with the advice. Most programming problems given in interviews should be relevant to the actual job on the ground.
You can probably learn more by wrapping it as a tiny 'project' note: not a take home -- just a DSA/LC style 'problem' diguised inside a git repo. I'd rather see 2Sum with a Cargo.toml in a repo, seeing them scaffold this in the lang of their choice, or within an existing codebase.
Justifying the full end-to-end "how is this going to be deployed and maintained", "how would you test X" is a bit more informative than "please repeat Djikstra's algorithm into the void".
Of course, being good @ LC in isolation is still a proxy for (math) intelligence perhaps unpopular - but in SWE being smart isn't enough, you gotta grift, ship or hustle your way through; thinking is mostly optional.
Essentially, there's 100 different things you need to know to do your job well. The job of a good technical interview is to give you a (biased) sample from those 100 elements of knowledge. So, some practical programming work. Some conversational - "how is this going to be deployed and maintained". Etc.
1. You can answer basic coding questions 2. You’re able to work on a team 3. You have some soft skills to work with customers to learn about what they want, so you can build it for them
The first step is to get that interview with the above resume. Then when you interview be sure to be transparent about your experience and interests and your desire to continue learning. If you’re working with _good_ hiring managers this is the most important thing to them.
Working on some simple AI projects to add to my portfolio as a start. OpenAI APIs are pretty easy to use.
You can then parlay that into a software engineering job or even a more ambitious SaaS.
Unless a specific job you want needs a specific certificate, don't pay for them. Your employer probably should pay anyway.
Make a nice portfolio of projects, or contribute to open source projects. That's your resume.
You'll always have trouble getting hired in government or big companies without a degree, tho.
Having said that, the job market wasn't as rough back then as it is now.
Pick one.
Too much screen time if you do both.
love your username btw.
They did try to route me into QA first, but I ignored that and none of them were technical enough to know the difference.
I've had people on HN tell me that this path is the most horrible path to recommend to people, yet at the same time -- it works. And you make a living while getting your skills up.
I’d also suggest changing the tone of the website a little. You say, “Take a moment to browse through my innovative ideas,” and then link to mine sweeper that uses sums instead of numbers? I kind of expected more from the description, and if I were looking as part of a job application I might start to doubt other things you claim. If you’d just said Minesweeper with sums I’d have come away with a much more positive impression.
I think you have a few possible paths (many mentioned in sibling comments):
Ship something at least slightly novel of your own. Could be a web site, a web game, a mobile app/game, or something open-source that you've kept at for 6+ months. This will both sharpen your own skills and give an interviewer something concrete to talk about.
Complete Advent of Code. This isn't quite as impressive as the previous, but if someone has completed all of an AoC, that's a pretty positive sign for me. (Note that it's quite possible to cheat at AoC, making this not as strong a signal.)
People hate to hear it, but grind leetcode. Get to the point where 95% of leetcode easy problems are truly easy for you and where medium ones are 50/50 within your grasp. Not only will this sharpen your skills, but it (like AoC) will force you to work through some problems that are initially difficult for you. Just like lifting heavier weights, this exercise will make you stronger as a programmer.
Find an open-source project that has some beginner-friendly tasks. See if you can complete any of those. This will both give you confidence, but also give you a sense of "do I really want to do this as a job?" (A lot of programming is, IMO, the best job in the world. A lot of is...not...)
Keep at the applications. Ask for feedback from failed interviews. Sometimes the true answer is just "we had only one spot and the person we hired interviewed more strongly"; OK, only sensible thing you can do is keep interviewing. Other times, you might get a piece of feedback that really helps.
You could consider pursuing some (charged) AWS certifications. These aren't a major positive signal for a lot of employers, but they're a modestly positive signal for some and for a career-changer, they're probably a better signal of seriousness than a more traditional candidate.
If you find none of that lands you a role, depending on your location, age, and life circumstances, see if any companies near you have internship programs and if one would consider hiring you into their internship program.
I would only do the QA-first route if that was the very last option for you. (It's probably better than a bootcamp, but it's close.) Companies that hire you into QA won't want to quickly lose you from QA into coding. I have a few devs on my team who have gone through that route in our company, so it's definitely possible (and they're good), but I think it's on average a longer road than waiting and coming in the front door to software.
freelance work.
Sign up on Upwork.com (or similar). Do a bunch of contracts. Put them on your resume.
I did freelance work for years before deciding i was sick of constantly hustling for clients. Then I applied for jobs and said "here's all the things I've done" and they were like "cool. interview. yup. you're hired"
Also, pro-tip: make contributions to big name open source projects. Not only will it be great to be able to honestly say "yeah, I'm a Rails contributor" (or whatever) BUT it is also great experience for working with others. The large projects tend to have high standards and require good code and unit tests. You'll frequently get a code review and need to make some tweaks before it gets merged. Good experience.
I guess I have a confidence issue with putting myself out there.
2) Ignore experience requirements, apply for everything (within reason). Some folks seem to have the idea that job descriptions are carefully hand-crafted by the hiring manager to present an exacting description of their needs--but this is rarely the case. Don't be deterred by the ubiquitous requirement for 3 years of experience. That said, don't waste your time applying for senior positions, either.
3) Seriously, apply for everything. Many (if not most) of your applications will never be seen for a human being--particularly when applying for entry-level jobs, which see the highest number of applicants. Even when I'm fully qualified for a job, I assume that I'll get a call back on ~20% of applications. In your situation, the percentage will be much lower, probably less than 5%. Spam accordingly.
4) Track your applications in a spreadsheet, and follow up with a call to HR for the most promising ones. Tell the HR person that you know you're the right person for the job, and politely ask them to give your resume to the hiring manager. If you can find the hiring manager on LinkedIn, shoot them a (brief!) message saying that you've applied, why you think you can do the job, and include a GitHub link. Touchpoints like this elevate you from "just a name on a resume" to "actual human being" in the mind of the hiring manager, which is invaluable.
5) In the immortal words of Barney Stinson, "Ambition is the enemy of success." For your first job, just get a job. It will be infinitely easier to find the right job after you've got some experience on your resume.
6) If you get an interview and don't get the job, hit up the hiring manager on LinkedIn and ask if you can take him to lunch. At lunch, tell them that you've gotten a few interviews, but haven't been able to land a job. Ask for feedback, and make it clear that you aren't asking for politeness but for brutal honesty.
What jobs even issue phone lines to employees anymore?
Nobody lists the number for HR—you just call in and ask to be transferred.
I‘m CTO of a Series C stage scale-up by now.
There are literally hundreds of such jobs out there you can‘t really train for with obscure names, just go browse some listings from companies with a good culture and a way up. Show up with a technical enough mindset and an attitude of making things happen and you‘ll get that job.
If you just go a bit above and beyond of what‘s expected and ask smart people smart questions, you’ll kill it in no time.
Good luck!