I kind of wonder if we’re overthinking technical interviews at some level, perhaps out of some sense of value that we don’t actually have.
Let’s assume that your company doesn’t need to hire John Carmack or Linus Torvalds–let’s assume that like 99.9% of companies the software work is boring integration work or tame line-of-business stuff. In that case, the business side of the house views a developer as:
Somebody who is probably only grudgingly required.
Somebody who isn’t really going to take ownership in the company in any meaningful way.
Somebody who is going to push the product/features ahead further/faster.
Somebody who won’t actively decrease company cohesion.
Somebody that does the above while being as cheap to employ as reasonable.
That’s literally it. It doesn’t matter if they’re a good developer if they ship product. It doesn’t matter if they scramble extra hours if they do so at their existing salary cleaning up the messes they’ve made. It doesn’t matter if they read the same blogs and go to the same conferences as the other engineering hires.
If we just hired people with the mindset that they need to meet those needs, and give them the education required on the job to do so, interviewing would be a lot faster–“Can you fog up this mirror? Do you want to make rent this month? Can you demonstrate a basic grasp of dividing a task into component tasks? Great, here’s a contract and a gratis copy of ‘Teach Yourself Javascript in 24 hrs’, come back Monday if you’re interested.”
Side effects (good and bad) of such an approach I expect would be:
Increased diversity in employee demographics
Decreased costs to business–many fewer expensive engineers!
Larger and messier codebases
Simpler problems in the codebases–if for no other reason than the developers are now of a lower skill and can’t do “clever” things as often
Slower development of interesting technologies–fewer intelligent engineers burning VC money to learn about monads in the DOM
Faster interviewing process
Increased ability gap between senior and non-senior engineers
I kind of think the place I work does this. I don’t think they do it purposely, though, it just sort of happens. We have a lot of devs. I’m talking like nearly 10k spread across the company. I’m not sure if that number includes contractors or not – if it doesn’t, we’re talking probably close to double that, and if it does, we’re at about 5k salaried devs.
We do have a few different lines of business, it’s not like all 10k are working on one app, but there are a lot of people on one app. So many that it’s pretty much impossible getting people on the same page. We have these daily meetings that are meant to get our 38 teams (seriously) together and bring up any issues or developments that will impact some of those teams. In reality, only a handful of people ever speak up. Most people just show up for attendance to say they were there.
They promote people up to more senior levels, but their qualities are not senior. As far as code goes, it’s a total crapshoot. Some people can do a couple things, but most people require hand-holding of some sort (and some can’t do anything on their own at all – demanding “pair programming” where they basically have you do the work or just copy/pasting code in and asking you to fix it when it inevitably doesn’t work).
The company is very profitable, but not because of our software. And really, the software doesn’t make them money, it’s just a necessity that people be able to use this software at this point. In that sense, I understand why they’ll hire just anyone.
I can’t help but thinking that the same (and more) could be done with a fraction of good devs, though. I’ve worked on tiny teams, small teams, medium sized teams, and now this monstrosity of an über-team, and I’ve observed the larger the team, the less work comes out, the more time wasted going over the same old thing every week, the more time spent trying to “align” everyone. Is it really worth having so many bad-to-mediocre devs? It seems like the time spent weeding out folks who cannot communicate, who don’t know how to write a for loop, who don’t know what environment variables are, etc would be better in the long run rather than having these same meetings over and over and getting next to nothing done.
I’ve never seen a company go from idea to production slower than here. There is no iteration, there is only spinning wheels. Most of that is due to the inefficiencies created by having so many completely unqualified devs, IMO.
Not only do companies doing the interviewing need to change the process, I think developers looking for jobs should start refusing to go through the whole whiteboard trivia nonsense. If that reached critical mass, companies would change their interview process real quick.
How many job seekers really want to reject an opportunity over something annoying? When the bills are due and you need health insurance, that’s a rather bold move.
I could only see people with big amounts of savings doing this, and it’d only matter if they were obviously qualified. Otherwise, the recruiting team would shrug and move on, and the job seeker is left wondering if they made a huge mistake. There’s an obvious power dynamic here that can’t be ignored.
That might be true if you’re unemployed and short on options, but often I find people interviewing are already employed and looking to make a change. So for them, saying no just means staying at $CURRENT_JOB a bit longer.
Correct. The solution is to not let yourself get into a situation in which you are unemployed and looking for a job. That is shifting the power dynamic in your favor.
I kind of wonder if we’re overthinking technical interviews at some level, perhaps out of some sense of value that we don’t actually have.
Let’s assume that your company doesn’t need to hire John Carmack or Linus Torvalds–let’s assume that like 99.9% of companies the software work is boring integration work or tame line-of-business stuff. In that case, the business side of the house views a developer as:
That’s literally it. It doesn’t matter if they’re a good developer if they ship product. It doesn’t matter if they scramble extra hours if they do so at their existing salary cleaning up the messes they’ve made. It doesn’t matter if they read the same blogs and go to the same conferences as the other engineering hires.
If we just hired people with the mindset that they need to meet those needs, and give them the education required on the job to do so, interviewing would be a lot faster–“Can you fog up this mirror? Do you want to make rent this month? Can you demonstrate a basic grasp of dividing a task into component tasks? Great, here’s a contract and a gratis copy of ‘Teach Yourself Javascript in 24 hrs’, come back Monday if you’re interested.”
Side effects (good and bad) of such an approach I expect would be:
I kind of think the place I work does this. I don’t think they do it purposely, though, it just sort of happens. We have a lot of devs. I’m talking like nearly 10k spread across the company. I’m not sure if that number includes contractors or not – if it doesn’t, we’re talking probably close to double that, and if it does, we’re at about 5k salaried devs.
We do have a few different lines of business, it’s not like all 10k are working on one app, but there are a lot of people on one app. So many that it’s pretty much impossible getting people on the same page. We have these daily meetings that are meant to get our 38 teams (seriously) together and bring up any issues or developments that will impact some of those teams. In reality, only a handful of people ever speak up. Most people just show up for attendance to say they were there.
They promote people up to more senior levels, but their qualities are not senior. As far as code goes, it’s a total crapshoot. Some people can do a couple things, but most people require hand-holding of some sort (and some can’t do anything on their own at all – demanding “pair programming” where they basically have you do the work or just copy/pasting code in and asking you to fix it when it inevitably doesn’t work).
The company is very profitable, but not because of our software. And really, the software doesn’t make them money, it’s just a necessity that people be able to use this software at this point. In that sense, I understand why they’ll hire just anyone.
I can’t help but thinking that the same (and more) could be done with a fraction of good devs, though. I’ve worked on tiny teams, small teams, medium sized teams, and now this monstrosity of an über-team, and I’ve observed the larger the team, the less work comes out, the more time wasted going over the same old thing every week, the more time spent trying to “align” everyone. Is it really worth having so many bad-to-mediocre devs? It seems like the time spent weeding out folks who cannot communicate, who don’t know how to write a for loop, who don’t know what environment variables are, etc would be better in the long run rather than having these same meetings over and over and getting next to nothing done.
I’ve never seen a company go from idea to production slower than here. There is no iteration, there is only spinning wheels. Most of that is due to the inefficiencies created by having so many completely unqualified devs, IMO.
Wow, what industry do you work in!?
Not only do companies doing the interviewing need to change the process, I think developers looking for jobs should start refusing to go through the whole whiteboard trivia nonsense. If that reached critical mass, companies would change their interview process real quick.
How many job seekers really want to reject an opportunity over something annoying? When the bills are due and you need health insurance, that’s a rather bold move.
I could only see people with big amounts of savings doing this, and it’d only matter if they were obviously qualified. Otherwise, the recruiting team would shrug and move on, and the job seeker is left wondering if they made a huge mistake. There’s an obvious power dynamic here that can’t be ignored.
That might be true if you’re unemployed and short on options, but often I find people interviewing are already employed and looking to make a change. So for them, saying no just means staying at $CURRENT_JOB a bit longer.
Correct. The solution is to not let yourself get into a situation in which you are unemployed and looking for a job. That is shifting the power dynamic in your favor.
I know of one startup in NYC that has an interview process pretty similar to this.
The sentiments and goals expressed in this article are spot-on.
However, the proposed solution - involving many more people in the interview process - is hard to scale.
It would be the same number of people though.