2253 stories
1 follower

CSS { In Real Life }

1 Share

It tends to be standard recruitment practice in the tech industry to require candidates to complete some sort of coding test or challenge. Sometimes this takes the form of the much-feared whiteboard interview – where candidates are expected to work through a problem on the aforementioned whiteboard, in front of an interviewing panel. In other cases, it’s a take-home assignment, or coding challenge. Often following an initial interview (or sometimes two rounds of interviews), the candidate is given a task to complete in their own time, generally something typical of the job they are applying for, or that requires many of the same skills.

This article is not specifically about the whiteboard interview, which I have never been through myself, although many of my points are equally applicable (perhaps more so). Rather it is about the utter uselessness of the “coding challenge”, and why I would never advocate using this to assess prospective candidates for your job vacancy. Having been a candidate for front end developer positions on several occasions, I am 100% convinced that coding challenges are a waste of time and resources, and cause unnecessary stress for the prospective. I particularly enjoyed this Tweet from Laurie:

(If you don’t want to read this whole article, read her Twitter thread instead!)

Disclaimer: I’m writing this as an interviewee, having never been on the other side of the interview table (for a web development position, at any rate). Perhaps you’re an interviewer and feel that coding challenges are important and valuable. I would argue that even if that is the case (which is doubtful itself), they are not worth the burden you put upon the candidate.


The number one reason I believe coding challenges shouldn’t be conducted is the amount of time they take to complete. Looking for a job is tiring and often demoralising. The chances are your candidates are already spending many, many hours writing out applications and tailoring their resumés. Many coding challenges come with caveats like “only spend six hours on this”, but in many cases candidates will spend much more time than stated. Why wouldn’t you, when you know there’s a chance that other applicants are spending more time, delivering a more polished result than you?

For this reason, coding challenges are anti-inclusive, only encouraging applications from people with unlimited free time. For candidates who are parents, have other caring responsibilities, work multiple jobs, have medical conditions, are studying in their spare time (the list goes on), six hours work for a job that they might not even get is time they simply don’t have.

Spec work: just don’t

A special mention here for “spec work”: It should go without saying, but requiring candidates to complete tasks that would otherwise be part of a paid job role is a complete no-no. I shouldn’t have to explain why this is bad, but it’s safe to say that if you’re expecting your candidates to do anything like the amount of work this challenge involves, you should be compensating them accordingly.


People do not do their best work when put under pressure. The whiteboard interview is a classic example of how putting someone in an anxiety-inducing environment is unlikely to yield the best results, but the coding challenge is stressful in its own way too. To be writing code knowing that every line will be scrutinised and judged to determine your future, means that you’re unable to concentrate fully on just writing code that works. You’re second-guessing all the time – “Will they approve of the way I’ve constructed this function?”, etc – which will likely lead to overthinking, sucking up the time you have available, and therefore requiring more of your time.

On the other hand, perhaps the challenge is easy for the candidate, and they’ll simply sail through it. Take the “to do” list application – a fairly common coding challenge example. It’s quite possible they’ll have built something like for an interview before, and this “challenge” will be re-hashing the same. In this case, you’re not learning anything that couldn’t be gained from looking at their previous work, and it wastes everybody’s time.

Some candidates may stick to the safety of their comfort zones, and focus on delivering something technically polished but less advanced. Others may overstretch themselves, taking on something new, only to fall short (while stressing themselves out in the process). An example from my own experience: apply for a junior developer role, I was required to build a landing page from a design. Although I had barely any experience with Javascript, it was one of the “desirable” job requirements, so I spent a disproportionate amount of time trying to add some JS functionality, meaning I had less time to do the things I was confident in doing well. I went into the interview already feeling like a failure. Either way, a coding challenge is an artificial environment, that doesn’t reflect the real world where an employee will feel less pressure. I repeat: it’s in no way an indicator of how they will behave in a working environment.

For these reasons, a coding challenge is unlikely to demonstrate what a candidate is truly capable of.


A disproportionate amount of time is often spent trying to deduce the requirements of the challenge. What is actually being judged? In the previous example, I didn’t know whether I would be judged poorly for my mediocre JS implementation, or looked upon favourably for having given it a go. Another case in point is this tweet from Carolyn Stransky:

Of course, you can ask your prospective employers if it’s not clear what criteria you’ll be judged against. But unclear requirements lead to more time wasted, and more unnecessary stress. In the worst-case scenarios, the person doing the recruitment doesn’t know the criteria themselves, beyond “I’ll know it when I see it”. (If that’s the case, then it’s a major red flag.)

What are the alternatives to a coding challenge?

So, what do I advocate instead? How is a manager to know which candidates have the most potential to shine at a job?

Ask pertinent questions (and trust in the answers)

Well, naturally you can ask them. A good interviewer should be able to encourage prospective employees to talk about their past experience with different technologies in a way that gives them an insight into how they would fare in the job role. What have they built? Were they part of a team? What were the constraints they needed to consider? How did they come to certain technological decisions? What do they like or dislike about a given technology? Which areas do they feel comfortable in, and where do they feel their knowledge or experience is lacking? What are they curious about? What would they like to learn or improve upon?

People don’t generally lie about their experience (they would soon get found out), although sometimes they might exaggerate for their resumé. An example is an interviewer looking for a React developer. Someone listing “React” as a skill on their resumé could be an accomplished React developer, or they could have only surface-level knowledge gleaned from attending a bootcamp or walking through an online tutorial. It should only take a few minutes of talking to them to understand the depth of their knowledge in this area, and whether or not they might be a good candidate for the role.

Have a probationary period

Most jobs have this already – a fixed trial period (usually 6–12 weeks), where the employer and prospective employee can determine if they are a good fit for the role. If not, they are free to part ways. Coupled with a good interview process, this should be sufficient. Plenty of people don’t pass their probationary period despite completing a coding test or challenge. There are many factors other than technical proficiency that determine whether someone is a good fit for your team, but coding challenges often focus on technical proficiency above all else.

Walk through their existing projects

Most candidates will have side-projects or work they’ve done for previous employers. Ask them to show you the code and describe the process, asking questions along the way (see above).

Even candidates for a junior role, perhaps who are fresh from a bootcamp, will likely have projects they can show. If they’re experimental or not public, that’s ok. It’s not the point of the exercise.

There might be some cases where candidates are unable to show work for specific reasons (such as NDAs). In those cases it might still be possible to talk about the work and challenges faced, without viewing the source code or going into specifics. But if none of these things are practical, there are still a few more options...

Ask them to build something – anything!

Instead of a coding challenge, ask them to spend a short time building something they enjoy, and talk about what they did and why. Perhaps they want to take the time to learn about a specific technology, so they put together a simple demo that helps them understand it better. Maybe they’re already a wiz with CSS animation, so they make a fun demo that really shows off their skills. Or another option, experienced by Jordan:

The difference here is that candidates are likely to be more comfortable talking about something they understand. The point isn’t how polished the result is, it’s how they talk about it afterwards.

I would still exercise a note of caution with this, as you are still asking people to complete an assignment in their spare time, which is not an option for everyone. I don’t advocate it as standard, but could be something to consider in exceptional cases.

You could argue the point of a coding challenge is to test a candidate’s limitations, which you might not glean from allowing them to choose what to build. Testing a candidate’s limitations is a terrible idea, which can only enhance the stress of the situation. And, as previously stated, stressed people don’t give an accurate impression of how they would behave in a “real” work situation. (Unless your work environment is super stressful, which is a whole other problem...)

Pair program

Again, I’m on the fence about this one, because pair-programming is not necessarily the less-stressful option. Personally, I don’t feel like I do my best work when someone is watching my every move – I would probably do a lot less Googling, and write far worse code! But if this is done well and with empathy, it could be used as a last-resort.

Focus on their ability to learn

Arguably, a candidate’s ability to learn is more valuable than how much knowledge they possess on a given subject right now. Coding challenges can only really demonstrate a current skillset. A better strategy might be to walk through an example of your company or product’s code and encourage the candidate to ask questions, as well as talk about what aspects they are familiar with.

A “good” coding challenge

If I haven’t convinced you to dispense with coding challenges altogether, let me give you one final piece of advice: Don’t try to catch people out. Make your challenge something straightforward that people can complete without hidden “gotchas”.

Here’s an example: For one position, I was given the challenge to build a simple app using API calls to get and post data to a server. I was given access to a starter repository, only when I tried to run the project locally I kept getting an error. I spent hours trying to debug it, thinking I was doing something wrong, berating myself for falling at the first hurdle (before eventually figuring it out!). At the subsequent interview I learnt that this error had been put in deliberately, to test whether I would reach out and ask for help. This immediately put on the back foot for the rest of the interview, despite not remotely reflecting how I would act in a work environment.

So. Don’t do that. And, if you can help it, don’t set a coding challenge at all. There are better ways to spend your (and your candidates’) time.

Read the whole story
18 hours ago
Hamburg, Germany
Share this story

How to Incrementally Migrate 100k Lines of Code to Typescript

1 Share

Migrating a large project to TypeScript even with the loosest settings may be insurmountable. The number of errors is overwhelming.

You may think the best options for fixing this situation is to use a mix of TypeScript and JS (using the allowJs flag), however there is a risk of a large amount of code never being typed because there is not enough incentive and feedback to do so.

If you run TypeScript on a large project after renaming files you may be faced with something like:

Too many TypeScript errors.

Or there could be a lot more errors, this project started with 15k errors.

Unfortunately for a project of any sufficient size, you’re going to run into trouble trying to migrate to TypeScript in one go.

So what are your options?

Dimensions of ComparisonSolo HackathonTeam HackathonEnable on Changed FilesChecklist + Coach TeamSnapshot Test
High Quality ResultsYMMV
Low Team-Coordination
Non-Breaking For Wip
Reliable On Larger Repos/Messy Code
Can Enable Strict Rules On Day 1
Easy To Add Stricter Rules
Will Achieve 0 Errors
Easily Repeatable For New Rules

Think about it.

Ideally you would like to achieve 0 errors and have an easily repeatable process for preventing new errors. To do this your best option may be creating a snapshot test.

On a high-level, using a snapshot test requires creating a test that runs TypeScript and saves a snapshot of all the errors along with filenames and line numbers. This test will fail anytime lines are shifted on a file with errors, or when new errors are added to the codebase — this serves as a reminder to fix type errors when adding or modifying code. This requires low coordination because it’s an automated approach.

It also becomes very easy to incrementally increase the strictness of type checking, the incremental approach is the same.

In essence, the snapshot test is closer to the code than any checklist process and it requires low team-coordination.

How to create a snapshot test of TypeScript errors?

This repo (DylanVann/typescript-migration-demo) shows a basic example of how to snapshot test TypeScript errors.

Here’s how it works, consider the following 3 untyped JS files:

export default function add(a, b) {

a + b


export default function subtract(a, b) {

a - b


import add from './add'

import subtract from './subtract'

add('1', 3, 'hello world')

subtract('1', 3, 'hello world')

When we convert to TypeScript (changing file extensions and adding a tsconfig.json file) this will produce a number of type errors:

Errors after changing file extensions to .ts.

At this point you should run the snapshot test and commit the result. The snapshot of the errors will look something like this:

Snapshot of TypeScript errors.

What happens when I fix or add type errors?

When you fix type errors you can run yarn check-ts -u to update the snapshot, and you will commit something like this:

Diff after fixing TypeScript errors.

If you were to add a type error by accident you would see something like this:

Diff after adding TypeScript errors.

So at this point if you are doing PR reviews your reviewer would probably reject this change.

This technique applies to any pattern that can be detected using code quality tools. For example it’s possible to write ESLint rules for bad practices specific to your codebase. You can then incrementally remove them using this technique.


Out of all the possible techniques to migrate to TypeScript this one has a lot of things going for it.

Read the whole story
20 hours ago
Hamburg, Germany
Share this story

Hello from Ruby Jard | Ruby Jard

1 Share

Navigate with pleasure

Thank to backtrace visualization and source code display, you'll never get lost in the dump of backtrace again. By default, those interfaces are always available, and compact.

You now can freely go up, and down of the current stack trace. At each frame, you can view the source code, input parameters, relevant variables. This helps you create a minimap of your program execution in your mind.

Nonetheless, you can even continue the execution at a particular upper frame, get out of unwanted boring gem, or just skip a nested loop with ease.

Read the whole story
2 days ago
Hamburg, Germany
Share this story

Write once. Deploy everywhere.— BeeWare

1 Share

One codebase. Multiple apps.

BeeWare allows you to write your app in Python and release it on multiple platforms. No need to rewrite the app in multiple programming languages. It means no issues with build tools, environments, compatibility, etc.

Python native tools...

Python has proven itself as a highly capable language - approachable for newcomers, but powerful in the hands of experts. Why shouldn't you be able to use Python everywhere that you need to tell a computer to do something? And shouldn't your tools exploit all the capabilities of Python as a language, not just the bits that map nicely to a C binding?

...on mobile & desktop...

Modern computing doesn't happen in an 80x25 console window. It happens on phones, tablets, and desktop machines with rich user interfaces. Shouldn't you be able to use Python in all those locations, and exploit the unique capabilities of those platforms?

...behaving natively.

End users shouldn't have to care what language their tools are written in. And that starts with looking and behaving like completely native tools. Native appearance, native behavior, delivered in the way a native app is delivered. Why shouldn't your Python tools fit in just as well as a native tool?

This is what BeeWare provides. Tools to help you write Python code with a rich, native user interface; and the libraries and support code necessary to get that code running on iOS, Android, macOS, Linux, Windows, tvOS, and more.

Open source

The Open Source development process has proven itself to be the most reliable way to develop robust and reliable software. That's why the entire BeeWare suite of tools are BSD licensed, and available for all to use and modify.

All contributions welcome

But it's not just about code. A successful software project requires documentation, design skills, feedback and bug reports. The BeeWare community acknowledges that all contributions are important — not just the ones that come as a pull request on GitHub.

From diversity comes strength

A diverse community is a strong community. This means accepting people of all levels of experience, from all backgrounds, of all races, creeds, orientations and expressions. The BeeWare project is committed to developing and maintaining a diverse, welcoming community. We have an open offer to mentor anyone who wants to get involved as a contributor, backed up by a Code of Conduct that is rigorously enforced.

Read the whole story
2 days ago
Hamburg, Germany
Share this story

Is this evil? Analytics via CSS

1 Share

In a recent episode of JS Party we were told that you can program in CSS. But you can do some less complicated things with bigger payoffs. You can use CSS to track users that have JS disabled. Not sure how to feel about that. This post covers the rough idea of it and wants your thoughts on the practice.

Discuss on Changelog News

Read the whole story
3 days ago
Hamburg, Germany
Share this story

Evidence of Alien Life

1 Comment and 8 Shares
Both too cautious AND not cautious enough: "I'm skeptical that those are aliens, so I'm going to try pulling off their masks."
Read the whole story
3 days ago
Hamburg, Germany
Share this story
1 public comment
4 days ago
Both too cautious AND not cautious enough: "I'm skeptical that those are aliens, so I'm going to try pulling off their masks."
Next Page of Stories