new article

This commit is contained in:
Morten Olsen
2022-04-15 22:45:01 +02:00
parent fdda10b52b
commit fea27d9a5f
14 changed files with 76 additions and 61 deletions

View File

@@ -1,3 +0,0 @@
title: A defence for the coding challange
parts:
- main.md

View File

@@ -1,48 +0,0 @@
Let's talk about code challanges. This is a topic with a lot of opinions and something I myself has been unsure if i liked or absolutly hated, but I would like to make a case for why I think there are situations where this practice actually are benificial, not only for the interviewer, but the candidate as well.
## Downsides
But before getting that far I would like to point out some of the down sides to code challanges, because it isn't a one size fits all and you may want to steer completly clear of them, or only use them in specific cercumstances.
## Downside #1
The primary issue with coding challanges are that they may be build in a way that prevents the candidate from showing their strength. I have for instance often seen those logic-style code challanges being applied to all development prositions, so a front-end developer would be quiz'ed in his ability to solve sorting algorithms, while what he would be suppose to do after being hired where aligning stuff correctly with CSS. This kind of skill tests, which ultimatly assesses a completly different set of skills than what is needed will lead to alienating the candidate, and allow a candidate with skills in the quized topic to overshine one with the skills actually required.
Later I will talk a little bit about some requirements that I think need to be thought into a good code test, so if used, at least would give a better indication of a candidates skill in relation to the specific role, not just as a "guy who does computer stuff".
## Downside #2
Second one is one I have mentioned before, but in a competative hiring market, being the company with the longest hiring process means that you might very well miss out on some of the best candidates, due to them not having the available time to complete these tasks in their spair time, or because another company was able to close the hire quicker.
# Why you may want to use code challanges
My first point here was one I was debating with my self if I should add to the downside as well. A lot of people don't perform well under this kind of pressure, so this might obscure the results. The reason I did not put it into the downsides, but will instead use it as my first argument is that the alternative is that you can only showcase your technical skills in the actual interview!
The IT space has historically been associated with an introvert stereo type. While not always the case, they are definatly out there, and there is nothing wrong with that, but they are usually not the strongest at selling them self, and that is basically what most job interviews are about. So if we give a candidate only the ability to showcase their skills through an interview it stands to reason that the guy we end out hiring aren't nessicairly the strongest candidate for the job, but the one most who is best at showcasing hers/his skill.
Using a code challange along side the interview allows you to use the interview part to assess the person, get an idea about how they would interact on the time, have time to explain to them what the job would be like, without having the "hidden" agenda, of trying to trip them up with arbitrary technical questions, to try to see if they can answer correctly on the spot.
So instead of the on the spot question style, the candidate would get the time to seek information and solve the tasks in a style much more remanisant of how they would actually work in the real world.
Additionally, if done right, the code challange can also help the company/team to prepare for the new candidate after the hire. If your code challange can give an indication of the candidates strength, weaknesses and knowladge level with various technologies, this can help put the "training"-program together, to help the new hire being up and running and comftable in the position as quicly as possible.
## What makes a good code challange
It is a difficult question to ask, as it would very from position to position, team to team and company to company. Some position may require a specific knowladge set, where the "implement a sorting algorithm" may be the right test, and be something you would expect any candidate to be able to.
I can give an example of my recommendation for a code test, to use with new developers. The role is actually quite open ended, we need good developers, and have so many open positions so if you have talent in an area, we most likely need you.
The particually test in question should be one that could be used to test people both at their frontend, backend-for-frontend, QA, DevOps, etc. skills. Not that a candidate should have skills in all those areas, but we want the candidate to be able to show there skills in any of those areas.
So the idea I came up with was to create a small `next.js` app, which is an application building platform we use in a lot of our projects and has a large industry adoption.
I would have prefer to not have to tie it to any specific technologies but that would have made the codebase to large for a small code challange.
In the `next.js` app we would create and API endpoint with a simple data source. This endpoint would contain bugs.
We would also implement a frontend feature, which used this endpoint. And the frontend would contain bugs.
The project would also have a few broken unit and end-to-end tests
It would also have a target environment that it was deployed to, but with no DevOps pipelines for it.
All the code would be written in a suboptimal way (not linting compliant, less than perfect naming etc.)
Additionally there would be a "backlog" with a few items that the ficticious product owner and team of this ficticious product had created, which would contain action items for fixing the backend bug, fixing the frontend bug, improve the styling of the code, setup CI/CD, fix/add QA etc. along with a new feature request which would require adding a new API endpoint as well as an interface

View File

@@ -0,0 +1,4 @@
data:
type: article
structure: ./index.yml
generator: latex

Binary file not shown.

After

Width:  |  Height:  |  Size: 164 KiB

View File

@@ -0,0 +1,6 @@
title: A defence for the coding challange
published: 2022-04-15
cover: cover.png
shareImage: ./share.gen.yml
parts:
- main.md

View File

@@ -0,0 +1,36 @@
Let's talk about code challenges. Code challenges are a topic with many opinions and something I have been unsure if I liked or hated. Still, I would like to make a case for why I think there are situations where this practise is beneficial, not only for the interviewer but the candidate as well.
But before getting that far, I would like to point out some of the downsides to code challenges because it isn't one-size-fits-all, and you may want to steer completely clear of them or only use them in specific circumstances.
## Downside 1
The primary issue with coding challenges is that they may be built in a way that prevents the candidate from showing their strength. I have, for instance, often seen those logic-style code challenges being applied to all development positions, so a front-end developer would be quizzed on his ability to solve sorting algorithms. What he would be supposed to do after being hired was to align stuff correctly with CSS. This skill test, which ultimately assesses an entirely different set of skills than what is needed, will alienate the candidate and allow a candidate with skills in the quizzed topic to overshine one with the basic skills required.
Later I will talk a bit about some requirements that I think need to be considered in a good code test, so if used, at least would give a better indication of a candidate's skill concerning the specific role, not just as a "guy who does computer stuff".
## Downside 2
The second one is one I have mentioned before, but in a competitive hiring market, being the company with the most prolonged hiring process means that you might very well miss out on some of the best candidates due to them not having the available time to complete these tasks in their spare time, or because another company was able to close the hire quicker.
# Why you may want to use code challenges
Unfortunately, many people don't perform well in interviews. Without a technical assessment, the only place for a candidate to showcase their skills is in the interview itself.
The IT space has historically been associated with an introvert stereotype. While not always the case, they are definitely out there, and there is nothing wrong with that, but they are usually not the strongest at selling themself, and that is basically what most job interviews are. So if we give a candidate only the ability to showcase their skills through an interview, it stands to reason that the guy we end out hiring isn't necessarily the strongest candidate for the job but the best at showcasing hers/his skill.
Using a code challenge alongside the interview allows you to use the interview part to assess the person, get an idea about how they would interact on the team, have time to explain to them what the job would be like, without having the "hidden" agenda, of trying to trip them up with random technical questions, to try to see if they can answer correctly on the spot.
So instead of the on the spot question style, the candidate would get the time to seek information and solve the tasks more reminiscent of how they would work in the real world.
Additionally, if done right, the code challenge can also help the company/team prepare for the new candidate after the hire. For example, suppose your code challenge can indicate the candidate's strengths, weaknesses and knowledge level with various technologies. This can help put the "training"-program together to support the new hire to be up and running and comfortable in the position as quickly as possible.
## What makes a good code challenge
It isn't easy to answer, as it would vary from position to position, team to team, and company to company. Some jobs may require a specific knowledge set, where the "implement a sorting algorithm" may be the proper test and be something you would expect any candidate to be able to.
But here are a few questions I would use to evaluate the value of a code challenge:
1. Does it cover all the areas you are interested in in a candidate? This is not to evaluate if the candidate has ALL skills but rather to see if he has some skills which would add value to a team. For instance, if the role is for a front-end team that does both the front-end development, back-end for front-end, QA, DevOps, etc., the test should allow a candidate to showcase skills. If, for instance, your test is too heavily focused on one aspect, let's say front-end development, you may miss a candidate that could have elevated the entire team's ability at QA.
1. Does it allow for flexible timeframes? Some candidates may not have time to spend 20 hours completing your code challenge, and the test should respect that. So if you have a lot of different tasks, as in the example above, you shouldn't expect the candidate to complete all, even if he has the time. Instead, make a suggested time frame, and give the candidate the possibility of picking particular focus areas to complete. That way, you respect their time, and you also allow them to showcase the skills they feel they are strongest at.
Another bonus thing to add is to give the candidate the ability to submit additional considerations and caveats to their solution. For example, a candidate may have chosen a particular path because the "right" approach wasn't clear from the context, have made suboptimal solutions to keep within the timeframe, or even skipped parts because of scope but still want to elaborate. This way, you get closer to the complete picture, not just the code-to-repo.

View File

@@ -0,0 +1,9 @@
generator: html-image
data:
name: 'article/a-defence-for-the-code-challange/share'
template: ../../images/share.ejs
background: './cover.png'
title: A defence for the coding challange
subtitle: 5 min read
width: 780
height: 780

View File

@@ -1,6 +1,6 @@
title: How to hire engineers, by an engineer title: How to hire engineers, by an engineer
cover: cover.png cover: cover.png
published: 2022-03-16
shareImage: ./share.gen.yml shareImage: ./share.gen.yml
published: 2022-03-16
parts: parts:
- main.md - main.md

View File

@@ -1,6 +1,9 @@
generator: html-image generator: html-image
data: data:
name: 'article/hiring/share' name: 'article/hiring/share'
template: ./share.ejs template: ../../images/share.ejs
background: './cover.png'
title: How to hire engineers, by an engineer
subtitle: 5 min read
width: 780 width: 780
height: 780 height: 780

View File

@@ -0,0 +1,2 @@
title: Web 3.1
parts: []

View File

@@ -15,7 +15,7 @@
left: 30px; left: 30px;
right: 30px; right: 30px;
background-color: #fff; background-color: #fff;
background-image: url("<%=getAsset('./cover.png')%>"); background-image: url("<%=getAsset(background)%>");
background-size: cover; background-size: cover;
background-position: center; background-position: center;
opacity: 0.3; opacity: 0.3;
@@ -60,8 +60,8 @@
<body> <body>
<div id="bg"></div> <div id="bg"></div>
<div id="info"> <div id="info">
<div id="title">How to hire engineers, by an engineer</div> <div id="title"><%=title%></div>
<div id="subtitle">15 min read</div> <div id="subtitle"><%=subtitle%></div>
</div> </div>
</body> </body>
</html> </html>

View File

@@ -37,9 +37,7 @@ const SlideIn: React.FC<React.HTMLAttributes<HTMLDivElement>> = ({
{...props as any} {...props as any}
ref={ref} ref={ref}
initial={{ initial={{
y: 50, y: '100%',
opacity: 0,
scale: 1.3,
}} }}
animate={controls} animate={controls}
> >

View File

@@ -51,7 +51,7 @@ export class ArticleDB {
structure.parts.map((part) => generate( structure.parts.map((part) => generate(
location, location,
part, part,
2, 1,
this.#assets, this.#assets,
)), )),
); );

View File

@@ -25,7 +25,7 @@ const ImageWrapper = styled.span`
`; `;
const Wrapper = styled.article` const Wrapper = styled.article`
line-height: 1.8rem; line-height: 2.1rem;
background: #fff; background: #fff;
p + p:first-letter { p + p:first-letter {
@@ -53,6 +53,14 @@ const Wrapper = styled.article`
line-height: 3.8rem; line-height: 3.8rem;
margin-bottom: 0; margin-bottom: 0;
} }
h2 {
margin-top: 5rem;
}
h3 {
margin-top: 3rem;
}
`; `;
const Meta = styled.div` const Meta = styled.div`