There are mixed opinions about coding tests for job interviews. 

Some developers are opposed to coding tests because they are incredibly time-consuming — or the test is irrelevant to the position — and others are hesitant to do labor for a company that may not employ them. While these are legitimate concerns, a good coding test has more pros than cons for both the employee and the company.

A relevant test can improve confidence in newly-hired employees — if a developer has already proven to both themselves and the company that they can do the job, it will help ease any anxiety about their performance. That confidence translates to concrete results, too — Aberdeen Strategy and Research reported that businesses that use pre-hire assessments, a category that includes coding tests, are 24 percent more likely to have employees who surpass performance goals.

In addition, there is an unexpected benefit to coding tests: They help avoid hiring bias. By using a test that produces concrete and relevant results, a business has objective metrics for their recruitment. It’s much harder for a person’s implicit bias to prevent hiring a diverse candidate when they’re not relying on subjective gut feelings. In a field that desperately needs more women and people of color, taking steps to mitigate bias can only be a positive.

While there are definitely coding tests that are less than effective at accomplishing their goals, there are plenty that benefit both the hiring team and the job seeker. Lever Software Engineer Ellen Chen and ShopRunner Lead Software Engineer Sarah Huynh sat down with Built In Chicago to talk about why the coding tests they took contributed to their positive recruitment experience, and how they prepared for and executed the tests themselves.

 

Ellen Chen

Software Engineer

 

Describe the last coding test you took. Why did you take it, and how did you feel going in?

The last coding test I took was Lever’s pair programming test as part of the panel interview step for my current role. I had an introductory call with the recruiter prior to the interview about its format, which enabled me to know what to expect and feel pretty good going into the test. The test itself was a coding exercise — a real-world problem I could potentially encounter while on the job. I was given some starter code along with a prompt describing the new functionality to add to it and what the expected output of the code should be. 

The test focused on core CS concepts like object-oriented programming, recursion and other data structures and algorithms. I was able to use the open internet and was allowed and encouraged to search things I wasn’t sure about — especially syntax — as that’s what we would do in our job’s day-to-day. They wanted to see how I would collaborate with other developers. I used CoderPad to run my code to be able to test out other ideas. After the initial implementation, I debugged and tested the code to ensure all cases were covered, and then further exercises were given to add to the code from there.

 

How did you prepare? Did you feel equipped to handle the coding test as you walked in?

Since I was already in the middle of my interview cycle, I had …….

Source: https://www.builtinchicago.org/2021/12/10/dont-get-bugged-coding-tests

Leave a comment

Your email address will not be published. Required fields are marked *