Ask HN: Landing a programming job by virtue of a side project only?
I'd like to pursue developing full-time but have no formal education. I do however have a profitable (~$500 MRR) SaaS in the finance niche and a few dozen freelance reviews from over the years. I plan to continue growing my product, but I believe the upside is limited and marketing isn't my forte, which has lead to my interest in seeking a position with stability where I can focus mostly on coding.
My first step will be to get a public repo up for it, but provided that's done, my questions are:
1) Would you consider someone in my position a candidate for an interview based on a product/repo only?
2) My experience is full stack, LAMP/JS, but all vanilla. Are there opportunities for a developer without framework knowledge, or should I focus on this prior to a job search?
3) I live about an hour from Toronto, Ontario. If I had a choice, a hybrid position where I commute one or two days a week and work the rest remotely would be great. Can this type of arrangement be found outside of senior positions or am I being unrealistic?
Cheers
38 comments
[ 2.6 ms ] story [ 71.3 ms ] thread2. This makes it harder - just learn react, new ES stuff and webpack if you want to focus on front end, it doesn't take long, just run yourself through some tutorials and build a small project to familiarize yourself. Some people will ask you trivia.
3. You're being unrealistic.
I suggest you ask for referrals.
As someone who also hires software people, I would urge you to review the evidence on whiteboarding. It's difficult to discard your own anecdotal evidence, but hiring has no control group -- you have no idea how many great people you're missing as a result of whiteboarding.
The reasons against whiteboarding have been discussed here many times, but I'll summarize them again:
- They're unnatural. People haven't practiced writing code standing up, with markers, with other people around, in real-time with minimal thought/planning, or with a potentially life-changing job on the line, and they don't do that after you hire them.
- They're biased against people who are introverted, who haven't specifically practiced whiteboarding, and/or who just aren't as cocky. Why are those traits you want to filter out?
- Most programming jobs are about learning and critical thinking, not regurgitating algorithms.
- They're humiliating for most people. That alone should be enough to end the practice. When people ask me for advice, I tell them to avoid companies whose first interaction with you is humiliating.
- Experienced candidates can (and should) refuse to do whiteboard interviews, which means your company is missing out.
I hope that's at least food for thought!
Anymore, I love that I have a clear path on how to obtain a very high six figure gig with plenty of resources to get there. I’ll gladly play that game, with enthusiasm. When others focus on the plight of the interviewee, others are leetcoding, white-boarding, practicing, reading up on blind, etc.
Depends what industry you work in, but where I am, it's more about accepting to switch team and language during hiring freeze, spend a week or two on legacy retro spec'ing, tell business users that you failed your impossible deadline, and fix your own crap honestly. Nothing leet about it, just brutal honesty, courage and loyalty to get a six figure where I am.
These things have no relationship with whether someone is productive, constructive to the team, or good at coding.
1. Invert a binary tree (tree based and simplistic) 2. Open a file, parse it in a simple way and then write to a new file. (file systems, strings) 3. Design a barebones twitter/reddit, etc. (architecture)
No dynamic programming, no esoteric stuff. Just can they understand tree structures, do they have a grasp on file systems, and do they have a modicum of design sense.
It doesn't need to be hard. After that the rest of proving themselves happens on the job. This isn't for humiliation, I just want to filter out the people who I would waste time on with further vetting and training. If the candidate cares they should be able to meet my appropriately low bar.
Also, who inverts binary trees on the job?
I've had good success with (like you) asking to be walked through some architecture. I also ask them to review a one-page program and then code-review two commits to it.
Finally, I give them a take-home (paid) assignment.
It's as close to testing how they really work as I can get without contract-to-hire (which I also support).
2: surprisingly, not all programming jobs require opening a file (I used to run a question that required opening and writing a new file and got rid of it).
3: I love whiteboards for design questions.
My suggestion for a technical interview (coding portion): take a real life problem you solved in the last year or so. Distill it down into something you could do in 15 minutes. Give the candidate 45 minutes to do it on a computer (preferably their own). For other important things you need them to know before they start (like if trees and file systems are important), just talk about them and ask questions. You can drill down as far as needed there and learn more than if they know the file api in the given language. I recently hired a guy who was green, and did not know how to open and read a file or do unit tests (really green). But given a laptop and a few minutes to read docs, he knocked it out. He has been a fantastic hire working on high scale, high available systems. I don't think he would have done well if the questions were on a whiteboard. Just my $0.02.
Look up some local meetups and get to know the local market.
So my point isn’t to discourage you, but to make you aware that managers might see your lack of formal education as a risk that you need to mitigate.
Everyone can learn to program, but learning how to program, correctly, efficiently and safe comes with formal education and you probably need to show that you know at least something about how to make CS based decisions. Maybe you do, if so great. If you don’t, spend a little time researching best practices, read up on design patterns and maybe complete the MITX intro course(s) to CS on edx.org.
I’m not sure knowing a specific framework is really all that valuable. If your can build something with LAMP/JS that makes money then you’ve already demonstrated your ability to write software. On the other hand it wouldn’t hurt you either.
edit: Plus, I know quite a lot of formally trained developers who at some point just stopped learning. To me that is much more dangerous than not having a formal education in the first place.
Which was kind of my point. The people who failed to get a degree are typically the people who won’t become great when they are self-taught either.
I can see why you would chose not to get an education in a country like America, where it would be a huge financial burden to do so, but we literally pay people to attend their free education.
We have a lot of self-taught programmers in my generation in the UK (I think mainly because of the BBC micro programme for schools a few decades ago). I've seen awful CS educated programmers and I've seen awful self-taught ones.
The two best programmers I know, one was self-taught and one was not.
The worst programmer I've ever known was formally educated, could quote you reams of technical specs, advanced CS, and managed to write 20 lines of not working code in 3 months.
I’m sure you can potentially get a CS degree and never learn anything but I don’t get the point that makes. I wouldn’t hire those people either. I don’t think it’s true though. I’ve never met anyone who went through 5 years of university without picking up anything useful.
2. You're pointing out that self-educated people aren't worth the risk and then you go on to advise him that he should self-educate.
3. A point that I think you're kind of making and that I agree with, is that a degree is a signal that you've gone through a certain process of education. If you don't have it, then you'd better signal the same thing in a different manner and demonstrate that you're familiar with theory, best practices, design patterns and so on; and that you can stick with something for a continuous period of time (showing up and doing at least the minimum amount of work for 4 years isn't a signal that all candidates have).
The rockstar developer is kind of a myth. If you compile 100 applicants into the 5-8 best ones, then the truth is that you could probably hire any of them and get good results.
That doesn’t mean self-educated people should give up. Especially because very few countries have as easy access to education as we do.
Anyone can get a CS degree without knowing how to program, you can make up the credits with all the irrelevant, purely academic, formal CS stuff.
But no-one can be a self-taught programmer, actually create a whole app, and lack the fundamental ability of being able to write a basic program.
On the flip side, I’ve never personally met anyone who went through 5 years of university and came out knowing nothing.
The thing with CS is that it’s not the programming itself that’s actually valuable. It’s being able to create efficient, safe and maintainable code. If you can’t tell me the bigO of your program, if you don’t know how to remove the top node of a binary search tree or if you think using NPM packages to do simple computation is a good idea, then I just can’t use you, because it’ll be way too expensive to teach you.
If you suck at our specific tooling, but have already proven you can obtain a university degree, then I know that I can re-school you relatively cheap by sending you on a few courses.
I’m sorry this is rubbing non-educated programmers wrong, but an education is actually valuable, and it will be increasingly so as the younger generations are all getting them.
See yourself as a product you must sell to a new client, your future company. The client is made of: - A future manager - Future colleagues - HR / Upper management
Each part of the client has its own set of requirement. Getting the interview depends mostly on selling the resume: make professional accomplishment clear, show that you understand what's happening around you and focus on problems and their solution.
1) I would definitely consider you for an interview, but with a strong bias against you: I, like many others, have a formal education and believe it helped me. I also hired exotic profiles and got bitten. The fact you have a product up and running is the only reason why I'd pay to see you.
2) Vanilla or not, what I would want to see in frontend code is clarity and team-orientation. If your code can be worked on by a team, and is clear and well done, that'd be more impressive than an angular spaghetti. I would ask you your opinion and try to determine if you can scale to team work, big project and deadlines. Your profile is usually understood to be able to accept ungrateful work happily while learning, and become senior in a 5-year horizon at best. You'll be expected to be humble unless you can demonstrate exceptional insight about programming.
3) I would refuse to see you immediately if I heard about you wanting to slack while we pay you to learn, and I would strongly signal during an interview that not only this is not possible even for the CEO, but that wanting it while you have so much work to do just to be on par with the team that will have to support you for a few years is disrespectful.
The top rule I try to apply when recruiting, is : is that guy better than me. If yes, hired.
Your marketability is fairly limited with just vanilla JS/LAMP. At this point I'd say learn basic React, Node and Python (preferably) or Ruby. Familiarity with AWS would also be a high return investment. You don't need to know any big back-end frameworks (e.g. Django/Rails) really well, but be able to bootstrap a project and use the management app. Spending some time with a microframework is a good idea (e.g. Express/Flask/Sinatra).
At your level working remotely part time is probably not going to be an option. Offering to take a lower salary during negotiations might get you a few days remote but I wouldn't expect it. I would definitely negotiate for more remote time as a reward for positive performance reviews though.
My concerns are do you know how to work with a team? How about communication? Do you know how to partake in all the other activities outside of coding? Testing? Documentation? System Design? Do you know how to program in the large?
Most people out there can brute force their way to a working project and even make tens of thousands of dollars but that doesn't mean they are a great developer.
What it would inspire me to interview you for is an junior PO role. You found a problem, built a solution, got a few customers, and have kept them happy. The skills to do that are not related to the coding -- they are product design/ownership skills.
If it's a software solution, the idea that the skills for the “built a solution” part of that are not related to coding seems to be generally untrue. Yes, a solo project of the type involved more than coding skills, but product owner skills without tech skills don't call forth software from the depths of the abyss, though they can produce a nice idea of what a software solution would look like if someone was available to build it.
Many people can fight through learning enough code to whip out an MVP. But did they do it effectively, or did they spend 3 months doing what most coders do in 3 days? Did they do it well, or is it brittle code that needs major refactoring?
So while you are right that coding has to happen, I stand by the original statement that the mere presence of code does not inspire me to interview the person who created it.
do you have any formal education? bachelors in anything?
If you learnt to advertise yourself effectively, getting a job as a self taught developer should be a breeze.
Conversely, if you learnt to advertise your financial widget so that it paid you a full-time salary, you could effectively hire yourself and continue building more products.
Just keep working on your own projects. Who cares if it's spaghetti code, you are making money, those people you interview with are working for the man, you are not.
Creative, drive and initiative (the talents you used to build your own web site and make it profitable) are talents not found in programming. Coders and Sr. Devs who see that you have those talents will soon extinguish those positive traits from character.
Sent from a government office... Help I'm trapped.
1. Do some human networking/meet ups. This is completely under rated and the returns are infinite.
2. Upwork.com, it take about 10 proposal before you get some work. It works over time.
Here is some inspiration... https://glenmccallum.com/2019/05/14/senior-developers-reject...
https://selftaught.blog/self-taught-programmer-jack-dorsey-b... second paragraph.
I realize now that I didn't give enough consideration to what would be imperative to an employer and the largest change from my experience working solo - functioning as a team member. I'm a lone wolf, and while I don't think that's inherently right or wrong, it's how I deliver my best work.
I think perhaps I'll revisit this idea in the future with my improved perspective, but for now I know that what I truly want is to support myself with a product I can call my own, even if it comes at the expense of a heftier paycheque.
YES! Side projects are the best way to demonstrate you know what you know.
1) YES! A million times YES! When recruiting people I don't care about their degree I know how academia works I know its all talk no walk, I want proof and a public repo is the best way to do that.
2) When searching for jobs search your skills (php / javascript) not a job title.
Your biggest selling point is that you are a self starter. If there is something you don't know you will just learn it, while the academics sit on their ass waiting for some one to show them. Its hard to understate how much of a massive advantage this is, especially to business minded people.
3) Yes
Your biggest obstacle will be self doubt or over confidence, don't bull shit if there is something you don't know just stick to your winning attitude.