Ask HN: Would you hire me (passionate hobbyist programmer) to a dev position?
I am not posting looking for a job offer, but just curious if I would be hire-able with my resume as it is. I own a house in a somewhat rural area so would likely need a remote position.
Here is my resume. I coded it by hand. Personal info scrubbed.
http://codepen.io/anon/pen/RNxJWp
104 comments
[ 5.1 ms ] story [ 226 ms ] threadWhat of the general content of my resume?
Your bullet points read like job descriptions, and anyone else who submits a resume that has had a job remotely similar to yours will sound about the same. Focus on your projects and accomplishments while employed, and make it look less like a job post.
I know you aren't emphasizing the front end skills, but leaving them out in the open if you aren't great, and aren't up to date with your front-end skills (tables, adding classes to make paragraphs look like headings - just use headings) can make any semi-critical resume reviewer cry "eek!.." Showcase what you are best at, and don't try to justify your hiring with things you "kind of, sort of" know how to do.
As others have said, tailor your bullet points to the job you are applying for. I don't care about your systems engineer work if you're applying to be a junior dev. Talk about your internal tools and app development. Those should be your bullet points - not that you "started and completed projects" or "were a member of a team".
Focus on your strengths and your goals!
did you not read the whole resume? tons of coding projects i've done are listed.
At any rate, the ability to make a rudimentary web page with HTML and CSS is not exactly impressive. I assume that's why jchendy said "… unless they're really impressive." Like, cool tech demos with HTML and CSS probably would help get you hired, but making a '90s-tastic resume is not even in the same neighborhood.
If you're going to start styling it (and in resumes, once background color enters into the picture, that's styling it), you really need to clean it up and make it look nice. Otherwise, going for a simple resume that's just text is probably going to serve you better.
I'd admittedly probably toss this resume as-is.
(Also, what about a DL for your experience rather than header/list?)
Startup founders and HR people tend to be very short on time and will most certainly not go through a wall of text just to figure out if you're good or not.
Your resume should make people interested in your skills and curious how you got there.
Once you have an interview you can still tell them all your additional information.
Furthermore: there's a cool open source project called json-resume that separates your resume data from design: https://jsonresume.org/themes/
this is a great point. I actually tried to accomplish this with the skills highlight section, but since you mention it maybe i did not.
edit: thanks for the link. I'll check that out.
It will help you get an interview, if nothing else.
I have freelance full-stack experience, just nothing black-and-white professional wise other than sysadmin & electronics experience in the military. I recently moved to what could be considered an "up-and-coming" startup city and I've been tossing around the idea of pursuing a change of career to development, but I keep telling myself an entry-level gig while keeping my salary around $80k isn't a reasonable expectation. Does anyone here have any insight?
I'd say work out timelines of how much you'd stand to lose if it took you 1,2,3 or 5 years to get past a certain point. I'd guess you end up recouping it in the long run but if you think it'd make you happier then you can't put a price on that.
But getting a company to take a chance on you requires that you adhere to their expectations of you R.E. salary, what you're putting on your resume, what you tell them in the interview. Once you have some professional experience under your belt, then you can start to be pickier about who you're going to work with.
I was in your exact position two years ago, down to the sysadmin and electronics military experience. First job I took was $40K. It lasted three weeks before they let me go with a letter of recommendation, which I never ended up using. Second job was with Panasonic for similar money. I hated it so I found another job after about six weeks for where I'm at now. They hired me at $60K and I made enough noise after a year that they bumped me up to $75K. I was a Test Engineer at Panasonic but represented myself as a Web Developer, as that's what I was actually doing at Panasonic when I wasn't doing testing.
I'm active in the development community and while there's a hot market for talent, there's a lot of pickiness on both sides of the table, perhaps justifiably. I would love to hire an entry-level guy to work with me, but my company doesn't seem to want someone that's actually entry-level, but rather someone who is experienced but willing to take an entry-level salary. They lowball the experienced guys and won't even make offers to the unexperienced guys. So none of my candidates have worked out so far. Companies don't want to foot the bill for teaching someone how to code, perhaps because they don't want to pay all this money just to watch them walk out the door a year later.
I started working with the MEAN stack to offset the boredom and after about 15 months I switched to a local startup. The pay was about 30% less, but I didn't have any professional experience on my resume (just my side project) so I saw it as more of a stepping stone. After ~6 months there, I applied to remote positions and ended up finding an awesome Senior level front end gig making quite a bit more compared to my DoD job. Also, I'm way happier now that I get to work with the cool things I used on my side projects. If our situations are as similar as I think, I'd say float your resume out there and see what bites. GL!
But you can't hire based on their resume.
Exempting them, it'd be the sort of resume I'd accept for filling an intern or temporary single project position, potentially leading to full-time.
Starting with the Summary, I would change from "Expert Systems Engineer with a passion for programming seeking an entry level development position in a fast paced environment that will leverage my existing self-taught skills and provide and opporunity to grow as a developer." to
"Passinate programmer with a history of custom software development and systems engineering ...etc"
Good luck!
That reasoning is pretty much entirely about my companies position, and not your strength as a job candidate. Similar reasoning happens at tons of other companies. I'd recommend sending out 100-200 applications to see if you can find a company that's in a position to hire someone like you. It's a fairly cheap way of getting information.
Does text like this really sell "you" to people? I find them quite pretentious-ish.
A agree with the post below about the adventurer bit though. It makes the rest a bit more over the top. I also agree with the posts about the colours.
Also, it is odd that the job experience descriptions are italicized where the education and projects descriptions are not.
Finally, (and you may know this already, but I am just mentioning it for completeness' sake), you should adjust your resume depending on the position you're seeking. So for instance if you are looking for an internship at a company that is not very interested in functional programming, you might want to change or reorder your interests, as well as reword the descriptions if needed.
* The colored bits and the typesetting of your name are on the whimsical side of resume style. Probably okay if you're applying to tech companies, but consider a more traditional layout if you apply to a more traditional company (eg bank, consulting firm)
* In 'experience' and 'projects', take care to use active language wherever possible and highlight what you accomplished, not just what you focused on. Ingersoll and Katie School could use revision in particular, the others look pretty on-target
* What sort of CS independent study and research have you done at Illinois State? You have the page space to be more specific, and can tailor this to the job you're applying to. Similar for Bloomington Central: consider if you can make "focus on mathematics and the sciences" more specific.
* Stanford: what about Cryptography from Dan Boneh? Did you complete the course? Did you receive a certificate or ranking?
* You might consider revising "interests" and "programming" into one section "skills" or "expertise". Narrow these to match the job.
* Like others have said, I am not a big fan of the 'Student, Hacker, Adventurer' tagline.
I had to look at it three or four times before I could get past the presentation to actually read the resume.
The codepen presentation shows me that you are able to write basic HTML and CSS. These are useful skills, but not enough to get you in any door that I might be operating. If the design was good, this method of presenting might work to your advantage, but it's neither pretty nor easy to read and it shows mainly that you have not yet developed valuable design sense or taste. There are lots of jobs (development and otherwise) you can have without those, but it hurts your resume to draw attention to your probably-irrelevant weak points.
Alternatively, if you'd written it all in JavaScript using some trendy framework, I would at least see you as a programmer. If the code was clever or elegant, I would be interested even if the output wasn't very pretty.
I had to look back yet again to get past the experience section. The experience section made me think of you only as a sysadmin/network admin. I've looked at this five or six times now before I got to anything that would make me think of you as a possible developer.
Some of the phrasing is sloppy - "start to finish" might be said better as "full lifecycle".
If you got a HS degree in 2004, you don't need to tell us you had summer jobs 10+ years ago. It doesn't add to the narrative.
Your professional skills section is all self-assessed things (critical thinker, team player, etc.) that add no real value. This type of fluff content takes away from the overall resume.
I wouldn't send this to an employer as a resume, but I do think you would get some response to a cleaned version of this. You do appear to be someone a company would at least interview.
They can bring it on on the systems engineering side. And as for programming, I am looking for an entry level position. How would you reword this?
I'll work on the other suggestions. thank you for the detailed feedback
If you are in the interview and they softball you, I'd invite them to 'bring it' live if the environment is right (are they smiling) - but on paper it comes across that you are likely overestimating the level of skills you would have.
One element of interviews that we rarely speak of is the interviewer needing to establish technical credibility with the candidate. Ego is one potential element in the exchange - particularly if it's unclear which party is 'stronger' - but an interviewer might also just feel the demonstration of their own technical abilities helps (a) make them a credible interviewer and (b) make their employer appear more attractive to candidates. Bright people want to work with other bright people.
But there is a first-impression problem. Obviously design skill is not what you are trying to demonstrate, but it's the first thing people see! Some people might read the code (and appreciate it), but even they won't jump right into doing that in the first few seconds.
I'd suggest copying the heck out of a good-looking online resume, and then subtly tweaking it to your taste. Subtly.
I'd also suggest hosting this on it's own. It will look more professional. (Github pages is a slick, free way to go.)
Your question was about whether someone would hire you as a dev. Yes, I suspect they would! Especially if you find an employer that has at least a passing interest in your operations/systems experience. I would look for a software company that works in this area (maybe one of your frequently used vendors?) - they'll eat it up that you know the domain.
That was my main lesson in a (test) interview for a front-end position that I applied recently (I'm also an hobbyist).
Resumes are sales documents; you're trying to convince someone to spend a lot of money paying you and hopefully investing in your skillset. Rather than think "is my resume good", reframe the question to, "who will be reading this, and what do they want to see?" There isn't one "right" resume.
Your word choice ("enterprise", "leverage", "medical applications", lots of talk about "projects"), certifications, and type of projects say "enterprise IT". If that's what you're going for, you might've hit it.
If you're writing a contractor resume (1099/freelance/etc.), you need to focus more specifically on skills and technologies, and how you've used them in the past. For a consultant resume, focus more on the business results of what you've accomplished (revenue/cost, customer satisfaction, retention, etc.) although frankly, you're probably too junior for that route.
If you want a job at a product company, figure out the age of the hiring manager. Most are 30-40 these days, if you want to get in front of those guys, talk more about "products shipped" and wins/successes you've had. For younger hiring managers/more progressive companies, a portfolio website would be nice. Also, the more code you can show/projects people know you can claim credit for/etc. the better, a big part of the hiring process for me is placing you on the social graph so I can try to find someone in my network who might vouch for you. It's surprising how easy it becomes to find someone who's worked with you after you've worked in the industry for 10+ years; help me do this.
Other general advice: "Good writing shows rather than tells". Rather than saying you're "passionate", talk more specifically about the projects you've done. SHOW.
Try to keep it plain; just make a PDF or if you really can do it well, a well-designed portfolio site. Formatting is table stakes, I don't think it would help much for a real dev/backend position, but it might hurt if you make it too hard to consume (esp. on a mobile device).
Get a copy editor. The writing is pretty bland, I think you could sell yourself better using more active language (focus on "what you did" vs. "what you are").
Put dates on things. I want to get the chronology of your career; this format makes that difficult.
Try to include links to websites. I want to see your github profile, what project's you've been working on, your blog, Twitter feed, etc. Again - trying to see who you are, what you do, and if we know anyone in common.
Try to use as simple language as reasonably possible. Say "use" rather than "leverage".
Be more specific about what you want. Full-time vs. hourly contractor vs. part time, if you want remote say which timezone you're in, talk more about what role you want (generalist/full stack, developer, designer, UX, manager, quality specialty, product management, ops, etc)
Finally, don't be afraid to let some personality show through. It's pretty bland, I don't know whether you're a wise-ass, what your sense of humor is like, more straight-laced, etc.; don't be afraid to be a little more funny/human with this.
Hope this helps. My email is in my profile if you want to talk further, I'm happy to chat more. I work in SF and regularly review resumes, so I see this stuff a lot.
Some notes on why not:
+ Your web-sume looks rough. As pointed out by others, there are a number of typos (i.e: "and provide an opporunity") not to mention the design itself could use work. If you are GREAT at web design/UX you should spruce it up. Otherwise, kill it and move to a traditional resume. Knowing HTML5/CSS3 today is pretty meaningless, so showcasing that is sort of pointless.
+ There are tons of issues with your resume itself (i.e: "Excellent verbal and written communication skills." despite multiple typos and unclear flow) which need to be addressed. Cut the fluff, point to recent projects & address why they are cool/why anyone should care. Anything that you did 10+ years ago that isn't directly applicable to what you want to do in the near future has no place on the resume.
+ Your bitbucket projects are lackluster. You don't follow good git branching habits, your commits are non-atomic, your code is cumbersome and unfinished in many places. You also seem to use .py files as notes in non-standard ways, introducing weird artifacts and conventions to your projects.
Some notes on how to improve:
+ Learn how to use git productively in a team environment (this means no more working directly out of master). This is a good resource to that end: http://nvie.com/posts/a-successful-git-branching-model/
+ Learn better coding habits in whatever language(s) you are most comfortable with. Your bitbucket only has python code, so learn how to do things in more 'pythonic' ways. (i.e: Don't just stub notes inside .py files. Throw them inside a README.md or keep them in a secondary utility so you don't clutter the repo).
+ Sort of back to point #1 but deserves its own category: Learn how to use .gitignore. You have tons of artifacts in your repos that do not need to be/should not be there.
If you address all of the above, you'll be in a much better position to start qualifying for entry level dev openings.
I really dislike gitflow for release-to-web projects. Any form of branching creates integration debt to be paid later. Maybe it's worth it, for instance, when discussing a new feature in its own branch. But gitflow's assumption of a heavyweight "release" process just isn't an accurate reflection of how the best companies work today. For a high-frequency deployment cadence (once/day or more), the level of ceremony required to get a release out is too much. And companies really do have to release that frequently, as high-priority bugs come up, integrations with third-party systems break, etc.
github-flow or the "Continuous Development Flow" as we call it, is much better-suited for high-velocity web development.
I'd be interested to hear what people are using for mobile projects. Maybe gitflow makes sense there, but I don't know that a "hotfix" ever happens, I think people just fix the bug and release a new version to the world?
Right now, there's a lot of ceremony to create release branches on 20+ repos. At the end of our two-week agile sprint, there's always a ton of confusion about "is the release branch open", "should I commit to develop", people opening PRs for review targeting the wrong branch (e.g. trying to merge into release/ but they open feature/ against develop), then accidentally merging release into develop and vice versa...it's just kind of a mess.
Maybe it's just my team that sucks at gitflow? Or our tooling could be better? It just seems like a lot of complexity to manage for a single person who isn't a full-time build/release engineer.
Also, if you don't mind me asking, how frequently do you deploy? We're at once every two weeks but I'm trying hard to move the org toward once/day or more, it's pretty insane how much organizational resistance I have to fight because deployments = "change" = scary.
Simpler is better; but when your actual code path of support looks like a network, that's the complexity you have to eat - I recommend eating it in your branching system (correspondingly, your versioned artifacts get some really funny version identifiers too. :) ).
Sounds like a headache but probably the best way in certain domains.
Some customers demand the absolute minimum amount of change - their interface is essentially fixed, all they want is fixes, no more improvements.
Besides firmware, I think this also get applicable when doing larger whitelabel software, each major customer might want to have a particular version they are focused on using.
It's highly unlikely for me to ever work as a developer but I'd like to know what you think of it, nevertheless :-)
[1] https://github.com/atmosx
ps. In case you take the time to have a look at my repo... Well thanks for your time :-)
(everyone else, feel free to drop a line or two about my repo if you like)
Maybe someday you can work as a developer for yourself. The good thing about a software business is that it's more about business than software. If you can code a working solution to fix some problem that exists everything else is irrelevant. The really hard thing is to identify a problem that's business worthy.
But why everybody should use this kind of branching model? Branches have their overhead, namely time spent merging after several days of work.
And also a method for quickly sharing code or projects with friends, instead of storing them on a server that requires FTP/SSH for access. Then everyone can just browse things in an easy way
thank you. i agree.
> Excellent verbal and written communication skills.
Prove it.
Anyone can write that. As a hirer I see that sort of statement all the time and it means nothing. I want you to prove it.
Eg.
> I regularly write reports for the CEO and board. I produce a monthly 200 word summary and 5,000 word detailed background on our team's accomplishments. This has lead to increased recognition of our team's performance.
I can immediately see what you mean by that. I want someone who can do that level of reporting and is trusted to talk to senior people. Of course, you might by lying - but that's what the interview and probation are for.
Let's also look at this:
> Backup reporting app that pulled results from a backup status DB and used a local database of admins and projects to present reports in various filtered formats.
So what? What did that achieve?
How about...
> I created a backup database app which sped up report by 35%. Using multiple output formats reduced support calls to the team by half.
I want my support calls reduced by half! We need to get this person in!!!11!
Ok, I exaggerate a bit - but in every single line of your CV, you should be showing not telling.
I wrote an app from scratch that filled a need in backup reporting. If i expand in the way you say my resume is going to end up 5 pages long. I want the kind of questions you're asking - during an interview.
- despite the efforts on your resume, it hurts my eyes. The focus is on the UI most than the content about you.
- At top of your content, I would like to see a summary about "what you have done" and reference links. I had to scroll down to find the info.
- I would suggest you move your code projects to github where is easy to see your work, bitbucket interface it's a bit complex for easy reading
And about the question "would be hire-able with my resume as it is", my answer is NO. Do the changes suggested. Your resume invite to "do not continue reading", fix that.
finally, always demonstrate what you have done, your resume "look and feel" its just a first filter and now it's a blocker.