A great LeetCode ranking doesn’t make you a Software Engineer.
Yet this is how many companies decide who to hire. LeetCode problems.
I’ve been working on a project to get the Rust programming language under my fingers. Something bigger than a ToDo list. Complex enough to force me out of my comfort zone and into true learning mode, but not so complex that it would take years to complete (ummm…maybe).
I was faced with a design problem (I didn’t know it was at the time, but I got there). I was trying to do the programming version of square peg in round hole. I found a lot of resources from people doing what I thought was the right thing, but the code…oh the code. As I looked through examples I saw so much complexity, so many code smells. Code I would have coached my engineers away from, but was in writing from employees of major software companies.
This is when my experience kicked in. I took a step back. There had to be a better, cleaner way to do what I needed. I looked through my digital bookshelf. My mind turned. I now understood that my problem was the design. There was no way to execute on it and feel good about the code.
I searched through several microservices architecture books, confirming my new design assumption. I read documentation within Rust, Axum, and Diesel, the crates I was focused on. I honed in on what I now felt was the right way to handle the situation in front of me. A less experienced me, one that I saw in the blogs and code I had found earlier, would have continued on my original path. Pumping out un-maintainable code.
Knowing how to code any algorithm by hand, from memory, is a fun parlor trick. I do have respect for people who can, and at times wish I could. But I can look up algorithm implementations. Many are in standard libraries. The experienced me is more interested in knowing when to use an algorithm, when the standard library implementation isn’t enough (almost never), or that one even exists (even if I don’t remember what it’s called, I can find it in documentation).
Knowing how to do a thing comes from books and courses. Knowing how to do a thing well (or choosing not to do it at all) is something you learn with experience. Just like the experienced me knows when a design is too complex to support in a production environment.
I hear about large companies with severe vulnerabilities, major bugs, overly complex code bases, and I know they use LeetCode type questions to hire. And while being good at LeetCode doesn’t mean you AREN’T a good software engineer, it also doesn’t mean you are.