Hiring junior developers is _______

Because you want to give them a shot. Just.. a shot. Just a chance to be somebody. So give them a shot.

Pop Culture question! Five points to who knows which show and episode I’m referencing :)

Disclaimer: some profanity and rants await you. Plus some tips I hope (^_^)

The Broken Interview Process and How to make it better

Let me start this post off by how the interview process for hiring software developers is fucked up.

Yeah I swore a bit there. But that’s how I want to convey my emotional angst when I think about the interview process.

You have the timed interview setting. Why make it pressured?

Do you actually work in a timed environment? Do you have three people looking at you while you try to code up something under time?

Is your work environment like, that much fucked up so you have your bosses breathing down your neck to roll out new features ASAP?

Okay so no. Then why is that something you try to measure new candidates for? You are biasing your new hires to be poeple who can bang out solutions as quick as possible. People train for coding interviews. They buy books to solve algorithms, practice solving algorithms daily to get prepared for these interviews.

You can literally google this topic and have COUNTLESS people more professional and experienced than yours truly weighing on this topic.

Unless you are a FAANG company, you can’t really try to act like a FAANG company. Why on Earth would you try to narrow the gap of candidate pool? FAANG companies can afford that because they have a huge amount of pool. They can pay. They also need to hire on standard - they need generally people who don’t quite thrive in chaos, who can follow orders, and who can be a generalist. Those who are willing to suck it up and go practice the coding challenge questions, and are OK with not using any of the coding challenge skillset while they work. Because money.

Hey, I’m not against money. I’m not against generalists either. Let FAANG be FAANG. Their setting of hiring people is that level, because they can afford it. They can throw whatever obstacle at the pool, and the pool can suck it up and jump through them. That’s what I’m against - that disparity between FAANG level companies and the SMB companies. You have to be nimble and suck up or drop that facade of pride. Arrogance if you will. Arrogance/ lack of courage that you can act like FAANG because that’s the safe path. That’s how you weed out poor performers.

Nope, wrong. That’s how you LOSE a ton of applicants who might be actually really good performers! You are losing out on people with the following traits:

• People whose bullshit-detection meter is up to 11
  • I worked with a seasoned software engineer at my previous company. The engineer, when we interviewed, said if there is a step to do coding challenges, then deal’s off. This engineer has done 20+ years in the industry, even managing large teams. You’re losing out on people like this.
  • When people say they don’t like coding challenges for interviews, they are saying something right. And when the companies are pushing against that notion, that common notion proven by countless debates rising up in HackerNews or any places where programmers congregate - then something is not right.
  • So, when something is not right, what do you do? Do you say that’s cute, but it’s not something you care about? Do you not feel the need to change? => These people are going to be in your candidate pool. Those who follow orders really, really well and have a natural tendency to not question the norm.
  • OR, would you do something about it? Would you state this is bullshit and state your case? Would you venture out and scope companies that actually DON’T ask live coding challenges? => Congratulations “smart” companies, your pool of candidates are those who think one step more, and are willing to stand up for something.
  • SMB (small / medium businesses) want to grow. You need a team of people that are diverse enough to get through countless situations thrown at you. You need all of them congealed together - those who THRIVE in chaos, who cherish being gung-ho, all-in-your-face grit, us-against-the-world mindset, the renegades, the here’s-how-it’s-done-right old-schoolers, pirates.
  • You lose out on this. Well, most do. So.. if you decide not to, then this is an EASY win on bringing on a diverse group of team that can win you some business.
  • It’s so odd, like seeing people struggle on basic coding algorithm challenges triggers a thought that the candidate doesn’t have the heart to work in this company. Because how dare they do not go through coding challenge practices like everyone else. I’ve felt that too as an interviewer, and I was wrong. It’s messed up.
  • OK, that’s all good but then how do you really guage someone’s proficiency / level, you ask? Read below and I’ll share some suggestions.
• People who can’t function under pressure but EXCEL while in a calm setting
  • I am an introvert who is this person. And I’ve been on the interviewer side often enough so I saw these type of candidates come.
  • If I am in a committee of interview management team, I often raised concern of this issue of biasing against introverts, but normally I don’t have that much power. It’s an uncomfortable thing to say.. in the era of open offices, favoratism for those who can code as extroverts - thriving in rowdy settings, where everyone speak across desks at each other, have impromptu Nerf gun fights - introverts are weird quirky people who can’t really see the point of all this.
  • Sure with practice and rehearsal in front of the mirror many, many times, introverts can fake social settings that are stressful settings where you have to perform, like live coding challenges.
  • I have seen people start shaking their markers while we just sit there and stare at them. Sweating profusely. These people who had YEARS and are veterans, just fumbling after some shit algorithm that they learned in universities and industry experiences never really asked for.
  • Are engineers .. doctors? Do they have to memorize a ton of knowledge and have to become walking Wikipedias for algorithms and rules of the ever-changing world of programming? Like I kinda get the point for medical students to be such. But software engineers? In the age of the Internet? Where most engineers have often opened up StackOverflow while they work?
  • “Quiet people can’t function in our company”? Nah. That’s a biased notion on what quiet people are. Given enough bullshit, they are actually the force that causes positive change in your company. I highly recommend reading “Quiet: The Power of Introverts in a World That Can’t Stop Talking”, by Susan Cain. Introverts have a way of enforcing change but without friction. A quiet lawyer who can make a case and win, while not putting down the opponent lawyer down in any way. Where people succomb and get in line while being okay with that. So give them a chance. If quiet people can’t function in your company, then your company is shitty and has a bigger problem. Quiet workers in your company are just quietly dying inside whilest trying to get by. It’s going to be a leaking, sinking ship pretty soon.
  • Again, you can’t get these type of people if you employ pressured live coding challenges in your interviews.

OK, OK!! What does this have to do with hiring junior developers?! Focus on your topic you noob blogger!

Hey, watch it! I’m not a blogger! I’m the head of this software service company and I’m doing content marketing now! Slightly different!

I’m gonna get to it! Just keep reading!

So where was I. Now you threw me off!

Anyways okay. Junior developers are the new fish in the pond. These are the sensitive breed. Sure they can keep learning and practicing coding challenges, but let’s face it - if their purpose for that is to get into companies, then this arragement is super toxic.

Programming is one of the most creative process that should be treated like an art. You need years to craft your skillset. Think like any trade - cobblers, electricians, home restoration workers - they all need time and practice.

So as a programmer with some years under by belt, I would highly recommend doing the coding challenge practices as a way to better the understanding of code in general. Here’re what goes inside your head when you do these coding challenges, which I believe is good for you - just not good for you when you think it’s the means to an end of getting into a good company:

1. You read a problem and try to figure out how to solve it
2. You work out some chain of attack in getting to a solution
3. Then you go into translating your thought into code
4. After that you start testing your logic
5. Feedback loop, learning more as you find bugs in your code
6. Fixing the bugs teaches you to be meek and humble, and also grit - as no one can solve this but you

So you see, these are very valuable traits to embed in you as a programmer - and it’s fun! Isn’t it fun? To have your thought and hypothesis actually come to life! And then let that function return an answer! Amazing!

It never gets old for me. I’ve been doing Codility lessons every day recently, and it really is fun. It’s pretty addictive, like games. To get to that 100%, and then shaking that fist in the air when you reach it… exhilarating.

And while I do them, I feel like I learn a lot about art of programming - ones I haven’t been able to face in my job.

So yeah, practicing to hone your skills is not that bad, and practicing with these coding challenge websites are fine in my opinion. I highly recommend it for junior developers.

Just don’t fucking do it to get into jobs - as in to ace live coding challenges. Don’t fucking memorize how to write binary search trees or bubble sorts or red-black trees in order to be really good in the interview session. You’ll be losing that excitement to code real fast. And then this will be just a job for you. Nothing, nothing is as sad as seeing someone lose that fire in their eyes - talking to someone and realizing they just don’t care anymore in code - just job security. Really pains me to see it happen.

No one trusts engineers who write code using memorized algorithms, who can’t use documented resources. And yet - why interview for that skillset.

And we, those who would be at the other side of the interview table, shouldn’t force junior developers to be in that position. SMB companies shouldn’t either.

OK, then how can you make the interview process better to get good candidates? And what about junior developers?

Well for starts don’t do what I ranted about, and instead to these things:

1. Give take-home coding projects that are fun to do!

You must make your company feel like it cares. That bleeds into these projects. However you must be respectful of the candidate’s time, so some points to consider, reasons why:

• Make them short and to the point: don’t make them create a huge app, instead make it small but complex enough.
  • Limit the time, but understand they might take longer as they are working. Just chill. Be chill. You don’t know their life, so be forgiving.
• In the description of the project, write detailed guidelines and implementation targets so there’s no confusion.
  • This tests on reading comprehension. You need to test for if the candidate can understand the task.
• Be in constant communication with the interviewer - this is how you operate as a team, so the interviewer should be able to cooperate with the candidate this way. - This tests the candidate’s method of communication. How do they talk in emails? How do they approach requirements aggregation/internalization? Do they start working only after everything is figured out, or do they do first/ ask questions later?
• Encourage the candidate to freely add more, but the breadth/direction of this should be broadly stipulated in the instructions
  • This shows the creative side of the candidates. I suck at this so I don’t want to add too much credit to the creative side
  • But what this actually shows is that they have decided the task requirement is met and done, which shows the level of understanding, dedication, responsibility.. or just hard-headedness. I’m not saying that’s wrong. All traits are needed to creating a kickass team!
• Create a private repo for them to download, commit, and push, for each candidate. Recommend to commit frequently, and give a codying style guide for them to read and apply.
  • Maybe the candidate isn’t the actual coder. You never know. But git commit history is a way of finding that out - not perfect but there are ways after the take home challenge to find that out.
  • When reading the git commit history, you can find out how the candidate thinks:
    • Did the candidate start off with a school base project? Why did they do that?
    • How often do they commit? Or is it just one commit?
    • How do they think? Which parts do they start working on?
    • Do they keep trying many ideas? How do they manage attempts?

Here’re some example projects I recommend for frontend:

• Give an API that does CRUD, and create a multi-page SPA in React that does CRUD
• Show a UI design that goes over a UX of a component (a badge, tick, type-ahead search with suggestion dropdown, side pane menu, etc) but prevent from using 3rd party libraries, enforce raw React + pure CSS work
• Given raw picture of a website, test how they code it up in React

Here’re some example projects I recommend for backend:

• Give a 3rd-party API to do CRUD, create a reverse proxy microservice that is scalable and maintainable
• Given a MySQL database, create a service that will do CRUD, and then design how to work with the frontend
• Create a service that will provide a real-time cryptocurrency price ticker (instead of stock because that’s been done too much)

Here’re some architecture questions I recommend

• Design a Twitter clone
• Design a Yelp clone
• Design a Discord clone
• Design a POS(Point of Sale) system in the cloud
• Design a Ring clone

Now obviously for junior level developers some of these are pretty advanced questions. So depending on level of expertise, this is generally an open ended question.

2. Invite them to discuss the project

This is where the interviewer has to go through the project first. You have to fully dissect the parts of the code.

Here’re some pointers/checklists when evaluating the code.

• Check if it runs. If it doens’t run, doesn’t look good.
  • Does it run, but not work according to specification?
• Read anything the candidate said about the code
• Check git commit history for the points said above
• How’s the code? Is it organized and easy to read? Does it make sense?
  • one thing to note is this is where you see the algorithm usage levels of the candidate. Maybe some things are done in a very weird/inefficient way.

Then, and ONLY THEN, invite the candidate to discuss the project.

Ask the questions and listen to the answers. Work like a team - don’t act like you are the gate keeper to all riches and glory. You are asking as if you are the code reviewer of a team member. Be humble, respectful, but still analytical.

Don’t hound them to sweat them on points that are wrong. Ask them what why it’s not functioning as intended, or if the lines in the code can be done better.

However, do confront them a bit and see how they react on the points that could be fixed. Do they get defensive real fast? Do they state their claims but agree it’s something that’s wrong (it has to be really wrong)? Do they just sheepishly follow along without any defense?

It depends on what the company needs, but generally I recommend hiring Junior developers who ask questions but passionately agree to fix it. You want those who might not be brilliant, but have enough passion to cover it up and also learn quickly. Like a sponge that soaks up teachings.

Now there might be parts that could be done better/fixed. Ask how the candidate wants to remedy this. Does the candidate want to fix it given the time? Again don’t put too much weight on this. If they say they want to fix it, give them time to send it in later - don’t let them fix it on the spot. Remember, no-pressure interview.

Also if the candidate doesn’t feel inspired to fix it, don’t take that as a dinger! Maybe the candidate is sick of doing coding projects because this is their 10th one. You must try to grab the big picture here.

3. And while candidate is answering the questions, ask behavioral questions as well

I have no qualms with behavior questions but you gotta stop asking ones that people memorize.

Rather here’re some questions I learned from my ex-CTO to pry them open:

Ask what they are freaking passionate about. Not just programming - but like anything in general. Start from there.

You want something that lights their eyes up. Even introverts who are generally shy (looking at myself) generally light up when they get a chance to talk about something super cool.

So chat them about that, and THEN gently guide the question to some project they worked on that was off-the-shelf, blockbuster-cool for them.

Ask why they did it. What were some obstacles along the way? How they resolve it?

Reason is, you can’t expect projects to be successful in one try. Generally it requires grit. The world doesn’t want that project to succeed, there are time commitments, there’s life happening, but this candidate, this pirate, decided screw that and did something.

That shows action. Passion. I find that awesome, and it’s something that resonates with your heart. You gotta be moved. And your gut should tell you there’s something there.

Ask them about their dream work environment

This one is pretty important because it tells you what kind of a personality/requirement the candidate needs.

This is multi-faceted, which includes traits involving:

• office layout: open office (I HATE THIS), cubicle, small rooms
• team size: 3, 6, 10?
• team culture: friendly? calm? active? chaotic?
• hierarchy: flat? some layer?
• feature work process: how they prefer work to be handed to them? This involves sales/marketing/C-level/PM/PO/UX teams, how they prefer interacting with them

This depends on the company. If you are small, you want generalists who are open for cooperation. Bigger companies, that probably doesn’t matter and they are okay with people who don’t want to interact with non-tech people.

However, it’s always safe to hire candidates who are friendly with non-tech team members, and generally like that. If they prefer to be independent of interaction with non-tech team members, they might be disguised brilliant assholes, and you don’t want too much of that.

Generally you want people who are friendly to everyone, who are humble and who would like to help people who are in need. Interacting with business team members can bring insight which often gets lost during the feature ceremonies / formal work handoffs - but getting your ear to the ground allows the developer to gain the clearer intent of why features are being built.

This ends up making the candidates to stick around longer, I think. I mean I would like to work on things that matter, and unless I know the why, I often end up questioning the feature request. So I tend to ask a lot of questions and try to understand the reason behind feature requests.

To err on the side of asking the reasons instead of blinded acceptance is, I believe, a key trait for any good candidate, especially more for junior developers. Humble curiosity leads to rapid growth, imho.

Whew! That covers the “how” of hiring junior developers!

It’s been quite long, and thank you for reading. Hopefully this dispelled some of the misunderstandings / false beliefs on the current “normal” way of doing technical interviews.

Big companies (though not FAANG level big) have changed recently on how they interview. Some companies got rid of live coding challenges in favor of take-home projects. Some have started asking actual business-problem oriented live coding challenges, which are better at least than some arbitrary algorithm challenges, and gives the candidate an environment as if they are working in a team.

Hopefully more and more SMB level tech shops can adopt a more nuanced approach to technical interviews, and therefore give more chance to junior developers while doing so.

If you have any input or opinion - because above is mostly through my experience - please shoot me at email! Address is at the [Contact](https://www.coramsoftware.com/contact/ “Contact”) page ;)