A Place to Record Some Thoughts


welcome to thoughts on Joel's Static Site. I've been in the software industry for, well, many years. I've held many roles from developer to architect to senior technical manager, in a variety of companies from small to large, private and public. I've been through some pretty unique experiences and have thought a lot about what I did learn and what I should have learned from them. This is a place for me to collect those thoughts and make them available to the public. Consider yourselves warned ;)

I'm starting this as I'm back in the process of finding a new job. My ideal role is a combination of technical leadership, management, and hands on development. The proportions of those items are not fixed in my mind and are realistically fluid in any role. Of course I want to avoid situations where the expectations turn out to be 70% of my time on each area. But I digress...

While preparing for my Python and Accessibility talk at PyBay, I started using github pages. I quickly realized a static site I don't manage or pay for is a great place to record thoughts I'd like to share with the public. Well, thoughts I'd like to recall occasionally and don't mind sharing with strangers.

as I think more about this, what I'm starting is a blog in an HTML file on a static site platform. Maybe that's a bad idea, there are so many options for creating articles, why an HTML file on github.io? I guess because I want to. Being blind, WYSIWYG has little interest to me. And writing in pure HTML and CSS gives me as much control as I want. And I"m thinking how I could write yet another static site content generator, but what would be easier than writing HTML/CSS in VS Code, git commit -a, and git push?

So, especially for my fellow screen reader users, here's a bit about the structure of this file:

Table of Contents


Posted ; Updated

Just what the world has been waiting for, another article on interviewing. There's a twist to this article though, it's all about me, yay. Well, more that it is motivated by my experiences and focused on interviewing for software development roles. I'm writing this as I'm preparing to interview for technical lead / hands on management roles.

Most Important: Be Concise!!

I start with this point because I suspect it is where I have failed the most. The ability to clearly and quickly articulate the important points of a story can be paramount to success in your interview. Don't ramble. Unless specifically asked, details of the data structures you used in your last project, for example, are not necessary information. And once you realize you are rambling, wrap it up ASAP. This is why practice is so important.

There is a balancing act though. Know the difference between clear and concise and too brief. For example, if asked to describe a time you faced conflict and how it was resolved, an answer of, another developer and I disagreed on which database to use. I explained why my choice was better and we went with that. is almost certainly insufficient.

The STAR Method

If you've done any reading on interviewing, you've likely read about the STAR method (pdf). Note: the two STAR method links are to different sources. I liked each description, it wouldn't hurt to read both. I'm not going to describe the STAR method (see the links above), but let's look at how one might frame the example above using the method.

This is a contrived example though has elements of past experiences. My goal was to showcase honesty, maturity, empathy, and leadership skills. And, of course, brevity yet completeness. STAR stories are not the place to showcase technical prowess, the interviewer will ask technical questions if/when it's appropriate.

In the past, I would have been tempted to explain more of the proposed solutions or the combined solution. For example, the new data was a good fit for a document model thus my colleague wanted to use MongoDB. Each document though would need the customer ID which was already stored in PostgreSQL. We would have to deploy and manage Mongo, a non trivial task especially considering we'd have to do it as a geographically distributed replica set. Plus we would have to manually address data integrity situations like deleting all the documents in mongo if the customer was deleted in postgres ....

I cringe as I type this recalling past interviews where I did almost exactly what I'm describing. It's hard when you want to geek out on something even knowing it's not the right time or place. Notice the last line in the Resolution part. Offer to give more details and let the interviewer decide how much to geek out.

Questions I'd Ask the Interviewer

Now it's your turn to ask questions.

Of course you've done your homework and read through the company's website and LinkedIn posts. And you've read through the job description and a few other similar sounding jobs. And if the company has a service with a trial or free tier, you've signed up and tried it. With all that research, you must have found something you'd like to understand better about the company.

The point is to be interested in the company and the job. Maybe don't pour it on so thick it sounds disingenuous. And if you are disingenuous, maybe that's not the right place for you. Though maybe there aren't a lot of options and you need the work, there's nothing wrong with that. More digressions, I'm going to go review my notes about the STAR process and stop this rambling.

To the point. Here's a list of questions loosely grouped.

Wrap It up

I think I've hit the high points, and I want to go work on other stuff. Probably the overall theme of interviewing well is be curious, be authentic, and be concise. Just as important, be ready to learn from your own mistakes but don't be too hard on yourself. I've finished interviews thinking, ugh, that was a disaster. I've also finished thinking, hmm, that went well. Then I hear back they're not going to continue the process. Every interview is a learning opportunity. The better you can honestly reflect, internalize, and learn, the better you will interview going forward.

Good luck and don't burn out. It's okay to do something entirely different for a while after reading that email about it not being a great fit, blah blah blah. Don't let that break be too long though. Something else always comes up. Be patient, and be ready.

Technical Leadership

Posted ; Updated

I was recently asked in an interview what I thought was important for technical leadership. My mind was mostly clear on the subject, but not enough to articulate it well. I rambled. So I'm going to do now what I should have done before the interview; write down those thoughts to force me to think clearly to present them in a concise way.

Summary (TL;DR)

The summary is probably the appropriate initial level of depth when answering the question in the interview. What is beyond the summary is probably better if the interviewer asks for clarity or wants to drill down on any of the points.


Let's focus on two points regarding experience, direct knowledge of the domain, and direct work experience in the domain.

Template for Next Article

Posted ; Updated

copy and paste from the opening article tag to the closing tag to start a new article.