I’d start with a programming job and work your way towards the “best” programming job. First the best jobs rarely hire inexperienced people. Second you don’t yet know what best means to you. It’s a huge field and people are very varied.

In general this is good advice, but it is important to mention there are companies and jobs out there someone just starting out should definitely steer clear from. I specifically mean developer jobs in certain huge corporations where a developer is expected to take part in 1~3 1h long meetings every day, each with 30+ participants talking at length about things like "architecture", "policy", "planning". In addition to a daily 1h long "catch up"(previously known as stand up). Also one is expected to produce multipage written comparisons of certain technologies to justify every little choice and no actual programming work ever gets done(but if you look at the planning software there are hundreds of work items whizzing by). If you, as a junior dev or a trainee end up in a job like this, run. If you don't, your skills will atrophy. If you get used to the nice paycheck and you stay for years you'll not be able to do any "actual programming" and you'll both despise your current work and be terrified of loosing it at the same time. In my consulting career I met many people and teams in such position. If you want to get a good dev job seek one that makes you do the actual programming first. Preferably with some experienced people.

>where a developer is expected to take part in 1~3 1h long meetings every day, each with 30+ participants talking at length about things like "architecture", "policy", "planning".

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.

Yeah I started out at my first company and really hated my job. I quit after 2 years and got a better job, but it was pretty boring. I quit after 2 years and now I'm at another company that I really enjoy working for. Markets tend to correct salaries and responsibilities pretty quickly (you make your biggest career gains early on)

Any employer is basically looking to have as much confidence as possible that you'll be able to do the job that they want as well as or better than any other candidate.

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.

Yeah, I came to basically say this too. If you want a good programming job next year the best way to get it is by having any programming job this year.

This is good advice.

Places that hire out of university are likely places that have tons of turnover. They might pay great but are they the "best" jobs?

Funny enough you learn on a percentage basis their turnover rates are greatly exaggerated, and some years are lower than a “healthy organization” of their size would like.

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.

Before you can crack the interview, you have to get an interview and with no credentials, that has little chance of happening.

Having been a senior person at some of those places and other adjacent and FAANG, as well as others, I can assure you those aren’t the best places. But they have good brand.

While true, this is completely irrelevant for the OP's question.

IMHO, the best thing you can do is to build something real. Register a domain name. Create social accounts for it. Advertise. Get real users.

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.

A lot of software engineers do not want to run a business (in the general sense of attracting users, being a founder, etc -- I do not mean making money), so this wouldn't be good advice for them.

Being an engineer != being an entrepreneur. They are disjoint skill sets, and one does not imply the other (nor should it).

Of course, but the OP asked what he can do. This answers their question. It doesn't have to be a business, it was just an example. Build something real. No one wants to see a calculator or weather application (unless it were like weather.com, eh? Now that's impressive).

Doesn't have to be a business... I made a similar suggestion specifically mentioning a hobby based community as the target audience. It's mostly about scratching an itch and creating something with the touch points you're likely to experience. Front end, back end, api, data storage/persistence, source control and ci/cd deployments.

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.

Building a system != building a business. Even if OP is just building something to scratch their own itch, slap up a landing page and repo. Even if you offer it as a WYSIWYG and totally ignore issues, it's still a tenable sign of other people finding your stuff useful.

The description in the comment I replied to mentioned acquiring X users in Y months. Looks like a business or startup to me!

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.

Yes and no - the guy who created the HomeBrew package installer in OSX was turned down for a job in Google, because allegedly he couldn't invert some binary tree quickly enough for some wet-behind-the-ears junior dev in the hiring process.

Imo this leetcode tests are just hidden iq tests (unless you actually get asked s.th. you studied before). That is not necessarily connected to beeing succesful.

Google isn’t the best programming job.

I second this. Building one or two cool demos with a common tech stack is a great learning tool and strong signal.

It's a much better approach than lots of small projects.

Eh, I wouldn’t think of these as “demos”, really. What you want to show is that you’re going to be building working products that solve peoples’ problems regardless of what happens, and by hiring you they’ll be putting that energy to work for their problems.

Network. Socially network. That's the best route into a job imo. Join some good hacking discord, build up your github, establish a presence on LinkedIn and start adding people in the space you're interested in. Some certs would be a good idea. The certification station website has a very active and helpful community.

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.)

Regarding Github, you're right -- that is what I was trying to say. There's nothing wrong with linking work you've done - much to the contrary.

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.

Totally agree! My apologies for misinterpreting your words. Looking forward to the day our new friend (the OP) makes it into the industry :)

Not an engineer but I would recommend finding something that connects your past experience to programming. Always nice to frame it as -- programming let me this thing nobody else could, because of domain expertise.

Yes, pivoting to a new career path can be financial painful if you have 10+ years of experience in previous career path. Utilizing programming skills as a differentiation from others is a really good option. Mixing any two areas of expertise is always a great sales pitch in getting a job.

Another tangent to this is applying to software companies who target your previous career's industry.

It depends on where you are coming from and/or going to... if you are earning less than the average income $72k/yr in the US, it's pretty easy to come close as even a starting level junior dev with no experience. As relatively high paid people, it's easy to forget that most people don't make nearly what our type of work makes, and half make less than the above, even a decade in.

This might sound old fashioned, but if you have a whole year I would invest some time in really learning the fundamentals.

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.

Absolutely this. Anybody can pick up the cool framework of the day and click together some usable cool looking app/website, heck even gpt can do this nowadays. What is harder to grasp is how a language works, how to architecture an app, what to look for security-wise, how something becomes scaleable from the get-go. Talking about such things in an interview will make you look far more experienced than some boilerplate projects. Not to dissuade from them - but then build something for the longer run, something that you need as well, not something to prop up your github repo.

I'll give you my opinion here, fwiw!

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

> 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).

I'm struggling to think of a scenario where this would be better than using sqlite, but I'm stumped!

You're right, it wouldn't be and I'd likely ask "why did you use a text file and not a database?".

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.

Regardless of level, easy hires for me were people that had code up on GitHub that showed their skill level. Typically this involved having a mix of:

- 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.

My brother got a job in the industry with only a degree in math. My advice is simply to trust in yourself and don't give up applying for jobs. It sounds like you enjoy and are good at coding. I guarantee you that is enough to be successful at 99% of jobs, you just need to find the one job that gives you a chance.

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.

Doing a portfolio site can help. I would probably suggest spending your free/learning time doing something productive, make something you want to see... maybe create a hobby community site from scratch, with the source/ci-cd releases from github. This will demonstrate that you can understand backend, front end, database as well as ci/cd and version control systems. The fact that you operate a support community for a hobby (doesn't have to be technical) can be a bonus.

That's just my though... you can probably target one of the free platforms out there, such as AWS or Google's free tier, use another tech that lends itself to a free tier such as Deno, cloudflare, etc. If you have some spend, then DigitalOcean, Linode or another VPS may be a decent option as well.

In the end, make something that scratches an itch and demonstrates the skills you are likely to need. You will probably make mistakes, but getting something made accounts for a lot. I must admit, in my hobbiest activities lately, I have several projects in varying states of stalled out; Don't be like me. ;-)

Mostly lack of motivation, partly analysis paralysis where I have too many things I want to explore. Favor making any decision and push forward. It's a good habit to get into, and I'm much better at it when someone else is paying me vs working on my own.

Aside: (Admin/Mod) if someone could add the [AskHN] tag to the title...

Good luck, you can do it. One piece of advice I'd offer that I read somewhere recently and liked is: at your stage, I would avoid "linking to your GitHub."

Instead, 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.

I spent several years attempting to transition from mechanical engineering to software engineering. The biggest and most consequential change I made was learning to speak a different language. Instead of answering questions and solving interview problems and explaining my solutions in mechanical terms, I learned to explain problems using software terminology. That was it. I went through literally dozens of interviews where I provided flawless optimal solutions, but software-only interviewers stared at me awkwardly and confusedly and told me my explanations didn't make sense, they didn't know what some words meant, and they didn't know what was wrong with my solutions but they didn't think they were right. So I learned the new lingo in two ways: 1) practice, practice, practice. I started reading software blogs and listening to software lectures and made an active effort to use their lingo instead of my own. and 2) I went on Coursera and took some free courses in data structures and algorithms and learned a bunch of terms and names there that I can pepper into conversations to convince people I know what I'm talking about. Because if you write up perfect code for a binary search but you call it a "bisection search" which is what one of my mechanical professors insisted on calling it, software engineers will stare you in the face and tell you your answer is wrong. The fact that it compiles and produces the correct output is irrelevant. Over and over. They're a very superstitious, anxious group, afraid of losing their privileged positions by letting in "the wrong people". And now I'm one of them ... sorta.

First off, figure out how you define best. Is it:

Most pay? Most interesting work? Best work-life-balance? Best ratio of pay to work stress? Remote work? Fun workmates?

As others have said, it often takes experience to really understand what your best job looks like. So start by building a list of qualities that define best. Once you define what best looks like, then you can start thinking about companies and what they look for. There are tons of resources on the web about interviewing for all sorts of different companies/positions.

Yes, build a project. See what you can get done in 2 weeks. Force yourself to produce something. Iterate. Build something else. Keep doing it. If you can get users and feedback that's so much better.

Have a github profile but don't put your best work there and use it to apply to companies unless you have had someone else do a code review beforehand. Unfortunately other engineers can be pedantic when anonymously reviewing your github and I've seen lots of premature disqualifications due to this.

I've hired hundreds of engineers, mainly software, data, and devops folks. If you're going for an environment that appreciates hackers (in the pg sense of the word) then it's all about showing that you have a passion for building things and self-learning.

Good luck! If you need help getting started hit me up @aiconference or @shon

20 years ago I was in a very similar position, but it was perl I was writing instead of python :-) This advice is therefore dated, and exhibits survivor bias, but it is what I know:

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.

Step 1: don't call yourself a hacker.

Consider looking for opportunities adjacent to your current career. I don’t know what career you are coming from, but you have a ton of industry and domain knowledge that will be valuable in writing software for that industry.

Try to automate things in your current job. Define the business impact. Tell me in a resume “I reduced 1200 person hours a year of manual input by automating our business process” my ears park up.

Consider grabbing some credentials. Depending on where you are coming from in prior academic experience, you might be able to finish a BS in CS at something like WGU in a year. You can also look for “bridge” programs from schools with a higher pedigree, which have the advantage of better career services and alumni networks (although understand you won’t get the full services or connections without a “real” degree). While you will definitely learn some useful things pursuing these credentials, they are even more important for you as a signal of intent and seriousness.

I’m less fan of open source contribution as a way of bridging careers. If there is something you want to contribute to by all means do so, but I find the barrier to meaningful contribution to be high enough that for Junior devs you are better off spending your time in something more structured like education or small work automation projects.

That being said, do create a great personal website. It can be a well written blog, a beautiful version of your resume, a showcase of projects, a charitable cause (although perhaps not for hot button issues), or anything and all the above. Just make it pretty, performant, and polished. It is a standout when I look at people.

As others have said, do personal networking. Show up to meetups and local events. Even if you don’t make a career connection (and you might), you’ll learn the lingo and things concerning working programmers.

Are there any tasks you can automate at your current job via custom software? For example: Things people are doing on paper, poorly executed excel spreadsheets, or any tasks that involve a lot of steps done by hand?

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.

I'm curious what your current career is and why it's coming to an end. Is it because you don't enjoy it anymore, it's a dead end, programming is far more enticing to you, or something else?

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.

Try and find a open source project you care about and help it out. Practice leetcode, probably python? Be prepared to be bested by generative AI's and find that programming won't be as fun as it was anymore. I for one would rather code than chat with my computer.

The other advice to practice is good. But you really don't want to be polishing turds, however skillfully. You want to find where you can contribute the most. Aim to be a professional.

If you have a year to switch, you'd get tremendous value from building your understanding of the field so you can make good decisions and target the right things, and see if you want more education/training.

Separately understand the gist of:

  - business domains and their product lifecycles
  - software lifecycles
  - classical software problems: algorithms, data structures, concurrency
  - modern software: internet scale, real-time & device, NLP & AI

By "gist" I mean understand the issues and forces, and how well-understood the problems are (i.e., are there many good solutions?). E.g., web apps can be re-deployed to millions daily, but medical products have multi-year lifetimes, and that determines the production process. Look for the difference that makes a difference.

Then assess yourself by trying some real CS, trying to get at the ideas behind the languages. E.g., pick up Haskell and write an interpreter. Read up on the math behind big-O notation, 3D models and ray-tracing, AI regressions. If it's sensible, more training might be in order, or you might take on peripheral roles in those domains (QA, data cleaning).

Finally (if not conversely), monkey see, monkey do: there are SO many open-source apps, databases, frameworks, etc. Just figure out how build and run them, watch how a bug gets fixed, and perhaps contribute. Pick the best (e.g., for C, sqlite). Then you can start to address the build-vs-buy question at the heart of non-greenfield/prototype software design.

One thing you'll optimize in that year is how to learn and assess, and how to plan multiple small projects, which you'll need for your entire career.

CS grads come out with knowledge but no experience. Your goal is to show you grok experience lessons and have the capability to learn as you go -- to show upside potential long after the interview. The skills part is the easiest to pick up.

If best means running a top tech company hazing gauntlet, then leetcode and system design interview practice. That should be #1. Then you can choose from a portfolio site, personal Github, open source contributions, and writing blog posts.

Take a severely underpaid junior programming job. That will get you the experience you need to get a job you actually want next year. Especially if you also do learning / a project on the side.

How do you get the underpaid junior programming job, though? My experience trying to get hired without a degree is that recruiters aren't interested in amateurs without formal CS degrees or professional experience and companies ignore anyone who isn't a recent college grad. I've never even gotten the chance to do a leetcode test, much less an interview where I can convince people that I'm capable and willing to work for peanuts if I don't have to do braindead manual labor.

You could try and learn mainframe and get a job as a cobol developer.

No need for a mainframe. There are multiple cobol runtimes for Linux. Several commercial ones.

Can you reasonably make the (only needs to be verbal) argument that you are considering maybe going to graduate school?

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.

Leetcode, and a friend who can refer you to a big tech company.

I do my best work when I'm coding on something I actually, personally care about. It gives me the drive to power through all the challenges, and also to strike pragmatic balances between clean code, progress, etc.

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.

You don't really describe your background at all so all you are going to get is generic advice. But the best thing you could do this year is get a job in the field. Even if its not a very glamorous one you will learn more than you could in a bunch of tutorials or online classes.

Identify a field, e.g web development.

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.

Honestly, it's a chore and we all know it sucks but grinding leetcode will open up the most doors.

Is this true? Have others here had success with it or hire based on it? (I'm asking honestly since i'm not in software industry)

It is pretty universally used to filter out candidates. FAANG pioneered this and maybe for a while you could work in startups without grinding programming challenges, but unfortunately today even startups lean pretty heavily into this.

How do you get an interview in the first place?

For a first job in the industry just spam applications. Assuming an acceptable resume that describes technologies you're competent with, and assuming it contains some projects or interesting things that have been built / worked on, some company somewhere will eventually take a flier on you.

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.

Stop calling yourself hacker.

Build stuff preferably simple but cutting edge and post it on twitter