Forem: Anton Fenske

How to Create a Sensible Take-Home Coding Test

Anton Fenske — Tue, 28 Sep 2021 11:03:18 +0000

Tech assessment is an essential part of developer hiring. Take-home challenges seem a convenient option to assess tech skills because they are asynchronous and remove candidate's stress.

However, overlooking some fundamental aspects might lead to never completed tests, lots of time wasted on both sides, and bias when assessing candidates' results.

In this post, we'll cover the basic rules for ensuring that your take-home tests achieve their primary goal, i.e., identifying if someone has the necessary tech skills required for the job.

Problem

The main challenge with take-home tests is that people have to do them outside working hours. So you have to deal with the following constraints:

Candidates are short on time. So they might not complete your take-home test.
Take-home tests require a longer feedback loop. So given your candidates are in several interview processes, you might lose them to someone else.

Is There a Solution?

I have some bad news for you: unfortunately, there is no silver bullet to ensure that all your candidates will complete your take-home test and that you'll have enough time to select the best ones.

However, if you follow the ground rules below, it'll significantly increase your chances of getting the most out of your take-home coding tests.

Define a Concise Challenge Scope

First, define the main assessment objective and make your exercise revolve around it. The following questions should help you:

What experience levels do we target?
What tech skills do we want to assess?
Do we only want to screen candidates or do a full tech assessment?
What competencies can we assess automatically using auto-tests, and when would we need a manual code review?

Second, create a clear task description. Here's an example of the structure I stick to that has been working well so far:

Introduction - provides a general description of the task.
Getting started instructions - helps the candidate get started fast (e.g., describes the setup, how to run tests, describes external dependencies, etc.).
Expectations - describes what the candidate should focus on.
Way to get help - describes how to proceed in case the candidate gets stuck.
Time estimate - helps the candidate plan their time before starting working on the task.

Here is an example of how it could look:

Third, provide auto-tests that the candidate can run locally to help them ensure they built what you wanted them to.

Once your candidate volumes have grown, you can also use the auto-test results to vet your candidates with no developer effort on your side.

Reduce Friction

Stick to the process developers use every day:

Instead of sharing your take-home challenge as an email/Word doc/ zip file/, use a Git repository (ideally, use GitHub as most developers already have an account there).
Instead of asking them to send you an email when they are ready, tell them to create a Pull Request.
To avoid lost emails, ask them to create a ticket (e.g., GitHub issue) on their repository instead whenever they experience a problem.
Pre-upload a project template (or templates if you expect submissions in multiple tech stacks) so that your candidates don't waste time setting everything up from scratch. Feel free to use this upload script that has support for lots of tech stacks.

Define a Standardized Code Review Scorecard

Because we're all humans, it's easy to slide into the bias-land when code reviewing someone's work.

To ensure no bias creeps in, create a code review scorecard that includes the following:

The scoring rules. Here's one way to define it:

Define scoring criteria per evaluated area. Here's an example of how it could look:

Embrace Continuous Improvement

Likely your take-home challenges will have some sharp edges in the beginning. What's worse is that not all your candidates will be vocal about it.

To ensure that your take-home challenges are up to standard, use this 2-step rule:

Add the following to the challenge criteria: "Describe one thing you'd improve about this coding task".
Once there is a good suggestion, implement it right away. Following this rule will save your tech interviewing team hours of future process revamping.

In Closing

Developer hiring is hard. But it doesn't have to be terrible. Following the take-home interview principles above will already put you well beyond most of the hiring processes out there.

Is there a good principle not described in this post? Don't hesitate to share it below in the comments.

The easiest way to set up your next project

Anton Fenske — Mon, 15 Feb 2021 20:42:17 +0000

I recently open-sourced a collection of boilerplate repositories that I built for my coding tests platform.

I've been using these templates to spin up a candidate's workspace, and after about 200 interviews, it has proven to be efficient.

There are other use-cases where this setup can be useful, e.g., one can also use it to bootstrap a portfolio project with one click.

What's included

Each project is hosted as a template GitHub repository and has the following structure:

A minimal app implementation in the tech stack of choice.
A suite of E2E Cypress tests.
A GitHub actions pipeline that spins up the app and runs the tests on every push.

Available tech stacks

There are currently nine projects available for backend, frontend, and full-stack profiles, but I'm planning to keep extending the collection.

How to get started

Go to the project boilerplate webpage, select your favorite tech stack, and click on the "Use this template" button in the newly opened browser tab.

Hope you'll find this useful.

Let me know in the comments what other templates I should add. ✌️

I designed a frontend interview challenge. What's your approach to making one?

Anton Fenske — Fri, 09 Oct 2020 10:13:31 +0000

Recently, I had a chance to design a take-home interview challenge for Junior Frontend developers.

We've all heard (some even been part of) those horror stories when one would get a take-home, which would take days to complete.

This is what I wanted to avoid yet get enough insight into the candidate's experience. So I aimed to make something that could make a decent addition to the candidate's personal portfolio and take 2-3 hours to complete at most.

I ended up with a challenge with the following three requirements.

Integrating with a REST API ⚙️

Frequently, a frontend doesn't function by itself. It integrates with an API. Here, the candidate gets a functioning REST API that they need to figure out how to use.

Implement client-side data validation. 👀

As we all know, frontends are built for humans who interact with those. That data can be malformed. This app would make all the necessary checks before sending anything to the backend.

Document your choices. 📝

Last but not least, it's handy when all critical decisions are adequately documented so that we don't have to reverse-engineer the code months later. So the candidates are expected to write down any such choices they made while building this app.

How do you approach creating a new challenge? 🙌

I'm now curious to hear about your process (if any 😅) for coming up and iterating on your coding interview assignments.

Let's have a healthy discussion in the comments below. 👇

The 5 years that made me start a SaaS business during COVID

Anton Fenske — Wed, 30 Sep 2020 20:50:39 +0000

In September 2020, I went all in working for myself.

The COVID Pandemic and my cushy engineering manager job made it a hard decision. However, it wasn't an overnight thought of mine. In fact, It took me five years to wrap my head around it. I can divide that time into three entrepreneurial seasons of my life. Each season taught me essential lessons that provided enough insight into changing the course of my career.

Here comes my story.

Season 1: Naive ambitions

Back in 2016, not long after I relocated to Sweden for work, I discovered a popular local job website. People would use it to provide or find help with small stuff like fixing a clogged kitchen sink. What made me curious was that many folks were willing to pay a decent sum of money to place an ad there.

I checked out their website, and a few issues stood out right away. E.g., the site was far from user-friendly. Anyone could place an ad leading to potential fraud. And the list goes on.

So my devious plan was to make a better clone and get all their traffic.

The next thing I did was jumping right into coding. I'd worked with backend all my career, so most of my late evenings and weekends I spent learning how to do web development.

As you might guess, such an approach didn't make me rich. After a couple of months, I built an ugly semi-working clone that no-one ever visited. After a couple of failed attempts to promote it online, I abandoned the project.

This is how I learned that building in a vacuum is likely not how one starts a profitable Internet business.

Season 2: Following the Y-Combinator way

This season started with a Hackathon organized by the Swedish state. I participated together with a couple of colleagues from work. With zero prep, we unexpectedly won one of the prizes.

To collect the cash, though, the condition was to continue working on our project, which we were fine with.

However, it didn't take us long to realize that our prototype was impractical. In the next three months (I cringe realizing this) we spent debating what we should build. Eventually, we came to some sort of agreement. It was a mobile app for discovering vegan food. Ironically, none of the three of us were vegans. However, we knew veganism was trending back then, so why not give it a shot? Lol.

That year we also applied to the YC Startup School. The organizers screwed up with the invitation emails by accidentally inviting all 15 000 applicants into the program. Luckily for us, we got a tutorial to follow.

We did everything that YC told us: asked family and friends to test our product, talked with our early customers, shipped updates fast, yet something wasn't working out. Our user growth rate stagnated.

There were probably many reasons for that, but I believe the fundamental problem was that none of us were genuinely excited about the problem we were solving.

About half a year later, we abandoned the project.

It was a bit of a personal drama for me as I put a lot of my time and thought into this, yet the product didn't take off.

I told myself then that if I ever decide to build anything on my own again, I'll have to be in love with it.

Season 3: The Indie Hacker way

In the next few months, I spent my time studying the topic of building successful businesses online.

One resource I want to mention in particular was the Indie Hackers forum. It's where founders of so-called bootstrapped businesses exchange ideas and help each other with building their online businesses.

I got tones of insight and learned what a bootstrapped business is and how it functions. One common advice I heard over and over again was starting with the audience and their problem first. The solution gradually builds up, evolving through continuous iterations driven by customer feedback.

Another concept discussed a lot on the forum was the founder-market fit. In essence, it is an unfair advantage that sets founders apart from their competitors. This idea especially resonated with me, given my previous failed attempts.

I knew that, in my case, the founder-market fit was in software engineering. And one thing I always enjoyed doing was running technical interviews. I also had a decent idea of how resource-intensive it is to set up a rigorous interview process.

Next, I scheduled a handful of conversations with different companies who had had experience hiring software engineers before. That showed that there is ample room for improvement with how hiring teams assess tech talent.

In the next half a year, I continued speaking with different hiring teams to understand what I could bring to the table.

Eventually, I launched an MVP that made a few hundred bucks. That gave me enough confidence to realize I was on to something.

Then COVID came. Lots of companies went bankrupt, and almost everyone stopped hiring.

This gave me enough time to reflect on whether I want to keep going as an entrepreneur. There were obviously pros and cons, but I felt like the pros part outweighed. I still remember that extraordinary feeling when I got my first payment notification.

Season 4: Now

It's been a few weeks already since I went all-in with my entrepreneurial endeavor. A lot of companies have resumed hiring, which opened up for new exciting opportunities. I realize it's a marathon, but I've never been more excited to take on the challenge.

Thank you for reading till the end! I'll keep sharing my journey on Twitter, so don't hesitate to follow me there.

Building a coding interview platform from scratch. Choosing a hosting platform.

Anton Fenske — Thu, 21 May 2020 11:20:21 +0000

Hi folks! 👋

In this post, I'll walk you through how I picked a hosting platform for my coding interview SaaS.

When I need to make a choice regarding a particular technology, I start by asking myself: "What have I already used that will also work here?".

This time I needed something that can run code in the cloud and can provide a fast feedback loop between writing and deploying code.

🔥 Option 1: Firebase

I started with Firebase. I already used it in the past, and it looked like the right candidate. Firebase has Cloud Functions, and at first glance, it seems reasonable enough.

However, one thing I didn't like. Although it has a local simulator, I felt I still needed a way to quickly have every changeset available in the cloud while having the production version unaffected. Unfortunately, I didn't find an out-of-the-box way of doing this in Firebase. One option could be having a separate staging account, but it felt like too much hassle and not enough flexibility.

▲ Option 2: Vercel

Moving on to another option, I tried in the past - Vercel (former Zeit). At first glance, it might feel that this platform limits you in how you're supposed to build stuff. However, I didn't really find it too annoying. I was ok to write code in Javascript, and they have decent support for it. But going back to the deployment problem from above, Vercel solves quite elegantly. In fact, it's their value proposition: "Vercel: Develop. Preview. Ship.". First, they got integrations with all major Git platforms. And second, they provision a new deployment on each git push. And that's what I needed. So, long story short, this was my choice.

🤔 What about other platforms?

There are Netlify, Heroku, and others. Simple answer - I found something that solves my problem well enough, and I didn't want to waste any more time playing around with other toys.

In the next post, I'll share with you what I landed with as a data store.

☝️ One last thing

I share more behind-the-scenes including financial aspects of my SaaS on my Twitter. Don't hesitate to give it a look! 💫

Stay curious! ✌️

Building a coding interview platform from scratch. Creating a challenge repo.

Anton Fenske — Mon, 18 May 2020 21:28:18 +0000

Hi folks! 👋

Here comes the very first piece of the coding platform we'll be building. And that is where the assignments will live - Github.

I chose Github because every developer has an account there and more or less familiar with that interface.

Now let's see how we can organize the workflow.

🏰 Create an organization

These days you can do it for free even with private repositories included.

CoreSkills Github Organization

👯‍♂️ Create a challenge repo and turn it into a template

Template Example

It will allow for easy cloning of the challenge per candidate.

👀 Define an issue template with the challenge description

Issue Example

This will allow you to easily create an issue with the task description.

🥦 Add the necessary boilerplate to the repo

Boilerplate Example. Add whatever makes sense in your case.

This is to help candidates spend less time setting up the environment.

📨 Send your challenge to a candidate

Make a copy of the repo.

⛄️ Invite the developer

👍 That's it for now

In future posts, we'll continue with automating flows like inviting a candidate and submitting test results.

💡 If you don't want to miss the next post

Don't forget to click "Follow" below 👇.

👨‍💻 If you interview developers

I'd be curious to learn about your setup. Feel free to share a few words in the comments below. ✍️

Building a coding interview platform from scratch

Anton Fenske — Sat, 16 May 2020 22:37:26 +0000

Hi, devs! 👋

For the last year, I've been running a side gig interviewing developers for multiple companies. Now I believe I've collected enough learnings to consolidate them in a coding interview platform that I'm about to start building.

The idea is to share the progress as it goes, explaining technical details and decisions made along the way. That will involve building a disperse system with multiple services. I'm planning to share each step here on Dev.

If there's anything you want to know in particular, feel free to share in the comments below so that I include it in my future posts.

Stay curious! ✌️

Dope life-hack for content creation

Anton Fenske — Sun, 10 May 2020 20:44:36 +0000

I recently discovered a dope life hack while I was putting up docs for my SaaS.

💡 If you need to describe a user flow, get a good screenshot annotation tool. Then use lots of annotated screenshots and minimum text for description.

🚀 It's crazy how much time it saves.

37 minutes to test your next idea

Anton Fenske — Wed, 29 Apr 2020 15:53:08 +0000

👋 If you like this article, you'll most likely find more useful content that I share on Twitter, so don't hesitate to give it a look.

A few days ago, I launched a coding interview prep tool I wrote about here on Dev.

One thing worth mentioning here is that I only spent about 37 minutes creating a setup that provided me with data I could use to decide if my idea was worth working on.

In this post, I'll describe exactly how I did it, and hopefully, you can re-use this setup to save your precious time.

Step 1. Created a landing page on carrd.co - 5 minutes

Carrd has plenty of templates for different use cases, so you have the freedom to choose whatever you like the most.

For CoreSkills Challenge I went for this template:

Step 2. Wrote down my value proposition - 15 minutes.

This one was probably the most crucial step as visitors would use it to understand whether the product resonates with them and if they want to subscribe.

Here's one for CoreSkills Challenge:

Step 3. Created an email list on Email Octopus & configured Carrd to use it - 5 minutes.

As simple as that.

Step 4. Created a welcome email campaign on Email Octopus - 12 minutes.

The reason it took a few more minutes was that I needed to put down a few words in the welcome email. That's almost as important as the value proposition itself, with the only difference that I had more space to describe what the product was about.

That's it! 🙌

Feel free to re-use this approach, and let's not waste time building products no-one will ever use. 🙏

And in case you know even a better way to achieve a similar result, I'd appreciate it if you mentioned it in the comments below.

Stay curious! ✌️

One way to put your thoughts together when interviewing a developer

Anton Fenske — Tue, 28 Apr 2020 16:46:16 +0000

There's probably been an infinite amount of information on the topic of tech interviews. And that's a no-brainer since there's a limited amount of resources that go into the process. As a result, bias slips through, crucial details are missed, and wrong hiring decisions are made.

Over the last year, I've been running a tech interview platform called CoreSkills, where the primary metric of the product has always been the quality of interviews. And in this article, I want to share one fundamental learning I discovered that helped me avert most of the pitfalls above.

It all starts with defining a sound evaluation rubric. For CoreSkills, the following structure has been working well: problem, assessed skills, score, and comments. This structure lets me stay focused on the parts that matter the most and ignore the noise.

To bring a bit more clarity on how it might look in practice, let's consider the following example:

Problem	Assessed Skills	Score	Comments
Develop a REST API service according to a specification.	Python,Rest API,TDD,Backend	5	All clear. The service API works according to the spec and all related API tests pass.
Implement handling of faulty HTTP requests.	Error Handling,Python,Rest API, TDD, Backend	5	All clear. All related API tests pass.
Cover business functionality with unit tests.	Python, Unit Testing, Backend	1	No tests were provided and the candidate motivated he didn't have time to add them.
Implement a solution according to Acceptance Criteria.	Problem Solving	3	Overall, the problem is solved. The initially submitted version was missing certain details, but then after I pointed those out, the candidate updated the implementation.

It's important to note that the content of the rubric depends a lot on your situation, and it usually takes a few iterations to get to an optimal structure. That's why it's so crucial to collect feedback from all involved parties on the corresponding aspects of the interview.

Would this structure work in your interviews? What other ways of consolidating interview feedback did you try?

Don't hesitate to leave your thoughts in the comments below.

Stay curious! ✌️

Solidifying your software engineering identity

Anton Fenske — Tue, 28 Apr 2020 07:28:45 +0000

Hi, folks! 👋 My name is Anton and I just launched CoreSkills Challenge - a way to solidify your engineering skills with 10 min real-world coding tasks.

Why on earth am I doing this?

During the past year, I've been running an interview platform called CoreSkills. That experience, combined with my 10+ years in the software industry, let me acquire knowledge that enabled me to do cool things. These are just a few examples: running high-load payment processing systems in production, leading a dev team of 6 great engineers, and run a side-project that made some cash (can even call it profitable maybe 😃) in my spare time.

And CoreSkills Challenge is my attempt to share my knowledge beyond my current network. So let's see how it goes. 💫

I also share behind the scenes

And in case you're interested, feel free to follow my journey on Twitter.

Stay curious! ✌️

Designing a pragmatic coding interview - Part 3

Anton Fenske — Tue, 21 Apr 2020 08:22:56 +0000

The next component in our pragmatic coding interview process is a visual interview pipeline.

💡 Its main goal is to represent an up-to-date view of where each of your candidates stands in your interview process.

Let's go through the following pipeline as an example.

It's a Github project with 5 columns:
1️⃣ Challenges to send
2️⃣ Challenge sent
3️⃣ Under code review
4️⃣ Preparing scorecard
5️⃣ Challenge completed

Each of the columns is quite self-explanatory and we found this structure working quite well for the CoreSkills users.

☝️ One important thing to note is that such a pipeline doesn't replace an ATS, but it complements it by providing a more granular view of the coding interview step.