| From my perspective, the tech hiring process is still mostly broken and cold hearted. I don't think hiring companies are specifically discriminating against older developers though. I think its just difficult to leave the candidate feeling respected after passing. I'm not 100%, but I imagine the reason the author was passed on probably had more to do with other things than being senior. You'd have to be stupid to pass on a solid developer that was a good fit just because of age or (reasonable) salary requirements for being senior. That's not how a company wins. Recently, we hired several new developers which I lead the effort on. I had (mostly) free rein on hiring so I set out to fix things I felt were broken based on my experience as a candidate in the past. Following are my major complaints I have about the tech interview process. * Most coding exercises I've been giving were mostly impractical BS.
* Coding exercises are often used as an easy scapegoat rather than a true measure of skill.
* There were several instances where I thought the coding exercise was in place solely for the interviewer to demonstrate their wit. In one case, after embarrassingly fumbling on the whiteboard for 30 mins trying to explain an advanced dynamic programming algorithm that I threw together, I watched as the interviewer smugly walked through the answer seemingly to showoff how much smarter he was. He had clearly spent hours practicing and rehearsing the answer.
* Companies mostly fail at giving respectful reasons for passing on the candidate.
* Companies focus too much on specific technologies and stacks vs capability to ramp up.
* Good fit is underrated. I would much rather have a mostly capable developer that has a positive can-do attitude than a poisonous genius.
* A college degree is an accomplishment. There are other ways to reach your goals and achieve competency. I have a masters in software engineering. I know of 1 or 2 other developers at least that only have high school degrees that were as capable as me maybe even more. We are finished with our hiring process and I like to think it was somewhat better than my past experience. We split every interview up into 3 parts. 1) 30 minute phone intro
2) Untimed take home programming exercise because nobody develops well like this https://cdn-static.denofgeek.com/sites/denofgeek/files/2/95/...
3) 1 hour follow to programming exercise (must explain submission in detail) Here are my takeaways from our process and how we tried to rethink the process. * Its actually hard to properly follow up with every single candidate with reasons you are passing. Doing it in a timely and respectful manor is also hard. I wish I had done a better job at this.
* The coding exercise we provided was practical and gave us everything we needed to know about the candidate programming level.
* The exercise was provided via github. It had 3 steps, each of which built on top of the previous, simple, medium, harder.
* After the exercise the candidate was asked to explain the exercise back to us as if we had no prior knowledge and were not techies. Then explain the technical implementation.
* Write at least 1 test case for each step because our actual code is heavily tested.
* We gave the candidate at least a full 24 hours to complete and could request more if needed. Its more important to get the answer right than to rush it. People work at different paces. I'm personally a slow developer because I like to take my time thinking through everything. I like to think I usually get it right at the end of the day. That's how we write software, correct is better than rushed.
* We valued curiosity and honesty. We devalued nudging experience. Admit when you don't know something. It probably won't majorly count against you unless its core to our project.
* Consistent clean code that is readable is very important. |
