“Are there any questions?”

All too often that simple and reasonable question goes unanswered. Answer it! Read on…

A regular topic in my discussions with our various team leads and subject matter experts is the lack of feedback or questions of any sort when they’re presenting a concept. It goes like this:

The team is gathered on Zoom to discuss a feature request. The product owner and business analysts put together a well thought out series of user stories and are now presenting it to the developers and quality team. There is no interaction, the PO is wondering if the stories are really that clear or if they are losing everyone.

The PO keeps moving forward. With no feedback along the way, when they get to the end, they ask the question:

“Are there any questions?”

A wall of silence.

Three days later, a developer starts working on a story. They immediately have a bunch of questions.

The PO and BAs are now working on the next sprint’s stories. They change gears, answer the questions, and get back to their other work. The developer finishes and hands it off to QA for testing.

QA goes back to the PO again and asks a bunch of questions. Meanwhile

This happens over and over again.

The PO and BAs eventually conclude no one is paying attention when they present the stories and give the opportunity for questions. “Engagement is low” I hear.

Pick a topic, it’s not just user story discussions, and this same pattern repeats. Someone presents a concept, they are met with a wall of silence, and only later do they hear anything in the way of feedback.

The overwhelming frustration at awkward silence being the routine eventually leads to the question “Is anyone even paying attention?”

Now, I get it… sometimes you truly didn’t have a question in the meeting. You needed to think a little more about it and it’s not uncommon to realize there is a question only after the next step begins. If it happens only some of the time, then it’s ok. When it becomes the routine, then the doubt creeps in and the continues to grow and the fury follows.

“Why am I bothering?”

“These meetings are useless.”

“I don’t have time to do my job because I’m always answering questions later.”

When they reach questions like the last one, no one wins.

There are at least 4 ways to respond in Zoom and Teams(verbal, chat, reaction, and body language via camera come to mind) when someone asks if there are any questions. Use the tools to clearly indicate “I heard you, I don’t have anything right now.”

If you are the person leading the meeting who is feeling unheard, then be bold! Ask a couple of people directly and make them answer: “[name] do you have any questions?” or even “[other name] what do you think about [some point made]?”

Whether presenter or audience, don’t let “Are there any questions?” go unanswered.

Otherwise, your leaders will be asking “Is anyone even paying attention?” and concluding the answer is no.

A quick post on my own story on going through a “return” to office mandate - 22 years ago.

“Return” to office mandates - 2003 edition

In 2003, I was working remotely for a job that hired me in 2000 to be remote. My employer now wanted to centralize the team as part of a larger reorg.

They made it clear that there eventually would be an ending to my role if I didn’t move but they were giving me plenty of notice. On the other hand, if I accepted the move, it meant I’d be moving to a lower cost of living area without an adjustment in salary - effectively giving me a raise. My employer paid all of my moving costs and gave me the time off that I needed to make the move. We agreed to a time frame that included waiting for me to finish my MS at Pace. Finishing my MS wasn’t even that much of a factor in that timeframe as others from the team waited several months longer before moving. Back then, moving for your job was tax deductible, so even if your employer didn’t pay for it, you could at least get some back on your tax return.

A few years later, they paid to move me again. This time, with the move to the Bay Area, I got an adjustment to cover the cost-of-living difference.

And that was all the norm for a company of any size that was asking you to make a shift like that.

How many people getting RTO’ed today when they never were in the office they are expected to return to get any compensation for it? Yeah, don’t answer that.

You hit all the points on the job description. Why aren’t you getting a call? It’s not the Applicant Tracking System (ATS) filtering you out. It is not the Talent Acquisition (TA) team. It is one of the hiring managers, maybe myself. How do you “get by” me?

I know creating a resume is stressful, you get conflicting advice, and you might be doing it when you are out of work and all that stress and contradiction will try to overwhelm you. In this article, I hope to help a little by taking a swing at explaining what I think when I review resumes. As always: Warning- Opinions Ahead!

This post picks up the theme of a post I dropped in October last year about dev lead resumes. It is still true: most - almost all - resumes I am seeing lately are nothing more than a summary of job descriptions. Throw in a key performance indicator or two and you have… a resume that looks like every other resume. That is bad!

Presume I have only one position open for a role. Your resume is in a pile with hundreds of other resumes. I need to pick one good one out of hundreds. You need to be the one I pick out of hundreds. If I have 200 applicants for one position, there are probably at least 20 that will be ok for the role. We agree that my task is easier than yours, right?

You need to stand out. Gimmicks such as formatting your resume like a brochure only run the risk of obscuring key detail. The best way to stand out, at least to me, is provide good information.

That is easy, you think. Yet, resumes like this simplified but not far off example are the norm for what I see:

Pat Lee
pat@example.com

I am a results driven test professional who uses state of the art tools to 
achieve my OKRs and KPIs. With my leadership in QA, we were able to test
our widgets.

Acme Corp
2020-2025
Senior Software Engineer in Test

- Wrote test cases for BXD NextGen
- Wrote test automation
- Tested apps
- Reported bugs
- Led a team of three

Goals met:
- Achieved 80% test coverage
- Enabled revenue growth of 1 million.

Tools used: Widget Test Studio, VS Code, WTSE, Jira

Ajax Corp
2018-2020
Manual Software Tester

- Wrote test cases
- Tested apps
- Reported bugs

Goals met:
- Achieved 50% of my annual goal in 6 months

Tools used: SQL Server, Jira, BrowserStack, BSDS

My reactions to fake Pat’s fake resume

It technically hits all the points it needs to match our job description (ok, it needs a little more, but you get the point). The level of terseness above is extreme compared to what I normally see, but terseness seems to be the norm. While a wall of text gets hard to read, nothing but terse bullets makes you sound like a video game character. “Short” resumes should not be dull resumes. No hiring manager I know is currently disqualifying candidates because they have a long resume - they may move on to the next in the pile if it is verbose word spam. Say what you need to say - not more and not less. You want a succinct resume, not terse resume. I hope to help you find the balance.

Pronouns help me understand

I do not care one whit about the first-person or third-person debate (“I did x” vs “Pat did x”). It’s worse than arguing tabs vs. spaces. I do not care if you choose gendered or non-gendered pronouns. I know some people care and will hold it against you, but they are jerks so you should not care about them. Reasonable people know you are getting conflicting advice, so will cut you some slack. You want to work for and with reasonable people, right?

But please clue me in that you’re a person! Most resumes now are written in the “no-person” voice. Please pick first- or third-person and stick with it. Why do I, as the person reading it care? It forces you to say whether something was a team accomplishment (That’s good. You are applying to join our team after all.) or your own accomplishment. It also makes the resume flow and forces you into a more natural voice. If you are concerned about being too wordy, you can do a little combo magic:

In this role, I:
- Wrote test cases
- Tested applications
- Reported bugs

What the heck are BXD, WTSE, and BSDS?

Are these niche tools you bought/open sourced somewhere? Are they internal applications? Are they internal test processes? I have no idea. Both of our brains shrink when you use unexplained jargon. Expand your acronyms! If they are internal systems, give me a few words on what they do. I’m not your former employer. If you want me to be your future employer, give me a clue.

While I’m at it, “apps”? Applications please. Yes, we all probably know what you meant, but it runs the risk of sounding lazy to someone. Do not sound lazy, ‘k?

The KPIs don’t add up

Every list of resume tips and tricks that’s worth the read will tell you include some actual measurements. I agree. Please make sure they make sense for the role.

You led a team of three… what? Other testers? Were you the leader of an entire development pod and had devs reporting to you too? I do not know. Help me out here.

You got 80% test coverage? What does that mean? Why did it matter? I do not even know how you define coverage. Covered all the branches in code? Covered all the methods? Wrote one test each for 80% of user stories? Covered 80% of regression test cases? Was it even valuable? Once I know your environment, I can crank out coverage pretty darn fast. It will be junk that doesn’t actually validate anything, but it will be coverage.

How, as a senior automated test developer, did you enable 1 million in revenue growth? There’s a connection missing here. Missing that connection means you take the risk I will to conclude you either have no idea what you did to help the company, are taking credit for someone else’s victory, or both. That’s all lose for you.

“Achieved 50% of my annual goal in 6 months” is a paraphrase of one I’ve seen recently and they highlighted it as a major accomplishment. Without any context, it sounds like they are bragging that they hit the minimum. Need I say more?

Who was that?

Acme and Ajax - there’s probably dozens of companies with those names. I can’t tell which one you worked for. If I need more people with experience in my industry (or consider it a nice bonus), you are missing an opportunity to distinguish yourself. That’s a symptom of a bigger problem here: you said nothing about what you were working on. Cloud application? Traditional web application? Embedded software? I do not know. What was the business goal? How did it help users? If it does not matter, you lost nothing saying it. If it does matter, I am picking a candidate that states it.

Do you know why it matters?

Please, for the love of chocolate, show you cared about your job and understand why it mattered to your employer. If you show that you understand how to make a positive impact, it will positively impact your chances of getting the job, not just an interview.

Bare statements like “Tested apps” make me wonder if you know why it matters. If you don’t know why it matters, then I do not know if you will be able to adapt what you know how to do to a new environment. I also do not know if you cared about the outcome. You were there, that is all I know. Were you a rockstar? Were you a steady, reliable teammate? Or were you the person who was just trying to game that job as long as you could before getting called out? I do not know. Other candidates are making it clear that knew why it mattered and that they cared. Who should I pick?

For some of the points you make on your resume, answer these questions:

• What did you do?
• Why did it matter?
• How did you do it?

You do not need to answer them in the same order and do not need to expand every point on your resume this way. Focus on the things that carried a demonstrable impact for the organization or that helped you grow. You can cover it in the introduction paragraph for the resume if it was really a point you want to highlight, in an introduction paragraph for the role, or somewhere else that looks good to you. Just make sure it’s there.

Let’s just take this accomplishment: “Achieved 80% test coverage”.

Every leader in QA automation includes that line. It needs more “so what” added to it.

Try this:

“I shortened our regression test window from days to minutes by automating 80% of our test cases. This increased development capacity by 15% per month by reducing our code freeze window.” (Code freeze windows are topic we’re not talking about right now. I will not be baited.)

When I see that, I know you get it and know you care.

Conclusion

Read a hundred internet pundits’ opinions on resumes and you will get a hundred internet pundits’ opinions on resumes. The stakes are always higher for you than for the hiring manager and you have difficult choices to make. I understand that and hope this helps even if you take a different path with your own rez. Good luck!

Look! Yet another study about developer productivity! This time, it is a Twitter post made by a Stanford researcher who claims 9.5% of software engineers do almost nothing and are “Ghost Engineers.” In this post, I consider a couple of my own development anecdotes in light of this and the experience gained examining productivity within various teams over the years. The long and short of it: looking at code is not a valuable measure of individual productivity and individual productivity should not be what we are measuring anyway.

The twitter post in question points to a Stanford U page. The only research paper linked from this page does not appear to be this study the original Twitter poster is making claims about, but it is related. In follow up posts, the poster did back pedal, but the damage is done. At nearly the same time, AWS is making the social media news for the shocking news about how much time developers are spending not writing code - instead lamenting, among other things, that they spend time testing (AWS is trying to sell you AI tools to solve this problem of course). Non-development leaders see blurbs like those and conclude they need to crack the whip on their developers instead of taking a more holistic view.

Going back to my days working on systems at PWC, leaders have periodically engaged me to evaluate team performance. At PWC, it was as a manager in one group looking at another group. During my time at Capax Global(since merged into Hitachi Solutions) and West Monroe, these occasions came as part of a formal consulting engagement. In most cases, the leader knows something is awry, has a pretty darn good sense already what it is, and is looking for validation and making sure they’re not missing something.

So in that time, can I conclude that “ghost engineers” exist? Yup, they do. Pick a profession and there’s going to be people whose main skill is avoiding useful work and they will spend an awful lot of energy in the process. There will be others who want to do well, they just do not have the right skills. You might be able to help the second. The first? Good luck. This is not new or unique to the development profession. To quote Ecclesiastes 1:9 “there is no new thing under the sun.”

Can we find those “ghosts” by looking at work output? Let’s start by looking at two of my own coding stories.

A definition before we get too far for those who may not be development managers: when I say “commit” or “code commit” here, think of it as a developer calling some work done and sharing it with the rest of the team by sending it to a shared location.

An anecdote

I came home from the office one Friday night in 2004, ate dinner, and opened my laptop back up. In the course of about four hours, I built an entire database with hundreds of unique tables with all their foreign keys, initial indices, and all the basic stored procedures needed to save, retrieve, and delete records. Monday morning, everyone was astounded. We were planning on it taking several weeks of developer time with the UI and App tier devs needing to drag out other work until the database was ready, yet here we were all ready to go on to the next stage. Was it a miracle? No. Was I a mad genius? No.

The only solo work I did was create the scripts transform the work we did collectively.

My burst of productivity came from the month or so of white boarding with the team and creating a data catalog without being bogged down in minutiae of turning it into database schema as we went back and forth over the data model. Once I had that first data catalog in hand, all I needed to do was export it into another format, add the SQL Data Definition Language (DDL) syntax around field and table names we had in our catalog and I had my DDL scripts. If you looked at my commit that week, I was REALLY productive, but only because myself and a few other people hashed everything out and then we wrote it all down in a structured format. The only solo work I did was create the scripts transform the work we did collectively into DDL.

None of those other people would get any credit for that work if all we did was look at code committed in the form of the final DDL. We didn’t even have a way to track anyone doing a code review to give them credit for doing even that part.

Another anecdote

In 2016 a client of mine struggled with the performance of one particular bit of business logic that drove a key feature in their product. They knew it should be faster, several of their senior developers spent quite a bit of time trying to improve it, and they still struggled to identify the reason is ran slow.

My toolbox for performance analysis was a little bigger than theirs, so I got cracking. Performance analysis takes time. There will be many red herrings. There will be many obvious things that save a little time but not a lot of time. There will be frustration, burnout, and a feeling HR is coming for you. There is nothing fun when you are in the middle of fixing performance issues. The reward only comes at the end.

By the morning of Day Three, I realized the performance data collected didn’t add up. If code is a tree, when I added up the amount of time that all of the “leaves” took to run, it didn’t match, or even come close, to the time when I added up all the “branches” those leaves were attached to. It took to that third day to get my clue: the problem wasn’t an algorithm. It also wasn’t a missing database index or needing to regenerate an index.

The root cause? Entity Framework(EF)¹ being told to do too much. The code that queries the database returned an IQueryable object. The code that called that code did some manipulation (a loop) and passed IQueryable up to the code that called it. Add a few more layers of that and the core bit that orchestrated all of that business logic still worked with IQueryable objects. EF likes to try to defer execution of any database query that returns IQueryable as long as it can. It’s trying to understand the whole of what you are doing so that it does not need to make a lot of very small calls to the database. We call a lot of small calls being “chatty” and the back and forth can eat up a lot of time. EF assembles all those calls into a big query and most of the time does just fine. This time? It couldn’t figure out how to make an efficient query out of all those layers and ended up basically with nested code inside of nested code inside of nested code, etc. It was sending THIRTY pages of SQL commands to get one result back.

All I had to do to fix it was change one word.

My code commit to fix all this? Figuring out how to break that chain and tell EF to make a few calls instead of one. All I had to do to fix it was change one word. I changed IQueryable to IEnumerable in the right place to stop the deferred execution² and cut the command bloat down. A one word code commit that had everyone dancing for joy because a process that took dozens of seconds now took less than one.

So what is productivity anyway?

In both cases, I spent some time and provided value. In case one, I spent a little time on creating a lot of output precisely because I was the fingers put on the keyboard for a whole team. That then accelerated the whole team. If did it all by myself, it would have taken 4-5 months (more time than the 3 or us who put most of the time into the model) and the team would be blocked. In the second case, others spent time, but it took someone with better tools to get to the bottom of the problem and my “output” was pretty small: one word. No one cared it was one word, they cared that it worked.

The productivity that matters is the value provided, not volume produced. How much code I wrote in either case is trivia. If management measured my productivity by raw output, they are incentivizing me to not get work done. I don’t spend a Friday night finding a way to get the result soon — I would drag it out for several weeks to make my average look better. Later, incentives drive me to add a bunch of useless changes to code to make my one word change look bigger (and take more time to do it). In both cases, the outcome is worse for the team and the business.

As I mentioned above, on many occasions, a leader called on me to analyze team productivity. That involved looking at code commits, looking at bugs reported, looking at how much time someone is spending on development, and more. Interviews and discussions with developers, CIOs, CTOs, stakeholders, systems architects, team leads played a crucial part in understanding the context of both the system and the team. So, who gets the most done when we measure code output? In most healthy organizations, it’s the mid-senior developers. Conversely, the “professional ghosts” (meaning, those very few people who would rather do nothing) know people their work will eventually be looked at so they do the bare minimum to get by.

Who commits the least? The team leads and, often, the most skilled developers on the team. They’re helping everyone else! And they ought to.

Going fast instead of going well leads to … the team going slower

If the most productive person is a team lead, that is a sign of a problem (Rule 59). Except in small teams, leads and other senior-most developers spending most of their time writing code³ and focusing on volume produced is a sign that they’re not spending their time understanding the business context, understanding best design, making sure knowledge is spread around, and generally focusing on ways to make the team effective. There are often deep technical issues and organizational dysfunctions at work: a focus on “get it done now” instead of “get it done well” is common and often isn’t even coming from executive leadership. Going fast instead of going well leads to poor testing (Rule 14), mounting technical debt, and the team going slower and slower over time instead of faster and faster as the team grows its capabilities and the systems gets better.

Conclusion - follow the money

What incentives are you creating when you measure individual coding “productivity?” You are saying “don’t think” and “don’t research.” You are also encouraging “roll your own” instead of looking for existing libraries. Why reuse when you can reproduce? When you tell me that individual productivity matters, you are telling me that the only thing that matters is how good I look, not how well the team performs or the organization performs. The message I hear, to turn the classic phrase⁴ on its head, is that “you are paying me for the code, not the solution.”

The result is that I’m going to spend weeks developing a calendar dropdown control for the website instead of spending a day or two evaluating which of many off the shelf options (many free in one way or another) I should recommend that we use.

As professional technologists, it is the solution that matters, not the code. When team management becomes code counting, no matter how intelligent that code counting is, we send a very clear message that our developers are drones who should not ask questions, who should do instead of think, and who should expect to be laid off/downsized/RIFed at any moment. Is that the team you really want to work with?

Let your leaders manage the “ghosts” and focus on the team’s well being. You will be happier, your bosses will be happier, and the team will be happier even if there are a few hard discussions along the way.

While messing around a little bit with prompts in Bing Copilot, I asked it to create a programming language that was easy to code and hard to debug. What did I get? The results were surprisingly unsurprising.

The Prompt

Create the basic syntax for a programming language named fwfvevetgh34gdfvdrrtg. It should be easy to use, but hard to debug.

The Response

Sure, let’s create a basic syntax for a fictional programming language named fwfvevetgh34gdfvdrrtg. We’ll aim for simplicity in writing code but introduce elements that make debugging challenging.

Basic Syntax for fwfvevetgh34gdfvdrrtg

Variables

var x = 10
var y = "Hello, World!"

Functions

func add(a, b) {
    return a + b
}

Conditionals

if (x > 5) {
    print("x is greater than 5")
} else {
    print("x is 5 or less")
}

Loops

for i in 1..10 {
    print(i)
}

Debugging Challenges

1. Implicit Type Conversions: Variables can change types without warning.

    var z = 10
    z = "Now I'm a string!"
   

2. Silent Errors: Errors do not produce messages; they fail silently.

    var a = 10 / 0  // No error message, just fails silently
   

3. Ambiguous Syntax: Similar syntax for different operations.

    var b = 5
    b = b + 1  // Increment
    b = b + "1"  // Concatenate, but no error or warning
   

4. Hidden State Changes: Functions can modify global state without clear indication.

    var globalVar = 0
   
    func modifyGlobal() {
        globalVar = 42
    }
   
    modifyGlobal()
    print(globalVar)  // Prints 42, but no indication that modifyGlobal changed it
   

This language is designed to be easy to write but introduces subtle complexities that make debugging a challenge. If you have any more ideas or need further details, feel free to ask!

My Conclusion

The result looks like something between JavaScript and Python with maybe a taste of Ruby thrown in.

It seems to me that the model managed to pickup on the commonly cited strengths and criticisms of higher level languages like JavaScript and Python and translated my prompt of “easy to code, hard to debug” directly along the lines of those popular views.

My takeaway? It is a little more anecdotal evidence that LLMs can be pretty darn good at summarizing the content of the internet and turning that into new output - if only semi-useful output.

Thought: If you’ve got a position listed on your resume that says “Software Development Team Lead”, the description of the role should start out with things you did as a leader.

The first 4 bullets should not emphasize your individual code contributions, especially if you’re applying for another Lead job. It makes it look like you had an inflated title, will emphasize yourself over your team, or both.

I’ve even seen Dev Managers who emphasize individual contributions over how they helped their team. The other variant on Managers is it’s all “here’s what the team did” and still little about how they helped their team. Was the team successful because of you or in spite of you? What philosophy did you apply to management? You have a management philosophy, right? Tell me about it!

Stop with the resumes that list your job descriptions and start focusing on who you are as an individual. It may not get you more bites, but I earnestly believe it will get you more quality bites from companies you want to work for.

This year my focus is on collecting my thoughts on being a manager. A large part of that is hiring your team, so we’re in a series on the hiring process. This time, a couple of notes on conducting a video interview.

Most of our interviews these days are done via Zoom instead of in person. It influences a little bit of what I do in the interview, but not much. If anything, I do more at the beginning of an interview when I’m in person: checking they have water or other beverage if they want it, making sure there’s not a bunch of noise that will be distracting, tidying up any cables strung around the conference room, etc.

There are a few things I do think about differently when conducting these interviews though. If anything, it is more important to think about the space and setup you have for a video interview vs. an in-person interview before you get there.

Posts in this series so far include creating job postings, reviewing the resumes you receive, and the first part and second part of getting ready for interviews. In this post, I discuss some specifics about conducting video interviews.

Have a good setup

I am a little bit of a stickler for having a good video call setup. The most important part is not the camera. Any decent webcam will do ok, just make sure you have good lighting in front of you so the candidate can see your face. Good lighting in front of you means the light in front of you needs to be brighter than any light behind you - it takes a lot of light to overcome daylight coming through a window behind you even on a cloudy day. Do not be a talking shadow (unless you are, of course, a talking shadow).

The part of your setup that matters the most by far is your microphone. This is a general truth: we tolerate bad imagery far more than we tolerate bad sound. If the candidate cannot hear you clearly, you add risk they will not have a favorable impression of you. The “big two” video conference tools (Zoom, Teams) do a really good job of making your speech clear, removing background noise, and reducing echoes, but they cannot work miracles. I even go as far to have chunks of acoustic foam in my home office to help. My microphone is a Shure MV-7 on a Rode arm that I can pull right up to my face if needed. That’s probably overkill for most, but I’m in so many calls a day that I get tired of headsets and I’m one of those people who cannot keep earbuds in their ears for very long¹.

Set up a practice call and record yourself. You won’t regret being sure the other party gets a favorable impression.

Dress like you are in person

Ok. You do not quite need to dress like you are in person, but you should at least wear a shirt that looks like someone working in the office would wear. They won’t see your pants so sweats might be ok. Remember that you want to create a good impression. Brush your hair too and if you are inclined to shave/wear make up/whatever before heading into the office, you probably should do that too. At least replace the “I’m with stupid” t-shirt with a polo.

Starting the interview

When the interview starts, make sure you both do mic and camera checks. Be patient - the candidate is probably using their home computer or phone and may not use your video call tool all the time. Build in five minutes just for this.

Require them to use their camera

Require the camera to be on. You want to see the candidate’s reactions partly to be sure they understand the questions, partly to get to know them better, partly to help make sure they are not talking to someone else or typing away because they are getting answers from elsewhere, and partly so you can take a picture …

Take a picture

Make sure the candidate has their video turned on and take a picture using your computer’s screen capture utility. Make sure the person who goes through the interview process is the person who shows up for work! KnowBe4 disclosed an attempt by a North Korean hacker to infiltrate them via employment - KnowBe4 only caught them after they started working because their security tools detected a sign-in from a different location. More mundane cases of fraud include one person doing interviews for a friend, then the friend shows up to work. Another all too common occurrence is a person getting hired but having people offshore do the work. That work will often be lower quality because the actual person doing the work isn’t properly integrated into the team and there’s nothing you can do to get the person you thought you hired to improve. They set out to cheat you after all! On top of that, the person who you think you are hiring will often keep 80% or more of the pay and send 20% or less to the actual worker. Do not forget to consider the security and potential legal issues that come up with a person working in an unknown country to think about.

While I do strongly recommend this practice, you should check with your human resources or legal team to make sure there are not laws in your jurisdiction that need to be considered. Being exposed to some variation of the fake employee scam is inevitable for any organization and needs to be balanced against any concerns about how a law might be interpreted.

Conclusion

The content of my interviews do not change much between in person interviews and video interviews. I lose the opportunity of using a whiteboard (I have never gotten used to digital whiteboards), but it hardly ever feels like an impediment. Given my organization is a mostly remote organization, it also helps me understand how effective the person can be when remote. The biggest risk is employment fraud on the part of the employee and that’s only getting to be worse with AI driven content tools as demonstrated by KnowBe4’s incident. Be alert for any oddity and be comfortable that “odd” is often your gut feeling when something is wrong. Do not let FOMO (fear of missing out) take precedence over a nagging concern.

This year my focus is on collecting my thoughts on being a manager. A large part of that is hiring your team, so we’re in a series on the hiring process. Posts so far include creating job postings, reviewing the resumes you receive, and the first part of getting ready for interviews. In this post, I share more thoughts about getting ready for the interview.

This sequel is another list oriented article, so I will just repeat the introduction from Part 1:

The purpose of an interview is to determine if the candidate is a good fit for the job. Many of the traps we fall into during the interview process come from forgetting that.

Remember, interviews go two ways. You are selling the candidate on the organization just as much as they are selling themselves to you.

Know the decision making process

Before you get into the interview, know how you will get your feedback to the rest of the team or collect the feedback from the rest of the team. Generally, I ask our in-house Talent Acquisition (aka internal recruiter) to manage this part of the process along with the scheduling. The reason is simple: if I am communicating with the other interviewers who come after me, I run the risk of communicating something that adds unintended bias into their own interview. I’m the lead of our group and if I share my opinions, even people who are quite used to working with me will tend to be swayed by my own view. Even when the relationship between interviewers is a peer relationship, bias will creep in, so don’t share notes. It’s perfectly ok to ask a subsequent interviewer to dig into topics you did not get too or when you realize afterwards a response may have been more nuanced than you originally thought.

The most important reason to know the decision making process beforehand is so that you will make a decision quickly. Do not lose a candidate to another organization because you waited two weeks and that organization got the offer to them first. Getting beat to the draw by other organizations is going to happen even when you turn around decisions next day, so do not dawdle.

Know who they’ve talked to already

It’s small, but it’s helpful. If you’re first, you know you need to do more to help the candidate to understand the role (there is always a nuance not quite captured in the role description). If you are not the first, the candidate seems more likely to have a question or two for you at the beginning of the interview.

Know your introduction

The first five minutes sets the tone for the interview. Here’s how I do it:

1. (for video interviews) Dialing in - make sure your setup is good and make sure the candidate’s setup is ok. Be gracious if they need a minute to get setup, it happens. Require their camera to be on. I will be posting more on this in the future. Some more tips on video interviews can be found in October’s post.
2. Say hi, briefly introduce yourself. E.g., “I’m Jim Leonardo and I’m the chief bottlewasher” and prompt them for their name. Given some of the fraud scenarios that seem to be popping up with more regularity, don’t blatantly ask “are you so-and-so?”, ask them for their name. There’s also the oh-so minor detail of making sure you’ve got the right person so you’ve got the right profile in front of you.
3. Do a more extensive introduction of yourself. Have this little talk ready to go. I reiterate my name and role, give them a quick overview of the company from my perspective, describe what I do, give a once sentence synopsis of my history, and why we’re talking. My goals right now are to:
   1. Put the candidate at ease.
   2. Make sure they know who they are talking to so they answer at the right level. I’m head of IT, a candidate for a software development related role may assume I don’t have a development background if I don’t tell them.
4. Ask them if they have any upfront questions. This usually goes like this: “I know you talked to Tony Stark already, do you have any questions before we dive in? This is a conversation, so you can ask as we go too and I’ll leave time at the end as well.” About a third of candidates will have questions at this point. They’re usually pretty simple, usually clarifying a point about the role.
5. Now ask them to give a brief synopsis of their professional background. I am a stickler for making sure I get it across to them that I am asking about their professional background and not their life history. “Would you please give me a brief overview of your professional background? Focus on the more recent and more relevant bits. Resumes usually don’t get quite the essence of what you’ve done across.”

From there, we get into the substantive questions …

Have your questions ready

The first part of having your questions ready is making sure you know what kind of interview you want to have. You aren’t going to get both an in-depth technical interview covering specifics of coding and a high-level software architecture interview and a deep dive into their leadership background done in 45 minutes while giving them any chance to get to understand your organization. If you do somehow need to do all three (and more), I suggest having others cover those parts.

Without getting into specifics for a given type of interview, here’s a few things I look for when creating questions:

Good questions are relevant to the job. They especially should not be brain teasers that often are more of a trivia question than a test of problem solving. “Given a fox, two chickens, and a canoe, how do you get all of them across a river without a fox eating one of the chickens” is a terrible question! “Why are manhole covers round” is also terrible. The answers are trivia - both are well known brain teasers and someone on may have read the solution without ever solving it for themselves. They also are unlikely to be relevant to the job.

The best questions require more than a three word answer. It will encourage an in-depth answer. “Why are cursors often considered an anti-pattern in database querying?” is a good question for someone who will be a database admin or database developer because it is asking for rationale, not just a yes or no answer. It’s also good because you are asking for something that (I hope) is general knowledge for the role. It’s also a good question because If the person disagrees that it is an anti-pattern, you’re not forcing them to defend that position, you are asking why it is a common view within the profession. Still be careful - this particular question is somewhat safe because there’s a solid rationale. Which brings us to …

If you ask an opinion question, understand the range of potential good answers and know that sometimes the best answer is the surprising one. Opinion questions can offer good insight into how someone thinks, but be very sure of your own opinions and understand why they matter. Interviews are not the place for the tabs vs spaces debate. Sorry, I’m not stepping into that particular morass right now. I’m certainly not going after the opening curly-brace question either.

Outside of the opinion questions, a good question will also be about something the candidate can be expected to know and that you know the answer to. Asking a candidate to solve a distributed network problem you don’t know how to solve is a bad move - you can’t evaluate the response. The other side of this if fact check yourself too! One of my most interesting conversations when I was the candidate was with someone who was starting to get smug that I couldn’t solve his performance optimization problem. After I explained in detail why I thought it couldn’t have an answer, I asked him what his solution was. His solution was flat out wrong. At least he had the grace to accept that once I went into detail why it was wrong. His solution wasn’t bad for solving the real business problem, but his question was phrased to require “constant time” in “Big O” analysis terms and his answer was most definitely not constant time. He had not checked his problem with someone else and so had bad question.

Unless you are interviewing an internal candidate who is switching teams, etc, keep your company knowledge out of the interview. Questioning someone on how to use your custom solution is only going to leave you disappointed. And yes, I do have to say that, because it is a thing.

In almost all cases, also keep the hard questions you’ve had to solve as a company out of the interview unless you’re looking for a specialist in that particular area to help make those problems not-so-hard in the future. That performance optimization problem? Yeah - it was a thorny problem that took a fair bit of time to solve. Expecting a candidate to solve it in the moment is just plain unrealistic. The distributed network problem I also mentioned? Also from the interview for a real job I applied for about 15 years ago. At least in the performance problem, he had an answer. No one at the company with the distributed network problem knew how to solve it. I did solve it once they hired me, it just wasn’t solvable in 20 minutes (remember that bit about “looking for a specialist” - I’m not quite that, but this did fall into a type of problem I worked on at that point in my career).

The biggest thing to not do for the vast majority of roles is asking questions where you expect the candidate to challenge or contradict you. This is firmly Rule 62 territory - if you’re not a psychologist, don’t act like one. In an interview, the candidate is threading a needle of putting their best foot forward while also presenting themselves as a good worker who will be easy to get along with, etc. Similarly, asking questions that have “obvious” flaws and expecting the candidate to spot the flaw without you telling them the question may be flawed is also a bit of psychology. You just cannot tell if the candidate is going to assume the problem is with them instead of with your question. They will freeze, they will blow the rest of the interview, and you will miss a potentially good candidate because they did not realize that you were playing dirty. It is not automatically wrong, but you better know what you are doing. Springing that trap on an entry level candidate is not testing their critical thinking, it is testing their skill at being interviewed.

Conclusion

Being prepared to conduct an interview takes effort. You are trying to figure out how a person will work for you day to day by creating a totally artificial environment and pretending that it will give a great result. Some people do well at interviews because they have plenty of practice at it but then cannot do a lick of work. Other people will bomb interviews more often than not, but will be awesome members of your team. Most will be somewhere in between. Like anything else, learn from both your successes and your mistakes and continually improve.

Next time: a few things specific to video interviews that I practice.

And oops … forgot to actually hit publish on this one in September. 🤦

Taking a pause from my series on becoming a manager(latest post), I took a morning to update my Expressur basic arithmetic library so I can test claims that .NET 8 had significant performance improvements over .NET 7.

Short answer? Add me to the people who say “apparently yes”, at least for pure C# code.

The real reason I built Expressur is so that I would have a meaningful but straightforward set of code that can be ported to almost any other language so that the languages can be compared. It does this by taking a normal problem — arithmetic — and using string manipulation, iteration, and primitive operations. It does not use much in the way of additional libraries, it’s pure C# code. That makes it a good candidate for doing an apples-to-apples comparison between two different versions of the framework. There’s no possibility of a bug or newly added features of a third party library causing issues¹, no network in the way, and not even any reading or writing from input/output files.

Expressur features a test harness to facilitate performance comparisons (I mentioned it in my writeup on Rust), so performing the comparison between the two versions of dotnet was a piece of cake: run the test, then update the version, build, and run again.

This is done using Expressur.LoadTest. Expressur.LoadTest is a simple executable that runs a very simple load test for Expressur. In five minutes, it evaluates the following three expressions as many times as it can:

    cplusaplusb = c + aplusb
    aplusb = a + b
    extraindirection = (aplusb/ cplusaplusb)

It uses these values as initial seed values:

    a = 1
    b = 2
    c = 3

On each iteration, it will encounter cpluasplusb before it knows the answer to aplusb and thus also not know how to resolve extraindirection, so that it fully exercises Expressur's deferred evaluation on each pass.

"As many iterations as it can" is somewhat qualified. To both simplify the code and prevent the load test code from adding too much overhead that would skew the results, it runs in batches of 1 million. After every million batches, it checks if the total run time is greater than 5 minutes. If so, it ends. i.e.:

    while (time < 5 minutes>) {
        run 1 million batches
    }

As a result, the run time will always be slightly greater than 5 minutes except in that rare case when the last batch was completed at exactly 5 minutes.

Running the same code built for dotnet 7 and 8, I saw these results:

An almost 14% improvement is impressive when no code in Expressur changed at all.

While these results are encouraging, most apps I have worked on end up throttled by inefficient code (Expressur is by no means optimized!), network, database, or other computing environment issues instead of raw performance of the underlying code engine. Given my results porting Expressur to Rust didn’t seem to make it any faster — I suspect I would have to revisit all the string manipulations to get better Rust performance — seeing C# going even faster makes me stop and think if pursuing a language that is hard to master (Rust) is worth the effort for most of us. I guess the next more technical article will be updating the Rust version of Expressur to see if that performs any better.

Footnotes

Over the last few months, I’ve put a few thoughts out there about creating job postings and reviewing the resumes you receive. In this month’s post, I share some thoughts about preparing to conduct interviews. There’s much more said on the internet about conducting interviews versus creating job postings and reviewing resumes, so this is going to be a bunch of notes.

The purpose of an interview is to determine if the candidate is a good fit for the job. Many of the traps we fall into during the interview process come from forgetting that.

Remember, interviews go two ways. You are selling the candidate on the organization just as much as they are selling themselves to you.

Scheduling

The scheduling process is one of the first impressions the candidate gets of your organization. We all are busy, but do everything you can to make it a smooth process. You are not going to get good people if you cannot get them scheduled.

1. Make sure whoever is doing the scheduling knows your schedule. We use Microsoft Outlook and anyone in my organization can see the open spots on my calendar. I make sure to keep it up to date and block off heads down time when I know I will need it.
2. Attach the resume or a link to the resume to the invite! Going back through emails or logging into and navigating through your HR system to find the resume wastes too much time.
3. Even if you are not going to schedule all the interviews for a candidate back-to-back, get as many set up at once as you can. Lately I tend to favor a first interview with the direct manager getting scheduled. If the direct manager is satisfied, then the recruiter will work with the candidate to set up the rest (usually 2). We don’t wait for feedback from one before scheduling the rest.
4. Once it is scheduled, the interview gets priority over almost anything else. Only a true emergency that well and truly needs action NOW disrupts an interview. Delegate anything else. Make this rule the norm in your organization and it will not be a problem. If you report to me and I ask for an on the spot meeting, “I have to conduct an interview” makes me wait, not the candidate.
5. If I have a meeting before the interview, I make sure to leave 5 minutes before the interview starts. It takes time to make sure Zoom is running, bring the resume up, and get my notes ready.
6. If you are not going to be the direct hiring manager, have a back up so that if something unavoidable comes up, you can keep the schedule.
7. If it is a remote interview via Zoom, Teams, or other video chat, make sure the candidate knows their video camera needs to be on and then has it on. We have had issues up to and including a different person showing up for the interview than who showed up once hired.
8. Avoid panel interviews. Even with two interviewers, one of them should be the lead and the other mostly observing. A group “meet and greet” is ok if the purpose it to introduce the larger team the candidate will be working with, but make it clear it is not an interview and make it the last step.
9. More interviews are appropriate for roles with significant seniority. A long battery of interviews for an entry level candidate isn’t appropriate.
10. Do not send candidates skills tests or projects before their first interview and make sure skills tests are short and relevant. Remember: the interview process is a two way street. You are optimizing your workflow at the cost of telling the candidate you are willing to waste their time by forcing them into a time consuming evaluation before they even get a chance to find out if the job is one they would want. Whatever you think you are accomplishing is coming at the cost of filtering out candidates who are not desperate for your job. The better the candidate, the more likely they feel they are better off looking for a job with an organization that is not going to waste their time. That means these early tests often tend to filter out more good candidates than bad. The test is having the opposite effect of what is intended!
11. For most positions, do not send candidates tests or projects that take more than 30 minutes to complete unless you are paying them for the time. Again, it is going to filter out too many good candidates. I will save a discussion for the value of such tests for another time.

Preparing

Now that the interview is scheduled, you need to prepare to meet the candidate.

1. Read the job description again. Just like when reviewing resumes, make sure you are interviewing for the actual job requirements and not mixing it up.
2. Read the resume at least three times. When I see the invite for the interview, I read it through once and then read it from the bottom to the top to see if that helps me see anything in a different light. Then I read it about 5 minutes before the interview takes place.
3. Have your questions ready. Unstructured interviews are not effective. That said, don’t go in planning to ask one question after another. I try to structure my questions so that they will prompt dialog. I try to create a flow in my questions so that a candidate’s answer to one is likely to lead into the next. When a candidate really knows the field, they will often cover part of two or three questions with one answer.
4. Are you a psychologist? If you are not, leave the psychology questions for someone else. Be alert for signs of a combative personality or someone who is not going to work well with others, but do not take it to a level you are not qualified to assess.
5. While we’re at it: “Culture fit” is nonsense. It is a cloak for exploitative workplaces along with racism, ageism, sexism, genderism, ethnocentrism, and any other form of otherism you can come up with. The only culture we need is this:
   1. Show up to work.
   2. Do good work that provides value.
   3. Be transparent.
   4. Do not be a jerk.
   5. Be polite. Be respectful. Do not be bashful.
   6. Work well with others.
   7. Practice self-care in all its forms. Help others practice their own self-care.
6. Know your company.
7. Know the law and the questions you cannot ask. I’m dedicating a section to this…

Know the law and the questions you cannot ask

I live in the USA and manage a team that is spread across multiple states. So, I write in that context. The US has a complex mishmash of overlapping laws between Federal, State, and even Municipal levels of government. I hear other countries are not quite so confusing, but it still takes a herculean effort to understand their various laws. In the end, questions about the following topics can be illegal depending on where you or the candidate live and probably have little to do with the job anyway, so do not talk about them. Be careful even making small talk about life outside of work because you can end up sounding like you are fishing for information you should not have.

1. Family - marital status, number of kids, pregnancy or plans for pregnancy are all off the table.
2. Religion - I am a church going Christian and confidently say that religion does not matter to the workplace for most organizations. There may be scheduling conflicts for some organizations. If this is you, state the requirements of the job rather than ask them what their religious beliefs are. Federal law does require some level of religious accommodation, so work with your HR team and legal team to understand how to navigate this if it is likely to become an issue.
3. Race/Ethnicity - Out of all the things that do not matter when it comes to being able to do the job, the candidate’s race or ethnicity matters the least (along with the next two). People are people so why should it be that we get along so awfully?¹
4. Sex, gender, sexual orientation - Again, church going Christian here: Respect and courtesy are not optional.
5. Birthplace/Country of Origin/Citizenship - Leave it to HR. Even for HR, before an offer is extended, leave it at “are you legally allowed to work in the US” and that is it. The only thing I know of that may come up is visa sponsorship. Again, let HR lead that conversation.
6. Disability/Medical Conditions - Unless you are in HR and know the right time to discuss these, then leave it to HR. The right time is after the interview process. If the candidate needs accommodation but has the actual skills needed for the job, figure it out. Is it really that hard to make sure someone gets assigned a cube they can get a wheelchair in and out of?².
7. Age - As a young manager, I was blessed to have two people significantly older than myself reporting to me. One was literally my father’s age. I learned more about leadership from them than almost anyone else over my career and both were a calming presence on chaotic teams.
8. Status as a Military Veteran or membership in Reserves or National Guard - Leave this to HR. Even then, the only questions to ask here are for Reservists and Guard members and that is limited to “which weekends and which two weeks do you typically need.” We need a military and the Guard is a key component of natural disaster response, so only ask with an eye towards figuring out the logistics instead of vetting the candidate. While I am on the soapbox - the same goes for people who volunteer especially in emergency services. Give them the time because that is your own insurance.³
9. Salary History - more and more jurisdictions are making this an illegal question. This is worth a post by itself, so I will leave it for another time.

Few of these questions have anything to do with how well the candidate could do the job. Stick to the job and not to their personal life. As a rule, I focus the conversation on the candidate’s professional experience and do not ask anything about them personally. I work with people who do great work while having hobbies that are off the beaten path to say the least. Those hobbies do not come into the office, so why do I care?

The questions you should not answer and be prepared to not answer them

1. Anything about Salary - You will need to work with the candidate after they are hired. If negotiations get thorny, you do not want that baggage in your working relationship.
2. Anything about Benefits - You only know how benefits apply to your situation and probably have not thought about the variety of situations that come up. Stay out of the discussion lest you lead the candidate astray.

Leave both of those for the recruiter to manage. Some candidates may press, but firmly say “I would probably share something slightly wrong, so best to stick to talking to HR” and leave it at that.

Conclusion

Unlike most of my posts, this one is all bullet points because it felt like the right format. Over the next couple of posts, I will dive in further to the interview. I am not sure of the order yet, but do know I will look at the content of the interview itself and dive in a little deeper into how I like to structure for various levels of seniority.

These are all “working in public”. I expect to come back and polish all of these hiring related posts once they are all done to make them a little more cohesive and cleaner.