DEV Community: Sören Blom

Stress in Tech Interviews // a recent NCSU research paper

Sören Blom — Mon, 20 Jul 2020 16:01:19 +0000

The North Carolina State University (NCSU) published their research on stress in tech interviews. You should not be surprised: it's not looking so good (Press Release).

Their main finding is that the typical on-site, realtime whiteboard coding challenges cause so much stress that they really test more how well you can perform in front of others under pressure and less about how good your command of the actual topic is.

Luckily, the authors give some suggestions ("guidances") on how to improve the tech interview process in the Discussion section [My personal elaboration under the quoted headlines]:

"Guidance I - Use retrospective think-aloud for accessing explanation"

Let people work on a solution and a way to present it by themselves, unobserved. Then le them explain their thinking to the interviewer as a second step.

Of course, "live" brainstormings / discussions are part of what a developer would do in a team, but the situation is not comparable. If you are an accepted team member and stand in front of a whiteboard you already psychologically belong and you are aware of the problem.

"Guidance II - Evaluate the kinds of stress necessary for position"

Ideally, the interview is evaluating a candidate on things relevant for a job. Some type of stress might be part of the job, other kinds not. "Performing" (as on a stage) to solve code problems is usually not a job requirement. Even an important technical presentation is usually prepared and rehearsed.

I could imagine that if you hire for a "consultant" developer that often has to function in unknown situations in front of strangers, maybe this style of interviews is more appropriate.

"Guidance III - Provide accessible alternatives"

Several suggestions by the authors to overall reduce stress in the process:

A "warmup interview" - an opportunity to settle-in and learn about the format of the real interview, allowing to ask questions.
Allow for a "free reset". Basically, a second chance (different problem) in case the candidate just freezes on the
first one - I would imagine just knowing that there is such an option will calm down candidates, even if they never make use of it.
Give "Partial program sketches" - Instead of starting from a literally blank whiteboard / paper, give some part of the solution and ask them to fill in the rest. Should work for architecture sketches as well.
Provide "familiar affordances". Allow the candidates to use paper or a laptop if that works better for them.

"Guidance IV - Consider impacts on talent and diversity"

Missing out on candidates that are well able to solve the problem but not handle the stress, is the obvious problem causing the wrong kind of stress in interviews.

Furthermore, the authors point to research that shows women are more affected by performance and test anxiety and thus might be at a disadvantage regardless of their actual qualification for the position.

Other groups might be disadvantaged as they might be lacking access / resources to prepare for the stress of a typical whiteboard interview, whereas some candidates can prepare extensively.

What I really like about this paper is how it combines proper research with applicable suggestions. I still want to interview people on technical topics, but I am now way more aware on how my design of the process might lead to distorted results and unnecessary suffering on the candidate's side. It is also good to see that there seems to be a growing body of research on (tech) interviewing.

I definitely recommend to read the original paper, as they authors argue way more nuanced and provide interesting references for all their points:

Behroozi, Mahnaz, Shivani Shirolkar, Titus Barik, and Chris Parnin. 2020. “Does Stress Impact Technical Interview Performance?” In ACM ESEC/FSE ’20.

Scrum and "old knowledge"

Sören Blom — Wed, 15 Jul 2020 21:59:57 +0000

Came across this article, which is one of a serious and it triggered more reflection than initially expected:

5 controversial topics that were removed from Scrum | by Willem-Jan Ageling | Serious Scrum | Medium

Willem-Jan Ageling ・ Oct 29, 2019 ・ 4 min read
Medium

Together with the accompanying

6 pivotal things that weren’t Scrum canon but got introduced later | by Willem-Jan Ageling | Serious Scrum | Medium

Willem-Jan Ageling ・ Oct 1, 2019 ・ 5 min read
Medium

The first time I used Scrum in a project was early 2008; twelve years ago. I read the usual books, got certified (Scrum Master and Product Owner) and have seen Scrum adopted well and not so well in may teams. You could say I thought I had this topic "in the pocket".

In recent years, the "Agile Industrial Complex" has dampened my earlier enthusiasm. The never-ending methods with certification schemes popping up, having scrum master and agile "coaches" in companies, whose only exposure with product and software development was a two day training course, etc. Apparently, though, Scrum hasn't fully fallen to the dark side and it keeps evolving, as shown in the linked articles via the changes of the Scrum Guides (also see this article).

I was aware of some changes in the guide. For example, not to use the term grooming anymore or switching out committing to a sprint backlog vs considering it a forecast. One thing that was new to me was the change of the Daily Scrum standard questions. They are now using the sprint goal as the reference point of reporting: What did I do yesterday that helped the Development Team meet the Sprint Goal.

While I am really pleased to learn about many these changes, I also was a little shocked to realise that they had all happened without my taking notice. Contrast this with, for example, changes in Java. A language I haven't written code in in forever and have no real interest in, intellectually. I still managed to keep a basic awareness about changes such as the Streams API or the language switching to a half-year release cycle.

I don't have a good explanation for this, other than it feels like I had Scrum "taken care of", knowledge was archived and good enough for reference in the daily work. Maybe I am also falling prey to the well-known problem of thinking agile methods are "easy" as they only have "a few rules" and then being very careless in sticking to the important basics. It seems, though, that I am not the only one being outdated on Scrum knowledge. Teams that I work and have worked with are happily grooming their stories, don't define a sprint goal and treat their sprint backlogs as binding contracts and not as forecasts.

In any case will I now keep an eye out for other topics that give me this "safely and snuggly archived" feeling. Time to shake up some presumed "certainties".

How to be less clever (and more creative instead)

Sören Blom — Fri, 03 Jan 2020 00:39:38 +0000

The funny seminar

Have you ever been in a classroom-like setting, on a Friday morning, with 10 random people taking turns reading "funny" (as in not funny) names of sport clubs to each other? Such as Dunkin' Donut for a basketball group (get it?)

Neither have I, until the middle of November. I was participating in a "comedy writing" class, at Berlin's Volkshochschule Mitte. Three days, Friday to Sunday. The teacher a full-time comedy writer for 20 years, not famous - but well in business.

I will spare you my creations, but what I have to share with you is my experience of being led to three days of simple enough creative exercises. And it was all about quantity. And about limiting time. And about not trying to be clever.

“Give me 9 funny names for first-name last-name combinations”
“Write down 30 adjectives”
“Think of 5 situations and inappropriate reactions in those situations”
...

Of course much of what we produced was not particularly funny, some seemed forced. Yet, every time, there were a few results that had us seriously laughing. From varying people, not just the funny ones.

What I found fascinating (for the purposes of this text) beyond learning insights into what is funny and how to manufacture that was to experience a creative process more as a physical challenge than some lofty thought process. Much as a sport coach might yell: “Give me ten rounds around the court”, here I was filling the paper with 10 ideas for a punch line.

The brain is an association muscle. Start writing down a few ideas and just looking at them will spark some variations, add-ons, forks.

And I hear you saying: "Sure, that is what they tell us in any workshop where somebody introduced brainstorming". Which, of course, is true. But I can say for myself that I have still been too restrained in getting into this “doing laps” mode of creativity. Overthinking_ is a thing.

Playing Tic-Tac-Toe

The second occasion, with a similar realization, was preparing a coding kata at work called "Test-driven development as if you meant it". Keith Braithwaite, the creator of this Kata, has toured many software conferences and there are two blog posts [1] [2] by Gojko Adzic, where he reflects on the the intent behind the Kata and how he ran one himself.

The Kata has very specific, simple requirements for implementing a simple game (usually Tic Tac Toe). You are supposed to just work on the requirements and nothing else in the order provided and following strict TDD rules (write functional code in test first, only extract into test file first, ...). An example for a first requirement for Tic Tac Toe would be a game is over when all fields are taken.

At the risk of spoiling the "a-ha" moment when you go through the Kata yourself, the main point is this: You must try hard to not bring your pre-existing assumptions to the task. When you begin with the Kata, there is no talk of a board or a 3x3 grid in any of the requirements. Yet, that is where many people focus their attention on. As the facilitator, it was my job to tell the participants to delete such code. The point of this exercise is of course to let the implementation being driven by the test(s) at hand and not by your own brain thinking too far ahead. Which is at the heart of "test-driven design".

There is much to learn about TDD in such a Kata. But besides that, I felt it an instance of creativity as an exercise, much as in the comedy writing situation.

Follow a simple system without overthinking. Get to writing and refine from there.

Having implemented the Kata myself in preparation for the work session, I can say working in the spirit of TDD as if you meant it leads reliably to programming flow.

Watching too much (Clojure) TV

My last observation of the same pattern came when I was watching a talk from this year’s Clojure Conj, the main conference on Clojure: Rapid Prototyping for Software Development by Sara Kimmich (video) (conference entry).

Rapid Prototyping is nothing new in software, of course. Sara makes the point that the typical agile approach these days does not iterate fast enough:

[F]or may problems, products and solution architecting the best way is to fail fast. Faster than Agile.

With her ideas you can iterate on an idea several times a day. No need to wait for two weeks (or whatever your typical sprint length is, if you are doing Scrum). Iterating often in very small increments resonates well with TDD. Creating many (similar) ideas reminds me of the comedy writing approach.

Sara makes one other important point (that also applies to the TDD): Creating something and testing it allows us to make observations. This is very different from discussing ideas before implementation where everything is a conjecture. Showing a real-life user even just a paper prototype will generate more valid feedback than having a long exchange of opinions.

Conclusion

I am sure the things I have talked about in this post have been discussed many times in different areas. Actually, I am pretty sure that a lot of advise about any type of (creative / academic / journalistic) writing promotes similar ideas. What was remarkable for me was to see such a pattern pop up in three unrelated parts of my life over a short period of time. This really got my attention and flipped some switches in my brain.

So, no more deep thoughts?

Obviously, that would be a silly notion. This post itself is a reflection about some observations that I made and took a bit for me to be happy with. My personal challenge is trying to be clever and witty in situations.

In closing, the best answer I can give is to refer to the (double) diamond introduced by the Design Council. Design consists of both divergent and convergent phases. The former producing ideas, exploring options in the design space and the latter consolidating those ideas and filtering out those that should be looked at further. The trick might be to understand when to do what and to have the discipline to put the mind in the right setup for each.