A developer journal can help you get your next software engineering job

As an unemployed Senior Software Engineer who’s been on the job hunt for over 5 months as of this writing, I’ve had ample time to reflect on my tenure at my last company. Although my departure was not of my own volition - layoffs, ugh - I’ve been thinking about what I could have done to better prepare myself for a job search.

I’ve done the requisite grinding of Leetcode problems and applied to every job posting that seemed even the tiniest bit relevant, but it’s been one of the toughest job markets I’ve ever seen, and candidates really have to be on point to get an offer. Clearly this has not been me! Given that, an ongoing discussion with myself has been a sort of retrospective to identify strategies or processes that could help shorten a future job search.

One idea in particular stands out: keeping a developer journal.

What’s a developer journal?

A developer journal is a place to document your projects for yourself. It’s a place to record whatever you feel is compelling about the project, the process, mistakes you made, things you learned, etc. It can really be whatever you want it to be.

Start by record the context behind the projects you’re working on - maybe focus only on the bigger ones - think about the “why” of your projects, as in why are you doing the project?

• What problem are you solving?
• Who are the stakeholders?
• What’s the status quo such that this problem has arisen?
• What data or graphs can illustrate the issue?

As your projects progress, or even as part of your own private retrospective, record architectural decisions and details about the decision-making process, conflicts and how you resolved them, what worked well and what didn’t, and things you might do differently.

Compare the outcomes to the state of the system before your project went live. What kind of data or graphs can illustrate the impact of the change?

This acts as a record of your career journey. As a reference it can help keep you from committing the same mistakes over and over again. And it can help remind you to apply what you’ve learned in your future projects.

Plus, it can help you in a job search!

Developer journals and your next opportunity

The interview process generally requires a few different types of discussions:

• Coding
• Systems design/architecture
• Troubleshooting/incident management
• Behavioral/Values
• Project Retrospective

There are tons of resources online to help you prepare for coding and systems design interviews. Grind Leetcode questions, work on personal projects. Read Domain Driven Design, Philosophy of Software Design, Architecting for Scale. So many resources!

Troubleshooting/incident management discussions are less common, but this is the kind of thing I enjoy and which tends to rely more on your actual work experience than data structures and algorithms questions do.

The other two rounds are similar to each other:

In a behavioral/values-based discussion an interviewer might ask you about how you’ve handled adversity and conflict over the course of your career. They’ll ask you to provide concrete examples and ask you to provide context. The questions are typically phrased in the form of “Tell me about a time when…”:

• Tell me about a time you went above and beyond for a client/customer/team/member/user/friend.
• Tell me about a time you encountered a conflict with a colleague. What was the issue and how did you resolve it?
• Tell me about a project that at first seemed insurmountable. How did you take it from something that seemed impossible to something accomplishable?

A project retrospective discussion is typically a deep dive into the details of one particular project you led or were involved with. It might be technical in nature or from a more project management perspective (in which case it’s very similar to the behavioral kind of discussion).

You talk about the context, the whys of the project, then get into the hows. You might talk about technical decisions, design decisions, architectural details, conflict resolution, what you might have done differently.

Behavioral and project retro interview rounds, which you’ll see at basically every company, rely heavily on your long-term memory of details. This, as you might imagine, can be an issue if you’re on the market for a long time, and potentially even more so if you’re fully unemployed and no longer thinking about the old code base.

How to prepare for behavioral and project retrospective interviews

Interviewers in these rounds are trying to assess how well you communicate your experience. But communicating all these notable events and structuring your stories depends on how well you actually recall the details.

Enter your developer journal.

During a layoff, you might not have the presence of mind to back up your notes if you had any in the first place. Or, if you’re still at your job, you might be stretched a little thin while sending out resumes and grinding Leetcode. With enough time behind you, it may be difficult to reconstruct the context and timelines coherently during this process, or worse: while under pressure in a live interview.

Your developer journal can act as your out brain for this process. As the now-canonical source of detail, you can easily review what amounts to a series of case studies so you can refresh your memory and prepare answers to those experience-based questions.

Practice relating your anecdotes by using the STAR method to ensure your narrative is well-structured.

That’s really it. I’ve been trying to retroactively create a developer journal for myself from the notes I did save, but there’s only so much detail I can remember about the projects I worked on over the course of my 8-year tenure at my last job, let alone over my entire career! There’s no resource on the internet that can recall your job experience for you, so do yourself a favor and make the resource that future-you would want.