Behind Behavioral Interviewing Questions

Every developer, no matter who or what the context, is going to run up against the dreaded “behavioral interview” segment in the interview pipeline with a company. When the market is hard like it was in 2023 and is in ‘24 (the time of this post) you need to prepare. As stated in the opening sentence, this advise and these breakdowns are targeted towards people attempting to land a software engineer/developer position. While some of this advise may be relevant to other fields, I would discourage drawing too many conclusions from them.

Preface

There is a big difference between small start ups and larger enterprises both in terms of what an interviewer is expecting from a candidate and the context in which they are asking the questions. At the smallest of the small, many start ups are staffed with generalists and development roles are expected to do many things with very little structure. At larger enterprises, developers focus on only the aspects of software; they may not even need to concern themselves with the CI/CD pipeline, monitoring, or even provisioning of resources (crazy, right!?) Make sure you are aware of the context around the interviewer when answering questions.

When being interviewed the standard practice has consolidated around the STAR methodology:

• Situation - give the context but do not overwhelm with details

• Task - plainly and clearly state the task (if there was one)

• Action - this should be the bulk of your answer. Avoid “we” as this indicates you were a part of and not in charge of the decision making

• Result - the positive outcome (always positive.) Do not leave a cliff hanger and tie all loose ends

Finally, make sure you are addressing your audience with a story which is relevant to them. If it is someone from Customer Success listening to you speak, don’t talk about the intricacies of RCP or the build system. Talk about something they could relate to. Keep the technical details light and the narrative around the work.

An Example Question(s)

The important part of each question is to ascertain what the interviewer is attempting to get out of asking it, e.g. what signal do they want to produce. Sometimes they’ll flip a question on you to see how you’ll respond to its corollary. So even though these are essentially the same question, the approach is radically different. Tread with care.

Tell Me a Time When you were tasked with solving a difficult problem and were successful

This is a chance for you to tell a story that positions you as a champion problem solver; one who is filled with grit, determination, intelligence, and expertise in the subject domain. Since it is a positive story, you need to ensure that in telling the story, you focus on the successful outcome and downplay interpersonal challenges you may have faced along the way. If there are aspects of your career or skill sets you want the interviewer to explore further, those things should be part of the answer to this question.

Areas of Focus

• Communication Skills - How you identified and set expectations

• Collaboration - How you engaged the team(s) involved in the project. Bonus points for inter-departmental problems.

• Technical Knowledge - At a high level, why this was difficult

Areas to Avoid

• Technical Details - while you lived it, they did not. Getting bogged down in details may steal the momentum of the story.

• Historical Problems - No one wants to hear how awful the last developer was, how some library is junk or what poor decision making led to this problem. Skip it.

• Failure - They asked for success. Everything succeeded. Right? Right!?

Tell About a Time You Were Given a Task but Failed

This is the opposite of the above question. However, unlike the previous question they aren’t waiting to hear how good of a story teller you are. They are looking for four important qualities: risk management, resiliency, a growth mindset, and communication. While it is about failure, it can not be a catastrophic failure and the underlying cause can not be some dysfunction within the organization. At the end of it, you must come out in some way, shape, or form “better.”

Areas of Focus

• Learnings - It was a failure. What did you learn and how will you avoid this in the future?

• Ownership - What was your role and responsibilities in the project

• Outcome - What positive came out from the story (besides what you learned.) Even though this is about “failure” it must have a positive result

Areas to Avoid

• Finger Pointing - don’t blame external factors. They can contribute to the problem or form the context around the story but they can not be the reason for the failure.

• Negative Emotions - No one likes to fail. I get it. You can be angry or bitter about the event(s) but not during the interview. You must stay positive and upbeat the entire time.

• Minutia - There might be some small details that you experienced which have been seared into your memory for time immemorial. You don’t need to tell all of them to the interviewer.

Conclusion

One story for each type of question is not enough. What an interviewer seeks and what information they’re attempting to gather depends on the type of question. Whatever the case, the story must have a start and end higher. Details can distract and hide the merits of your actions; be stingy and keep them pertinent.

Architecture: Ask Before You Optimize

If you’ve ever spoken to me you know I love “dumb” questions. They tend to drive problem solving in the direction needed before we dive into any hardcore analysis of the issue using our educated guesses as guides. They don’t get asked often enough at the beginning but I guarantee they’ll get asked at the end.

So, here is a story from early in my career of just that.

The problem

Our compute cluster was not performing to the expected level given the size of the machines. The CPU and I/O stats pointed to a problem with our software. We traced it to delays querying the authentication system. That is, authentication was running way over capacity (~10k req/m) and had been for a while.

On one hand, this was a good problem to have. It meant our users were using the platform. On the other hand, it meant we had hit a bottleneck in a portion of our code base we never thought we’d hit.

The Solution

After running the system analysis the group of developers assigned to the case concluded even basic user sharding wouldn’t help. It required a total re-architecture to handle the forecast platform growth over the next 6 months. Any delay jeopardized the stability and growth trajectory of the offering. A new multi-threaded authentication server would be spun up backed by a MongoDB caching layer.

The Question Not Asked

How many users did we have and how many of them were active at any time on the platform?

That’s it. That was the question no one asked. If they had they would have heard 100 and 10.

How could 10 users produce a staggering 10k req/m?! Could it be that we had forgotten to pass user permissions every time we requested data? Could it be that every node on the platform was thus making hundreds of permission requests using the user credentials instead of caching and reusing the previously requested perms? The answer to both is “yes.”

The Aftermath

After the developers proudly showed off the new auth system to much fanfare a non-developer pointed out the absurdity of the situation by asking “why?” Why couldn’t the original platform handle more than 10 users at a time? How did we engineer something like that? Seemed silly.

Leadership pointed out the problem had been “fixed” and the compute clusters were finally operating much closer to their expected level. This was worthy of praise, so that’s what we did. We congratulated them for all the hard work they had put in.

Internally, we raised the same questions. A senior developer then changed a few lines of code to pass user permissions into the computational framework we’d built. The load on the auth system subsequently disappeared. We no longer needed the new system …but we didn’t need to tell anyone it was gone shortly after it had been created.

In Conclusion

Don’t be scared to ask dumb questions. Sometimes the most obvious questions should be asked. I didn’t ask because that wasn’t my part of the system. I had accepted their prognosis and assumed we must have gained a TON of users.

Now that I’m older and, I hope, wiser I make a point to ask.

We're Looking at Developer Interviews Wrong

The problem with hiring in software is that most interviews focus on writing code and "culture fit" instead of focusing on the daily tasks which occupy a developer's time.

The five primary responsibilities or duties that are commonly assigned to software developers from my experience are:

1. Write code/produce a dataset

2. Review another developer's PR

3. Triage a production incident

4. Review a technical design doc

5. Review a product requirements doc

So why is it that most work involves reading and understanding other people's work while the hurdle to joining a company is about demonstrating that you can produce work? Seems backwards if you ask me. Maybe a better question is, why don’t more companies interview for all the tasks they ask developers instead of code generation tasks?

First, shifting the focus away from writing code requires preparation and work from the hiring company. Most times when someone needs to be hired, they need to be hired ASAP! There isn’t time to do the work needed to round out the interview.

Second, every role at a company handles different systems. Triaging a problem with Airflow is very different from triaging a problem with a RESTful API or a Kubernetes Pod. This would mean every team couldn’t use a standardized interview set up at a “triage” portion of the interview. Again, more work.

Finally, looking at the spectrum of experience, Jr developers shouldn’t be expected to do a critical assessment of a technical design document. So there would need to be some tailoring to help them with this stage (or skip it altogether.) Again, yet more work for the hiring team.

Thus, the problem with hiring is that we, as an industry, are emphasizing the tasks which are easiest for the hiring team to consume and judge while diminishing the evaluation of any task which would require effort from us.

Being a Jr Developer and Doing Code Review

If you have less than 2 years of experience as a software developer you should try to read every PR your team opens and leave a comment. Sounds like a lot of work and it is. However, you will benefit immensely from it.

Every time I sat down with a junior dev to ask why they weren't participating in code reviews they told me they didn't feel comfortable commenting …yet. It was always something along the lines of "I'm not good enough" or "I'm not familiar with this part of the code." They didn't understand this thing, they didn't understand why that change, or <insert reason here.> Maybe they'd start contributing in a year or two. You know, eventually one day.

I heard the insecurity and/or humility in their reasoning but reminded them, part of their job was to learn quickly so they could understand. The fastest way to get “there” was to read and ask questions. They didn't need to leave helpful comments, approve the PR by clicking "accept," or even find an issue. What they needed to do was make sure they were getting on-the-job education which would help us grow them into the next place in their career.

So you need to not be that person who hides away from show casing how junior you are. We all know you are Jr. We need to see where you are struggling, what concepts you still need to learn, and what things you need to be exposed to. Reviewing PRs or just code reading of PRs are a great way to help us help you.

Progressive Instead of Regressive Metrics

Metrics are an important part of goal tracking. Prefer progressive over regressive measurements.

Regressive measurements evaluate whether a baseline has been met; they do not capture incremental improvements and can hide a lack of forward progress. Progressive measures, on the other hand, quantify tangible advancements in performance, fostering a mindset of continuous improvement. This has a big psychological impact.

Let me give you an example.

If I'm training to improve my mile time from 7 minutes to 6 minutes, merely measuring the number of times I beat 7 minutes would be an ineffective approach. Such a stagnant and regressive measurement would allow me to run a 6:58 mile for months on end without providing me an insight into how far my efforts were propelling me. It could demoralize me; making me question if I’d squandered my time attempting the impossible.

Instead, if I’d employed progressive measurements that track my actual mile times, a plateau at 6:15 would signal to me that I had reached the gains from the current training regiment. At that point, I could choose to either revisit how realistic a goal I’d set or examine what I would need to change to hit it. Either way, I’d be pumped knowing I was now running a 6:15; something I haven’t done since college.

Progressive measurements are proactive and promote ongoing enhancement, while regressive measurements are reactive and simply evaluate whether a predetermined level has been attained. The former fosters a growth mindset and sustains motivation, while the latter risks complacency and potential demoralization.

Resume Parsing in 2024

Kevin Comics, 2024

You'd think that with over 1,000 ATS (Applicant Tracking System) vendors operating in the world today, and with the same file formats (PDF, txt, docx, etc.) being used for over 20 years, along with the rise of AI, this wouldn't be a problem anymore. However, you would be wrong. It’s much, much harder than you’d believe.

The often shared advice to developers when submitting a resume to an agency, recruiter, or job site is use a PDF. PDFs are great at formatting and arranging images, video, audio, text, interactive elements, etc. in a document. They focus on layout and spacing. They do not embed semantic linkages between text elements; something not needed for layout but required to properly parse information. All the clues are visual.

Hence, even LLMs struggle with deciphering the contents of a PDF. The best technique is still based on a rule engine and heuristics to group PDF datum. As such we wind up with “Clark Shipping, MA” as the address, a blank for the company name and still call it a win.

RIFs, Restructurings, Leadership, and Org Mapping

What is the one thing you need to do as a software manager if your team has absorbed responsibility for managing more systems or has lost personnel? I hope you said “redo my org mapping.” If you didn’t, take 5 minutes to read what I have to say.
You need to identify the gaps in your new org: skills, knowledge, experience, and resources. Gaps represent unbounded risks; risks which tend to materialize at the most inopportune times. Minimization of risk falls under your purview as a manager and it is your responsibility to assemble, quantify, and plan to address as many of them as possible. It is not, however, your responsibility to do this in isolation.

If you have never done it before, find someone who has. If that’s no longer an option (RIFs suck, I get it) then do the following:

1. List all the applications your team is responsible for

2. List all the technologies that go into them

3. Ask your team to rank themselves in terms of knowledge of the apps

4. Separately, ask each person to rate their confidence with the technical stacks you now own

5. Finally, ask them to rate their knowledge of the domain

Now take that list and sit down with your tech lead, product manager, and if possible, boss. Work out what is or isn’t acceptable. Then figure out what impact mitigating the issues you’ve uncovered has on the quarterly or half year plan.

Rumsfeld said it best when he spoke “there are known knowns, known unknowns, and unknown unknowns; with the later being the most difficult.” You have a chance to remove a whole bunch of unknown unknowns before one or more become a catastrophe.

Technical Choices and Scaling Teams

As companies grow, they often struggle with effective prioritization because they are unable to allocate resources appropriately. When a particular team becomes a bottleneck, simply adding more people may not be a feasible short or even medium term solution. In software development, the challenge goes beyond a lack of domain knowledge; it can also stem from unfamiliarity with the technical stack itself.

This is why I advocate for a "less is more" philosophy when it comes to technology choices. Instead of introducing unnecessary complexity, it's often better to streamline and standardize the tech stack. This approach involves making judicious selections for key components, such as:

1. Database: Pick one primary database solution that meets the majority of needs.

2. KV Store: Choose a reliable key-value store for caching or other use cases.

3. Internal Communication Protocol: Standardize on a single protocol (e.g., RPC, JSON over HTTPS, Kafka) for inter-service communication.

4. Primary Development Language: Settle on one language for service development and one tech for the front end (React, Vue, etc.)

5. Core Framework: Within the chosen language, adopt a single robust framework for building services.

6. Monitoring: choose a telemetry stack and integrate it into the core framework.

By minimizing the number of technologies and frameworks in use, teams can develop deeper expertise and familiarity with the chosen stack. This focused approach simplifies onboarding and knowledge sharing, allows more targetted recruiting, and lowers the barriers to employee migrations between teams. 

Moreover, a streamlined tech stack can facilitate better collaboration, easier maintenance, and more efficient resource allocation. When teams aren't spread thin across various tools and platforms, it becomes easier to identify and address the bottlenecks effectively, leading to improved overall productivity and resource utilization planning.