[janosdebugs]

I work on OpenTofu since November, lots of coding, docs, the rest is helping the community or coordinating contributions.

I used to work for Red Hat (OCP on oVirt/RHV, Arcalot/Arcaflow, etc), in a little over 2 years I wrote somewhere around 40.000 lines of code that I can account for with 80%+ time spent, but that diminished greatly around the end as a lot of changes into the "Scrum to rule everything" direction happened, which decreased the amount of code produced by a lot.

Depending on what you do you may want to go window shopping for jobs where coding skills are valued and that are low on process. If the interview process already puts heavy emphasis on your code, that may be a place for you. If, on the other hand, the quality of your code isn't appreciated as long as it works... Smaller companies/projects tend to work better.

[gosenx]

Ohh I’m jealous of you. I dream of coming near that number this year on my personal projects.

I’m in the market looking for something in the intersection of infra/systems programming.

It has been tough to get interviews due to my location and experience, but I know I will manage to do it.

[janosdebugs]

Don't give up! It took me a while to get things going too (I've been in the industry for 15-ish years and only started figuring out a bunch of stuff in the last few years.) Also, there are plenty of remote jobs that will happily do a B2B contract with you unless you are in one of the handful of countries that the US has problems exchanging money with.

I can only speak from my experience, but what helped me land interviews ( as a gradually built up over the last 3-4 years) was:

- Having contributions in high profile open source projects name-dropped at the beginning of my CV. (Front-load the interesting stuff. Also, these should be substantial works in case somebody goes to check.)

- Having relatively well-known open source projects I built from scratch (ContainerSSH, gotestfmt, etc) in my CV with well-known users I can also name drop. These projects had nothing to do with my day job and I built them in my free time.

- Having spoken at several conferences. This is the most unfair of all since not everyone can travel and having the conference in there doesn't say anything about the quality of the talk, but it seemed to help get through the recruiter filter.

What helped me get through the interviews (again, from my experience):

- Having experience in diving into unknown codebases and problems. Most companies that are serious about coding will have you do live coding, take home exercises, or read some code in the interview. If you do enough work on open source stuff, you'll develop this automatically as you will be jumping into code that's not yours.

- Being able to do TDD in the live coding interview and still finish on time. Nobody I talked to actually does hard core TDD in the industry and most people are stuck with a ton of legacy code, but this is a magic trick that will get you some eyebrows raised assuming you don't mess up the rest of the interview. Also, forget algorithmic problem solving. While at least knowing algorithms and datastructures helps, most companies don't have deep algorithmic problems in their day to day operations, so encountering these in the interview I found to be a minor red flag.

- Knowing the language basics. If it's Javascript, know your type issues or how the runtime works. If you do Go, know parallelization problems and how to solve them.

- Structure your code! On the interviewing side I had to fail too many candidates for submitting code with an unclear/messy structure for take home exercises.

Big no-nos (when I was the interviewer):

- Do not claim you contributed to a project if all you did was a typo fix.

- If you have a Github profile, make sure it's not full of forked repos you didn't contribute to. I will only look at what you linked in your CV, but others will google your name (no matter if it's illegal or not).

- Clean up or set your social media to private if you don't want interviewers to see that. Google yourself, make sure there are no red flags there.

- Don't use ChatGPT/Copilot without heavy refactoring. This is incredibly easy to pick out and not cleaning it up, not making the code style consistent screams that you have no idea what you are doing. Remember, interviewers only have your code to go by as a signal source.

- If there is a woman in the interview panel, make sure you don't just address the guys. We did interviews with my wife and we noticed this a lot. This may just be a force of habit, but for companies paying attention to diversity, this is an immediate red flag. The people who got flagged for this usually turned out to have a culture fit problem in other areas too, but it's worth keeping in mind.

- Leave your ego at the door. They may criticise your code, but don't get defensive! Stay factual, that will help defuse the situation.

- Don't have typos in your CV. Use a spell checker.

Finally, really, don't give up. My experience is just that of one person, I (probably) don't live in the same country, probably don't have the same amount of time available as you do, and I (probably) don't work in the same area as you. My advice may be complete garbage and not applicable to your situation.

[gosenx]

You really motivated me here. Thank you. I'm planning to getting into containerd and kubernetes.

I will have something to show for by the mid-year. I'm sure. Thank you.

[janosdebugs]

Fun fact: I had only a rudimentary understanding of Kubernetes until 2020, but I had a fair bit of knowledge about containers. (Built an experimental container engine to learn.) Then I did 2 Kubernetes certifications and that got me up to speed (completely useless apart from the time spent studying). In the process I went and adapted Kelsey Hightower's "Kubernetes the hard way" to my then-employer's cloud offering with Terraform. It was super hard because everything was different, but totally worth it. Would absolutely do it again.

I built ContainerSSH at that time too to learn Go (look up the first versions, it's ridiculous how small they are) and then went to work for Red Hat with my new found knowledge.

[gosenx]

Ohh the more you write the more inspiring it gets. You cleared my thoughts towards what to do, I'll act on it. I checked you website and OSS work, really good stuff