loading words...

Apr 29, 2019 17:57:42

Why do Developer Interviews have to suck?

by @jacklyons PATRON | 522 words | 🐣 | 127💌

Jack Lyons

Current day streak: 0🐣
Total posts: 127💌
Total words: 42165 (168 pages 📄)

One of the biggest things I dislike about being a web developer is going for a job interview. It's a bit of a paradox because I absolutely love chatting with other passionate devs about tech stacks, algorithms and solving problems. However when it comes to interviewing I'm often left feeling deflated and almost disliking the profession.

As a full time freelancer, I still often like to take interviews to practice my skills, get a feeler for what's out there and practice my negotiating skills. I have noticed that the biggest difference between freelance job interviews and those at a company is that with a freelance client I get to dive in deep on how I can make a difference and help them succeed.

On the other hand, software company's usually have a rigorous process where they first screen you, then send you a take-home challenge, then they dissect your code and grill you on all sorts of silly and irrelevant questions about a programming language. I feel like their aim in those hardcore technical interviews is to make you look dumb and trip you up on a touch question. If they succeed, then they certainly do have a better chance at lowballing you when they make an offer.

In my experience, most of the time you don't even get to talk about what they actually need from you; they just want you know all the best languages and tell you that you'll be solving "complex problems". This kind of vagueness is really a shame because it sucks the love out of the profession for me.

A lot of it comes down to incompetent recruiters not knowing what they are talking about, but it also just comes from this old-school corporate mentality where only the coding wizards who live and breath code will succeed.

I want to see interviewers take a more engaging approach where they explain what you will be doing and how you can help them to better improve their company. This needs to be backed up with practical examples of their codebase and tailored take-home projects that make sense to their exact software. So many job ad's out there are incredibly misleading.

They say they want to use the latest tech and that you'll be working on modern stuff, but a lot of the times they just write that to lure in a larger pool of applicants. Company's can vary in size and while one small department might use something cutting edge, that doesn't mean you'll be put there, which likely means you'll be in the trenches debugging legacy code that sucks to work with.

So, I'm sorry this post turned into a rant without any proper tips or tricks. I'll probably revisit this topic with greater depth at some stage. But the basic premise for anyone interviewing for a tech job is to ask a TON of questions and really drill down into what your day-to-day work will look like. 

If you have had a similar experience, or even something completely opposite, or any tips and tricks to share with others, please feel free to leave a commend below!

From Jack Lyons's collection:



contact: email - twitter / Terms / Privacy