Why we take a "collaborative coding interview" approach

Matt Ward — Tue, 18 Feb 2020 17:10:12 +0000

The first time I interviewed for a position as a software engineer my experience was probably like most other engineers: I had a phone screen, I did a code challenge, and next I had an on-site technical interview.

Of course the on-site technical interview has its place. And for many companies and it is absolutely necessary, but in my experience (having been an interviewee many times) most companies follow the same rigid process to evaluate technical abilities of a candidate that will never even be used in the real world.

I concede and agree that there are also many companies where this type of technical interview is critically important in determining whether or not a candidate will be able to contribute to the success of the product. But as a hiring manager when you are deciding what type of process to run your candidate through you need to really take a step back and align your business priorities with your hiring process.

Particularly in a small company or a company comprised of small teams, soft skills are equally important to technical skills. In my experience as an interviewee, evaluating team cohesiveness was typically an afterthought.

In nearly all of the processes that I have gone through to “prove my worth” as a developer, a common theme was: I was sat in a room with multiple people who gave me a problem and watched on as I tried to solve it in a text editor (because IDEs are a crutch in an interview, but apparently not after you get hired.) In most cases, the problem I was given was clearly something that would never be encountered on a day-to-day basis - or possibly ever at the company.

There is a place for quantitative assessment in the interview process, and I believe in a basic code challenge up-front for that purpose. It provides you with a baseline for assessing candidates.

But once you have a candidate in the door, your mission should be to determine how you believe you can work with them, assessing their ability to learn, desire to grow, and assessing their ability to communicate and collaborate with the other team members. What’s more, you should be demonstrating to the candidate how you view them: as a peer and future team member. This person is not your adversary - they are a potential teammate.

I believe in a collaborative interview process which involves my team, the candidate, and myself. It is important to me that my team feels that the person we are interviewing is someone they can work with on a day-to-day basis. It is equally important the candidate feels comfortable interacting with the team as they may be a future team member.

To that extent, for an on-site, typically for the first 15-20 minutes we’ll just break the ice between everyone involved in the process and keep things very informal. I prefer to have some of my team members meet with the candidate without me so that there is less pressure.

Once everyone is feeling a bit more relaxed we typically move into the technical phase of the interview. As I mentioned, I believe this phase of the interview should be collaborative - as an assessment of how we could all work together, while also exercising the candidate’s technical abilities.

To feel collaborative, it is essential that everyone involved is trying to solve the same problem. To accomplish this, I will typically design a problem that spans 5-6 problem areas, based on a real-world problem and covers about 5-6 topics relevant to our development. Often, I will design the problem shortly before the interview, so that even I have questions. I prefer to not let my teammates know what the problem is until right before the interview as well, so everyone is on equal playing field.

When I present this problem to the candidate I make it clear that I want them to operate in a “real-world” setting. I want them to collaborate with me and my team, ask questions, use Google or any other assets at their disposal, and work together to come to a solution.

Of course I prefer that the candidate solve the problem entirely on their own, but even then, with my team not even sure of the solution themselves we can ask questions and engage in discussions and better assess our fit as a team.

Using this method - in addition to weeding out candidates who snuck through the initial technical assessment - we can better evaluate candidates on culture fit and soft skills while simultaneously evaluating technical ability.

I like this approach because it treats the candidate like a human. And by introducing a problem that no one on the team is prepared for it eliminates hubris, keeps everyone humble, forces everyone to pay attention and also provides the candidate an opportunity to actually teach the team something they may not have thought of.

If you are a technical leader and believe in building great teams I challenge you to work through an interview with a candidate on a problem you’re seeing for the first time. I believe you will be surprised and see unsuspecting candidates excel.

Preventing Accidents in the Workplace - with AWS

Matt Ward — Thu, 06 Feb 2020 17:44:01 +0000

When in production preventing data loss is often one of the highest priorities as an engineer, usually next to availability. Typically preventing data loss is focused on customer data, but what about losing the data the drives your application? Many applications today store static assets in some object store in the cloud and serve via CDN. Included in these static assets are typically things such as front-end application bundles which are the heart of the end-user experience.

If you’re working in the cloud, most cloud providers offer extremely durable storage solutions, AWS S3 offers eleven 9’s durability for example. This durability doesn’t help if someone accidentally deletes something though. Of course there are access controls to mitigate this scenario; you could lock out all engineers from resources that you feel are critical to your operation, but then you’ve created another problem - “zero trust” is a roadblock to productivity for most teams and in many cases is overused.

Assuming you trust your engineers to access your static resources, how can you mitigate production mistakes - i.e., deletion of resources? There are many solutions depending on your RTO or RPO objectives. Of course you need to weigh your tolerance for downtime with your cost of implementation and your ROI.

When talking about storing objects in S3 there are a lot of options at your disposal. A feature introduced at the end of 2018, S3 Object Lock, is a great feature that enables you to prevent the deletion of objects in S3 during a defined retention period. A caveat of this feature is that it doesn’t actually prevent overwriting objects. Another caveat of this feature, is that if you have a bucket that was created before November 26, 2018 it isn’t available to you!

If object lock is available to you though - you created a bucket after November 26, 2018 - you are well on your way to preventing accidental deletion of objects. What can you do to prevent overwriting objects though? Enable object versioning. Object versioning alone is going to protect your objects for the most-part. When coupled object lock and object versioning are going to give you a lot of protection against accidental deletion and modification. The difference is, object lock will prevent malicious deletion.

Great. What if you’re on working with a bucket created before November 26, 2018? And what if you do want to have zero trust to some extent - i.e., pure immutability. Enter S3 replication. With S3 replication you can choose to replicate cross region or same region to another bucket - replication effectively copies all of your newly added objects - after you have created the replication policy.

S3 replication will replicate your objects to another bucket of your choice cross region or same region. There is some nuance to how your buckets are configured and you can read more about that HERE but in general once you have replication configured, you can also configure zero trust on the destination bucket, object lock, and versioning giving you piece of mind that your data is backed-up, secure, and highly available (S3 offers 99.99% availability).

With data replicated to another bucket either cross region or same region you are well on your way to creating a highly available system for your customers. In a future post we will show you how you can use your replicated storage to use as a failover when needed.

DEV Community: Matt Ward

Why we take a "collaborative coding interview" approach

Preventing Accidents in the Workplace - with AWS