DEV Community: Mark Walsh

Overwhelmed? Try this! - Part 4 - Good Meeting Hygiene

Mark Walsh — Tue, 26 Sep 2023 21:32:45 +0000

In this series, I describe the various methodologies I employ to combat burnout, enhance focus, and ultimately improve well-being during the workday. Most of these strategies are job-agnostic, so non-technical individuals are encouraged to read on!

What?

Meetings lacking documented aims, time limits, or action items can be disastrous for both you and your company. Over my nearly 14-year career, I estimate that approximately 70-80% of the meetings I've attended have been a waste of time for some, if not all, participants.

Here's the average cost, in dollars, for a 5-person team with a combined salary of 100k conducting a 1-hour meeting:

Feel free to calculate it for your own team

Why?

Voice or face-to-face meetings are often the default method for conveying or discussing information, whether rightly or wrongly. Unfortunately, they are frequently unproductive, unfocused, and, ultimately, a waste of time and money.

To save time and money for yourself and your company, consider the following:

Question the necessity of the meeting - Could the information be conveyed via email or instant message? Often, the answer is yes. It should be acceptable to decline meetings if information can be easily provided or obtained without a meeting. Context-switching is disruptive for all roles and costs a significant amount of money.
Ensure the meeting has a documented or obvious aim - Agenda-less meetings invite distractions and tangents. An aim keeps the discussion clear, on track, and all participants engaged. Meetings like 1-to-1s are somewhat exempt from this rule.
Set a fixed time for the meeting - Meetings should always be timeboxed appropriately to keep attendees engaged and allow time for other calendar items. No one should entertain meetings that overrun, and people should feel empowered to leave meetings.
Capture actionable outputs - Meetings should produce actionable results. If you don't keep track of these, why have a meeting in the first place?
Prepare for the meeting - The hours spent in meetings where someone adjusts fields on Jira or begins a lengthy setup for an unprepared demo, is criminal. Meeting organizers should always prepare beforehand.

If you're a person of influence witnessing these issues in your business, there are a couple of things you can do to promote better meeting hygiene:

Empower people to say "No" - Individuals should feel comfortable pushing back on poorly constructed meeting requests. This cultural shift will naturally lead to better meeting practices.
Practice what you preach - Consistency is key; leaders should model the behavior they advocate.
Aim small, miss small - Begin by encouraging the addition of agendas to meetings. Even this simple step guarantees some return on investment.

Overwhelmed? Try this! - Part 3 - Pomodoro

Mark Walsh — Wed, 06 Sep 2023 22:16:33 +0000

In this series, I describe all of the different methodologies I employ and encourage others to try to feel less burnt out, more focused and ultimately feel better during their working day. Most of these are also job-agnostic so non-technical people - feel free to read on!

What?

The Pomodoro Technique is a way of micromanaging your time for focused tasks. If you're employed in any field which requires dedicated concentration then you can employ this technique. It works especially well if you suffer from any condition which prevents you from concentrating... massively exaggerated nod to ADHD

Follow these basic steps for a "Pomodoro":

Pick a task you need to complete - remembering One-task-at-a-time
Set a timer - For at least 15 minutes but it can be anything up to 30 minutes - it's probably best to stick to 5 minute increments
Work on your task and only this task during this time (more on this later)
Once the timer goes off - stop working for 5 minutes
Rinse and repeat steps 1 to 4. Every 4 Pomodoros take a longer break, perhaps double or triple your 5 minute break.

I personally like to perform 25 minute Pomodoro and I use a software based Pomodoro timer located here for Windows. Here's one for MacOS and one for Linux. Or you can buy a physical timer or use a timer on your phone.

In order to achieve peak concentration, I also make sure I mute all of my OS, IM and phone notifications during this time. Not distracting yourself from your timed task is absolutely key to ensuring the success of this technique.

...BUT! as important as achieving your peak concentration during the task is the cooldown period. Make a coffee, go outside for 5 minutes, check the stock market (if that relaxes you!?). The important thing is that you honour the 5 minute cooldown by giving yourself a dopamine hit which is absolutely not work related.

Why?

This technique is so effective because:

You're totally focused on a single task at a time with no context switching
There's a low-bar of entry - it's a really easy technique to learn and adhere to
Time-blocking tasks into chunks actually makes difficult or long tasks easier to process and digest
You can avoid burnout
You can avoid decision fatigue
It's easier to forecast and plan your work when it's compartmentalised
You could find it easier to get started on a task

For software engineers I've found it's also beneficial because:

I've found it acts like a Rubber Duck Debugging-esque technique in the way that problems are often much more obvious post-Pomodoro
It will improve your estimates if operate in an Agile manner because you can class user stories or tasks by how many estimated Pomodoros they will take

Overwhelmed? Try this! - Part 2 - One-task-at-a-time

Mark Walsh — Tue, 18 Jul 2023 21:27:52 +0000

In this series, I describe all of the different methodologies I employ and encourage others to try to feel less burnt out, more focused and ultimately feel better during their working day. Most of these are also job-agnostic so non-technical people - feel free to read on!

What?

The phrase "I am a natural multitasker" or "I just juggle stuff all day" goes straight through me. If you're a person who says this, I can say with relative certainty that you may do some tasks concurrently, but you do none of them well. It sounds insane for me, a serial single tasker to say this now but you can only do one thing at a time.

Why?

As you climb up the seniority ladder you will ultimately be leaned on more for your expertise, guidance and if you're technical, debugging. More distractions, more people, more demand = evitable context switching. You open Slack/Teams or whatever IM client in the morning and you're presented with a Christmas tree of chatter; it happens (*there's stuff as an organisation you can do to mitigate this - more on that later...) - or if you're still working in the 90s, you're inbox is full of "demanding" emails.

So, why is it bad to rifle through all of these as fast as possible, context-switching as much as possible because the Christmas tree lights need to be individually turned off?

Well here's why:

You will miss important contextual details on your road to mark things as read
You will forget about that "5 minute thing" you said you'd do "soon"
You will overcommit to stuff you don't have time for

So what can you do?:

Spend X amount of time (usually minutes prioritising) - For this I have a personal task backlog which is constructed and reprioritised throughout the day. Those familiar with Agile should be familiar with a backlog and also familiar that personal backlog items belong nowhere near the Product backlog. For those not familiar, in simple terms, it's a list in which the order of importance can change dependant on demands.
Once prioritised - I determine the steps to completion for the task. A task is not always immediately and solely achievable; sometimes it involves collecting people or third parties and arranging dedicated sessions.
I "complete" that task and that task ONLY - that task may be completed by scheduling a meeting, emailing a third party or dealing with an issue immediately and solely by me. Either way; a task completion is a path forward, or a direct resolution.
I move onto my next task, in priority order.

I have scheduled appointments set with myself for personal backlog repriorisation throughout the day.

Doing the above means I suffer less from context-switching, over-promising and I make sure that my focus is 100% on the task I am working on.

Overwhelmed? Try this! - Part 1 - Calendar Segmentation

Mark Walsh — Wed, 12 Jul 2023 22:15:13 +0000

In this series, I describe all of the different methodologies I employ and encourage others to try to feel less burnt out, more focused and ultimately feel better during their working day. Most of these are also job-agnostic so non-technical people - feel free to read on!

What?

There's a relatively famous film called About a Boy which is basically about quite a sad man who aside from living off a relative's royalties divides his time into units; 1 unit for a haircut, 3 units for going to see a film etc. This is quite rightly portrayed as a negative in real life but when you employ this tactic in work; you may find it shockingly effective.

The idea is pretty simple and applicable to any job in which you have access to a hard or soft copy of a calendar. You assign appointments in your calendar to tasks in which you need to perform during your day; during that appointment, you only perform that task.

To quantify this with something visual; here's a relatively normal representation of what my daily calendar looks like:

In order throughout the day:

I have an immovable/uninterruptable (and therefore purple) administration appointment of 15 minutes whilst I read emails and look at my DMs (Bookending)
I have a stand up every day at 09:15
I will routinely have ad-hoc meetings placed into my calendar, this is totally normal at my level
I have an immovable/uninterruptable work item appointment to solely focus on a single work item
I have lunch as an uninterruptable (and out of office therefore grey) appointment. The time mostly never changes.
Again another immovable/uninterruptable work item appointment
Another ad-hoc meeting
I have an immovable/uninterruptable (and therefore purple) administration appointment again to bookend my day. I usually use this time to create appointments for the coming days/weeks calendars (Bookending)

The most interesting and pertinent calendar entries are 4. and 6. This is the time were I typically set a do not disturb and will become pretty strict about not being disturbed.

Why?

If you're relatively junior, especially in a technical role, then I am afraid to say that one of the negatives of becoming more senior is you will lose more and more personal focus time (by virtue of giving it to other people). It's inescapable; your calendar will run riot; you will be pulled into things with little to no notice and/or context.

The downsides of being more senior may be inescapable but you can start employing this tactic now to protect yourself; I have for the last few years and I've observed the following benefits:

If you block out your calendar more likely than not people will (and really should!) respect it. In general, people do use the availability features of calendar applications. Meaning - you get stuff done in a focused manner.
It acts as self-documentation for your day. Are you in a stand-up daily? Cool! - you can just read yesterday's calendar to tell the team what you did. If for some zany reason you work for somewhere that wants you to account for every moment of your day - Cool! you have everything in your calendar
Setting clear boundaries within your day minimizes context switching
Setting boundaries and routines is *physiologically beneficial * to most people. I have particularly found great comfort in bookending my day.

All About Automated Tests - Part 2 - Benefits

Mark Walsh — Wed, 01 Dec 2021 00:02:17 +0000

TL;WR

Welcome to part 2 of the All About Automated Tests series. This one is going to be a little more pleasant compared to Part 1 as I try to demonstrate some of the obvious and the not-so-obvious benefits of adding value to a product via automated tests.

Benefit 1 - Modularisation

In my opinion, the greatest benefit, mostly because it actually generates other benefits is the modularisation of code as a result of introducing automated tests particularly unit testing. Separating your code to be more modular might be a by-product but it's fantastic nonetheless.

Typically, in no/low test codebases you tend to see a lot of code which looks like this:

 public class OrderRequestService
        {
            private readonly IDatabaseContext _databaseContext;

            public OrderService(IDatabaseContext databaseContext)
            {
                _databaseContext = databaseContext;
            }

            public Order CreateOrder(CreateOrderRequest createOrderRequest)
            {
                var product = _databaseContext.Product.SingleOrDefaultAsync(x => x.CompanyId == createOrderRequest.ProductId);

                if (product == null)
                {
                    throw new ProductNotFoundException(createOrderRequest.ProductId);
                }

                if (product.StockCount < 1)
                {
                    throw new ProductNotInStockException(createOrderRequest.ProductId);
                }

                var supplier = _databaseContext.Supplier.Where(x => x.ProductId == createOrderRequest.ProductId);

                var supplierWithShortestDeliveryTime = supplier.Where(x => x.CanBeSuppliedWithinSevenDays(DateTime.UtcNow));

                if (!supplierWithShortestDeliveryTime.IsActiveSupplier)
                {
                    throw new SupplierNotActiveException(supplierWithShortestDeliveryTime.Id);
                }

                // And then about 20 other procedural statements

                var order = new Order()
                {
                    Quantity = createOrderRequest.Quantity,
                    ProductId = createOrderRequest.ProductId
                };

                return order;
            }
        }

I know this example is written in C# (therefore OOP) but this almost completely language-agnostic. This seems harmless enough but the more and more cognitive complexity you add to this the harder it will become to maintain and change existing functionality. It becomes even worse when you retrospectively need to add tests - Your tests will end up being a bloated mess of setup code.

The sensible thing to do in this example in order to make sure your tests are still readable, maintainable and quick to execute is to separate the concerns out. The obtaining of a product could be refactored out into a ProductAvailabilityService class and the same with the interactions involving suppliers - a SupplierSelectionService class. This would then enable testing in isolation and perhaps even more importantly - giving you units of reusable code which would be immediately available to other parts of the application.

The other cardinal sin within this example is the reliance on non-deterministic data (DateTime.UtcNow). This is so ridiculously common within the industry and the cause of so many bugs in production specifically when you start to deploy into different time zones. Refactoring the reliance on environmental variables not only makes you more modular but allows for the specific targeted testing of multiple cases.

Although these are basic programming principles (SOLID, in this instance) which you should be doing with or without tests, I often find the adherence to these principles often comes as a by-product of writing code which is easily testable - it feels almost automatic - it's like you get better design by default, for free.

Benefit 2 - Context Switching Damage Management

This never, ever gets mentioned and is closely related to Benefit 1 but it makes complete sense if you think about it. If your code is more modular and/or you have a test suite safety mat, in general, you shouldn't suffer too much from the damage of context switching (I'm not encouraging context switching at all but it's a sad reality).

If you're making changes to an untested 400 line mega-function with tons and tons of return statements (I am not advocating this either) and you get that virtual tap-on-the-shoulder or even worse, a screenshot with absolutely no context on Slack/Teams, what is the likelihood that you're going to make a mistake in that function? Or forget something? I'd say it's definitely quite high and I've seen it happen countless times. Is this going to be the same in a small, well tested function or component? Probably not ...meaning when you do resume work you will be able to enter "the zone" quicker and not only that, you'll have the cosy blanket of a failing test if you have made a mistake.

Benefit 3 - Intent Is Clear

Typically, well written tests accurately describe the intent of code e.g. (Typical unit test naming syntax)

ProcessOrder_WhenTheProductIsInStock_ThenProductIsOrderIsSubmitted

and

ProcessOrder_ProductIsOutOfStock_ThrowsProductOutOfStockExceptionIsThrown

or even (Gherkin-style):

Given: There is a product in stock
When: I order a product
And the product is in stock
Then: An order is submitted

You can clearly determine what is being tested in both of these scenarios, there's no real room for ambiguity. The behaviour is very well defined so in the result of one of these tests failing, the maintainer will know that they've broken something. This for me, is the best form of documentation and a thousand times better than using auto-generated code comments or writing needless comments

// Opens the filestream
var fileStream = new FileStream("some_file.txt", FileMode.Open);

You're doing God's work, son.

There is a caveat to this benefit of course - it all depends on your quality of tests and specifically the naming of the test. The intent of the test should be clear - not forgetting you're testing outcomes not implementation details.

Benefit 4 - Bug/Regression Reduction

It's the most obvious benefit but you will have far fewer bugs as a result of maintaining a mature test suite. Even taking the smallest type of a test you can write (a unit test) the highest real percentage of coverage I've achieved previously was about 92-94% of an entire codebase, purely on unit tests. This is anecdotal but when I joined said company the coverage was 0% with an almost daily meeting to discuss bugs, so you can probably say there were on average 5-10 bugs per week. Once around 80% coverage was achieved, that dropped to around 0-1 a month. You as I will quickly discover that the biggest protection when modifying functionality were those tests running either locally or on build - when they were red, I knew I'd introduced a regression bug.

Testing Pyramid

For full disclosure, this did go hand in hand with many process changes including the introduction of a Scrum-like methodology, proper pull request review procedures and manual testing etc but from first hand experience, in the many instances in which we modified functionality in some way, we had a failing test as a result.

One very recent example of bug prevention I've experienced occurred when I was implementing a password complexity function as required as result of a penetration test. Unfortunately like many specifications there was a missing requirement which had to be retrospectively added. There was quite a massive regex which checked various conditions of the specified password and I had to add a requirement for sequential characters. I made my changes to the regex - "Well that was easy to add" I said and a build was started as a result of my PR and lo and behold I'd broken a test by making the regex more permissible, and thus breaking the password requirements as per the penetration test. This is a small example but it's quite applicable to every single test type on the aforementioned test pyramid.

Benefit 5 - Refactoring Can Be Made Much Easier

If you're not refactoring code either as part of a change or addressing tech debt then you'll quickly start to experience both product fragility (a small change in one area breaks multiple other areas of the application) or increased development costs
by having to address multiple areas for one change (...well, the ones you remember...for the ones you don't it's yet another bug).

In terms of refactoring with testing this is a big "can" because if you are sensible about how you write your tests (e.g. you test outcomes not implementations) then refactoring the internals of functions/classes/services should be very easy to do. I learned a very valuable lesson recently in which I kept having to go back whenever I refactored a class to change the unit tests. This is a sign that your unit tests are too fragile and also a sign that the class is too complex. Breaking up the class in this instance and testing outcomes not implementations will make refactoring a breeze. If you find yourself constantly having to change tests as the result of refactoring (NOT changing requirements) then you've probably identified a code smell.

I've often found that the likelihood that a test needs to be changed actually lowers the more you climb the pyramid (less changes for acceptance/E2E tests and most changes for unit tests).

Benefit 6 - Execution Before Deployment

In a mature development environment ideally you should use automated tests as a quality gate for shipping software. Ideally this should run on a per pull request basis whenever any change is going to be introduced into the codebase. It's not really relevant to this article but perhaps you have a build and deploy pipeline which looks similar to this:

Test locally
Test on build server on pull request
Test on build server when merged into the Development environment
Test on build server when merged into the UAT environment
Test on build server when merged into the Pre-Prod environment
Manual tests by QAs
Deployed to production
Customer reports bug

Within the above process there are 5 separate stages from which code is being executed via tests before it reaches production. This offers quite a bit of protection from the introduction of bugs into the codebase, 4 of these being machine-agnostic builds.

The other obvious benefit is how quickly you can ascertain whether your change has broken anything. For unit tests that will be Stage 1 which is really early in the pipeline. It's also not out of the question to be able to see failing integration or E2E tests at this stage dependant on your system but if not they will be caught in Stage 2, 3 or 4.

Consider how this would play out in the same pipeline above without any automated testing:

Manual functional volatile test locally (potentially)
Build on pull request
Build when merged into the Development environment
Build when merged into the UAT environment
Build when merged into the Pre-Prod environment
Manual tests by QAs (potentially missing the bug)
Deployed to production
Customer reports bug

The best possible outcome is at Stage 1, the author of the change catches a bug because they just happened to have functionally tested it locally (Noting that this is a volatile test, I doubt this will be functionally tested again other than at the time of modification).

The next possible stage is Stage 6. Utilising a QA to test something an automated test could have highlighted is a complete waste of their time and then your time as a developer, if you have to then go and fix it.

The worst stage is Stage 8, using your customers as a replacement for automated tests is one of the worst things you can do and will result in product alienation and churn.

Summary

These are just some of the benefits I've experienced first hand when implementing automated tests of any kind into a SDLC. I am always keen to add arrow's to my unit testing quiver so if there are any you can think of please do let me know.

All About Automated Tests - Part 1 - Excuses

Mark Walsh — Thu, 29 Jul 2021 11:00:45 +0000

TL;WR

The year is 2021, and yet somehow, there is still an ungodly amount of people not(!) writing tests for production code and even worse, trying to excuse themselves of it. This article will attempt to dispel some common excuses I've heard in the wild. I am labelling these as excuses because I believe automated tests to be a hard requirement for production grade code.

Excuse 1 - 🗣️ "Tests will make X story/feature/defect longer to complete"

Probably in terms of implementation-to-deployment time this statement is probably true...however writing software isn't like making burger patties, the product lifecycle doesn't finish when it's consumed - software is never "complete". For all code, you have a debt as soon as that story/feature/defect is implemented - if you have untested production code you not only have to maintain that debt but also incur the debt of protecting that code from ever breaking its own or other related functionality.

For arguments sake, if you take a simple scenario of an estimated dispatch date endpoint which takes a product identifier and generates an estimated dispatch date. Let's also pretend for arguments sake that there's quite a bit of logic around several remote data sources, perhaps you query a distribution API, supplier APIs and then you perform some complex date related calculations. Code like this will commonly require changes, perhaps some business logic changes or perhaps there's other suppliers to add later on etc.

The cumulative effort for the maintenance e.g. either bug fixes or changes to business logic will take you longer than if you just originally wrote tests - it will also take you longer to make future changes. Obviously there are also the added benefits of the tests accurately describing the intent of the code and preventing you from breaking related functionality but there's a whole other article's worth of testing benefits.

Excuse 2 - 🗣️ "It's only a small change, we don't need a test for this"

If you are making changes to production code which will be executed, you should absolutely have automated tests for this and especially if you making a Super Small Fix™ (and we all know how that goes typically). A Super Small Fix™ will surely require a Super Small Test™ therefore there shouldn't be a problem, should it? Ironically, in systems with low amounts of or no tests, you typically find fixes being deployed more regularly because of the lack of tests which leads to yet more dangerous Super Small Fix™'s and so it snowballs and snowballs until you find yourself in a position of dealing with ever-growing amounts of bugs (a typical sign of this is having meetings specifically about bugs) instead of delivering value to your stakeholders.

I've seen countless times, in systems with low or no test, fixes be deployed, then another fix to patch over a regression bug and then another fix to patch something else which has broken because of the previous fix. The very least you can do is construct a test to signal the intent of the change and protect it from regression.

Excuse 3 - 🗣️ "We only need to test the critical areas of the system"

I do think, if you are adding automated tests to an existing production system, the critical areas should be
addressed first. However, a customers interaction with your software doesn't just fall under the remit of what you consider critical. I am of the opinion that every executed piece of code which modifies state is a candidate for at least some sort of test, even internal tools. Basically - anything you are executing which could impact your customer or stakeholders, should be tested.

When it comes to introducing tests to untested codebases, I tend to adopt a touch-and-test approach; you add tests to that which you touch and only that. I have previously made the mistake of spending a lot of time writing tests for code which I just ended up replacing wholesale with fully tested code. In order to remain pragmatic and productive you have to assume, unless told otherwise, that the current code is correct and work in your tests around the change.

Excuse 4 - 🗣️ "It's not our job, we have testers/QA people"

Typically this is uttered by what I like to define as "coaster developers" (which really deserves its own article as well). It's the entire responsibility of the development team, which includes testers and product to ensure the correctness of the application. Everyone should pull their weight; product in terms of identifying criteria and backlog refinement, testers for their manual/automated tests and developers for writing tests for their own code.

It's a sad reality that there are many developers with slanty-responsibility-shoulders within the industry who will perform very acrobatic gymnastics in order to abstain from any further responsibilities bar "coding". This self pigeon-holing is what sets apart mediocre developers from truly great developers. Bashing out code as if you are boxing orders for Amazon will only get you so far in your career and only enhance the product to a point. Learn to appreciate that you and your stakeholders all share a common goal.

Excuse 5 - 🗣️ "Frontend code doesn't need to be tested"

This is mostly related to Single Page Applications, if you've said this whilst writing or maintaining an SPA, congratulations, you've just created the worlds first SPA without any logic (and in this instance, you probably don't need a SPA). That being said, even if you've managed to create a SPA application without any logic you still have to test against visual regression bugs (Things like Percy can help with this)

If there's logic in place which is important to your customers and stakeholders (whether they know about it or not), it should be tested.

Excuse 6 - 🗣️ "That means we will have to write tests for everything we do! I can't be bothered"

This is a fallacy. I can think of four perfectly reasonable scenarios off the top of my head (and there are probably more) in which I don't think tests are required:

Non-production code e.g. Spikes/Research Stories/Proof of Concepts/Anything you will not deploy to production
Internal tools (which don't mutate state or you don't base business decisions off) - I am thinking of monitoring dashboards, any internally surfaced logs
In general writing code for language/framework specific functionality e.g. you wouldn't write a test to ensure that slice (JavaScript) actually splices or that a List<string> (C#) enumerates correctly
Dependencies which have their own tests - I wouldn't unit test a Nuget package I'd installed if it had it's own suite of tests providing proper coverage

Don't test things that don't add value to stakeholders.

Excuse 7 - 🗣️ "Customers don't care if we write tests or not, they just care about the product"

Customers would never usually say they care about whether you write tests, that bit is true and they should never be exposed to that information. They do care about the quality and stability of the product they are using - and without tests, every change you make is compromising that.

Summary

These are just a selection of the most common excuses I've heard from various people along my journey. There are many others I've heard along the way, some of them are too ridiculous to even note. Please note that I've specifically not mentioned the types of tests - this is intentional as to not provoke any discussions around the usefulness of unit, integration and acceptance tests.

The Madness Of Recruiting Permanent Engineers

Mark Walsh — Thu, 15 Jul 2021 13:40:07 +0000

Disclaimer: This article is only pertinent to permanent recruitment. If you have a multistage interview process for contractors I think you may be beyond help...

TL;WR

Modern recruitment is broken but unlike seemingly everyone else under the sun, I don't blame recruiters; who are mostly just responsible for sourcing and placing candidates. I blame companies themselves for many, many sins as listed below. Caution: This piece is opinionated...

"Just a one-hour pairing exercise" ❌

By far one of the biggest annoyances I have encountered whilst searching for a job was the insistence by companies to complete live pairing exercises...when they themselves don't even practice pair programming. Now don't get me wrong, if your company practices pairing, I get it - I really do, that's your modus operandi ergo you need to judge candidates on how they operate in that environment. However, that is not how most companies operate, so why would you interview a candidate in that manner?

Now it might just be me and my years of experience interviewing candidates, but recreating that scene from Swordfish during an interview tends to invoke a panicked response from a candidate.

Swordfish - An unrealistic scene (Cropped...if you know, you know)

Take it from me who has been on both sides of the fence - you're probably not getting a representative assessment of their skills by putting them on the spot.

Solution ✔️

Give candidates a choice between a take home test, pairing exercise or just trust their CV and have an adult conversation.

My preferred method when interviewing/being an interviewee was usually a 3 stage process:

Screening call - Establish appetite for role/Discuss role in detail
Handcrafted short take home test (yes, I mean very short) - Establish how a candidate approaches a problem under real world conditions. This usually has some pretty explicit requirements.
Final interview - To discuss why they approached the problem in the way they did and essentially review their code together

My reasons for this are pretty simple:

It mimics the real world - Candidates try things, Google stuff etc - I want them to approach a problem as they would day to day. The final stage also lets a candidate discuss their approach to the problem and allow for a natural, free-flowing conversation between both parties
It lessens the likelihood that a candidate has memorised a Project Euler solution or a particular algorithm (Yet to see how that skill is useful in the real world anyway...)
It shortens the amount of time dedicated to recruitment for me and other engineers - In almost every company I've ever worked for the engineering department is short staffed - Setting aside days to watch someone code is not a great time investment
A lot of lower quality candidates either can't complete the solution or don't read the instructions. I would go as far to say, a shocking amount

I've heard several arguments against this, so I will address these

"But they could just steal/get someone else to write it" - It becomes very, very obvious in the final stage when they cannot justify their design choices
"It takes too long!" - I said very short and I meant it (1-2 hours).

"Amazon/Facebook/Google do...we do too!" ❌

You're not Amazon/Facebook/Google. Now, I don't necessarily agree with the horrendous recruitment process undertaken by most FAANG companies but there's a reason they're market leaders - they attract the best talent because they usually have some of the best benefits, best co-workers, best remuneration and a lot of personal freedom within their roles.

It's highly unlikely that you're going to need to recruit candidates who need to be put through a 15 stage interview-a-thon including a "culture fit" interview (whatever that means) culminating in them being shot out of a cannon straight into the HR department.

End of interview human cannonball to HR - It's not for everyone

Solution ✔️

You should be much more interested in how they approach problems and whether they can write clean, maintainable code. Keep the interview process short with as few stages as possible which will keep both parties interested. I lost count of the amount of times I've heard about people getting bored and dropping out at stage 4 of a 7 stage process. We have a magical thing called "a probation period" - use it.

"Let's gather as many candidates as possible and select the best" ❌

Quite simply, you don't have time. The market is so unbelievably busy - companies are having to sell themselves to candidates which is leading to all sorts of fantastic benefits for us but unfortunately for companies, it means you have to act fast. I was offered 4 genuinely fantastic offers very recently within 10 days of initial contact. This is unprecedented in a time in which the word "unprecedented " is used too much.

I had a few companies take weeks to come back to even offer me an initial interview - For some it took months - How on earth are you hiring, well, anyone?

Earth - When a slow-moving company finally gets back to you

Solution ✔️

There's no time for you to compare candidates - if you spot a good engineer you should do everything within your remit to hire them before someone else does. The market is rigged against you.

"I know we're experiencing a pandemic but we need a face-to-face final interview" ❌

I don't even know what to say to companies who request this. Despite a successful recent vaccination drive, the UK (where I live) has recorded almost 130k deaths at the time of writing and we're currently in the midst of our third wave.

"Nice to infect you!"

Solution ✔️

Quite simply, don't do this. Be aware of the enviornment and conduct it via VC.

"Salary is dependant on experience" ❌

Translation - We're going to lowball you if we think we can get away with it. This has never sat right with me - not only does it result in you getting candidates who don't have enough or too much experience but you also introduce a completely needless stage of negotiation having wasted potentially hours of time on both sides.

What you look like when you lowball

Solution ✔️

It's obvious - advertise a salary or a salary band. Make sure the candidate is happy with either the maximum or minimum during first contact.

"Put legally required holiday allowances/tea and coffee/equipment/drinking water as a perk" ❌

Great! Thanks for what is completely expected in every job...I've ever had...since I was 16...including when I was a Kitchen Porter (aka young boy who cleans pans). You're really scraping if you're listing these things as perks.

"If I keep looking, maybe I can find some free oxygen to add to the advert"

Solution ✔️

Best to leave the obvious stuff off, especially the perks which are legally required. I know not every company is exactly flush with cash but there are other things you can offer engineers which are free - autonomy, freedom to work from home, brown bag sessions, dedicated personal R&D time.

"Comfy breakout area with PS5s, beer fridge and a massive TV" ❌

I've never met a single good or better engineer who cares about this. Not one. More to the point, I've never seen these areas used in any company I've ever worked for.

Engineers care about autonomy, process, well defined requirements and using the best tools for the job. I'd be much more inclined to interview for a company who, for instance, told me about the specs of my workstation on an advert or told me about their SDLC.

I was going to create speech bubbles for this but it's far too silly in it's own right

Solution ✔️

It boils down to this - Good engineers care about the quality of what they deliver which basically means, when you're in work...well, you're in work. By all means, keep your breakout area if you have one but have an awareness of the type of person you want to recruit...Hint: They're probably not going to care about zany token gestures.

"Our Work From Home policy is up in the air at the moment" ❌

Hearing this as a candidate is a red flag - it's typically a bait and switch e.g. they employ you and then all of a sudden a decision has been made and you're being asked to come in 3/4 days a week or you're being told there isn't an office (depending on your preference).

The office they advertised as "exciting and energic"

Solution ✔️

Coming to a decision on this shouldn't take weeks - you should just decide in black and white whether it is - or isn't - a policy, whichever side of the fence you're on just pick it.

"We don't have an exact list of your roles and responsibilities" ❌

This genuinely happened to me.

I still wonder what I would be hired to do, I am going to take a punt at trouser modelling for Asda.

Me and my pals in our black standard issue trouser chillin' in the dairy section

Solution ✔️

If you don't know what you want a candidate to do, you shouldn't hire them...however this specific example was a gambling company (they call it "Sports Betting" - it's gambling, don't try and zhuzh it up) after all, and they're not exactly known for operating ethically.

Summary

In no way are my views necessarily representative of every software engineer but these are sins and solutions have been procured from myself and others on both sides of the fence. In summation, companies need to change how they hire now or they will get left behind.