I've been a professional developer for a few years now. I've worked on monoliths and micro-services, debugged legacy code and built greenfield projects. For all these different projects, my day-to-day has looked similar:
- I break down the problem with team members and stakeholders
- I work on the problem using my IDE of choice that I've configured to my liking
- When I run into issues, I turn to:
- My team members
- StackOverlow
- Gophers Slack
- I often use other people's code as a template or a starting point (even if it's just my past code)
- When appropriate, I import 3rd party libraries so I don't re-invent the wheel
As a back-end developer, these problems almost always relate to the following technologies:
- Servers (REST, gRPC)
- Databases (SQL, MongoDB, DynamoDB)
- Data Streams (Kafka, AWS Kinesis, RabbitMQ)
So when I interview for a back-end developer position, why are technical assessments often:
- closed book tests (no Google, etc.)
- based on data structures and algorithms
- using contrived problems
- using something other than my own text editor or IDE
Why would companies assess my technical skills with data structure and algorithim questions when the job is about databases and severs? It seems like misplaced priorities. To see what I mean, here's a chart showing how long various events would take if we said a CPU cycle takes 1 second and scaled from there.
Internet calls take much, much longer than operations using the CPU and main memory. Given that, why would companies focus on how well I optimize for "second" and "minute" operations and not for the operations that take "years"?
The answers to these questions vary. Some companies want to follow FAANG's example. Others aren't giving themselves the time to create and maintain a quality technical interview.
I've decided that I won't entertain interviews that use these kinds of assessments.
The questions in this post show a mismatch between the skills LeetCode assesses me for and the skills I'd be doing at the job.
I prefer doing deeper dives into Golang, SQL, DynamoDB, Kafka, and design patterns for distributed systems. I hone those skills because those will provide the most value for companies I work with.
This is risky. I reject a lot interviews as a result of this decision. I decrease my chances of getting a new job. But I've rarely met developers who like these kinds of assessments or think studying for them is a good use of their time. Most people study LeetCode because they have to, because need a job and most jobs have this as an obstacle.
It's past time that we as an industry ask ourselves why we are using these kinds of technical assessments.
If you disagree with me, why do you think LeetCode style assessments are valuable, useful, etc.?
If you agree, what would be a better alternative? My suggestion would be to follow Laurie Barth's guide for Designing a Technical Interview
Top comments (8)
Fully appreciate it.
LeetCode interviews is not represent how candidate in technologies and application architecture.
Yeah, you able to add more tech interview steps, but it is take time of your developers, that not free, and distracts them from their work.
Given that a newly hired developer will be working with your developers for at least a year or two, is that investment of extra time and energy in the hiring process worth it?
Given how much it costs to hire and fire an employee, given how much time can be wasted training someone who ends up not being a good fit, I believe it's worth the effort and time.
In the vast majority of companies that use LeetCode that I met the average duration of employment of employees is less than a year, because most of the processes in the company are "dry", and management is simply trying to put the interview process on an assembly line. And plus my observations are that people who are crazy about algorithms, rather than tasks that are meaningful from a practical point of view in the majority are prone to toxicity, and such people only exacerbate the situation in the team, and have a negative impact on people's satisfaction with their work.
Would it be fair to say then that, from your point of view, requiring LeetCode style interviews is a red flag?
You know, I was talking to some manufacturing engineers a couple of weeks ago and they said they found it ridiculous that developers have to PROVE they're developers regardless of a degree and experience. Then they started making fun of the process.
That's the point where we're at. Industrial engineers mocking us. This is karma. I would make fun of my industrial engineer friends and now I'm paying the price cries in spanish
--
Anyway, I think these challenges were added to the interview process to filter out liars though I believe that a simple fizzbuzz would help with that. Nothing too mayor you know? But, I don't know how we even got to this point and I'm sure that's where we'll find our answers hahaha
Can relate, I force myself to study a leetcode program(I think some weeks in a row) and I just can't keep it. Because doing a side project that solves real life problems is more meaningful to me the emptiness of completing a leetcode wont say nothing about the capacity of an dev to deliver, being a team player, solves real life problems.
But that's the rules of the game we're playing and I understand they need to protect their investment before paying the checks.
If LeetCode is a kind of modern crossword puzzle (the cryptic variety) then I like it for that, it makes me try to understand and solve complex problems that use contrived and complicated constructs. But I wouldn't use it to hire many, if any, developer positions - the same way as newspapers and news sites recruiting journalists don't make them solve crossword puzzles to get the job. These problems use the same principles and the same language as the day job, but they aren't the day job.
I agree! They are definitely fun, especially when divorced from the context of hiring. I also love the metaphor. I hope you don't mind if I steal it. All my metaphors have related to video games.