3 ms·

I do think it’s inherently unfair that high-paying jobs are placed behind arbitrary leetcode gates. Dedicating time because you’re passionate is great, but I’m

I do think it’s inherently unfair that high-paying jobs are placed behind arbitrary leetcode gates. Dedicating time because you’re passionate is great, but I’m not here to feed your hobby. My experience is that people who dedicate lots of time to development outside of work burn out around the senior engineer level because they never get to use the cool techniques they play with on their own time. Most development jobs require very little CS theory or hobby projects to do the actual work. Most of what software engineers build are glorified CRUD apps. What those things tell a prospective employer is that you’re willing and able to grind yourself to the bone. Case in point: I’ve been hiring people from local minority jobs programs for entry level dev roles. Yes they’re green as heck (usually just a coding bootcamp) and we have to handhold them for a few months, but it gives mentorship opportunities to our mid-level devs and after 6 months of project work you’d be hard pressed to tell the difference. Not everyone can take a couple years off work to go get an advanced degree. These jobs are not so hard they require one. Credential inflation is out of control, and trying to hyper-optimize individual achievement often ends up building poor teams. Give me someone with good work-life balance and priorities outside work any day.

datavirtue 5y ago
"people who dedicate lots of time to development outside of work burn out around the senior engineer level" Word. I left the industry to sit around my farm and raise my kids for about ten years. When I came back and started working with people I was shocked at how long it takes to learn anything about tech on the job. I was working on my own trying everything while I was away. I noticed that my "senior" co-workers who had been working the previous whole ten years knew far less about the inner workings of the various tech they used daily than I did. I would rattle off something and expect a comment or answer and would repeatedly see architects and lead devs freeze up. I watched as they completely botched implementations simply because they didn't read the manual. The surprises were many because they used the same mental model to understand everything. One implementation with a vendor required socket programming. They snapped and threw up their hands immediately in a big huff. I pointed out that C# had libraries to support that and that it was fairly trivial and probably way more fun than consuming a HTTP API. It took a few of us to calm them down and get it working but the dev who was assigned to it continued bitching. They were incensed at having to program against a TCP stream. It was so easy and trivial (imagine a binary string the size of an encoded JWT). He fucked it up bad and blamed the network for weeks. In another instance, they were having trouble selecting a protocol for an external message passing framework. After selecting one at random I started asking about the protocol, mentioning that it sounded like it was based on "remoting (RMI binary non-routable transport). They had no idea. That concept of not having any idea about the underlying libraries and tech they selected was spread across an entire project, causing many real life disasters. This all worked out great for me because I got use my deep knowledge a lot to identify root causes and fix thier messes which led to mahoosive salary increases and bonuses. These bros were trying to leetcode everyone they hired. I couldn't do fizzbuzz to save my life. Just not interested in it. Is leetcode a filter to make sure you can work on the same old boring shit without losing it?
- Tyr42 5y ago
  >I couldn't do fizzbuzz to save my life I don't understand. You clearly could take a spec "output numbers ..." and turn it into code, as you can take more complicated specs and code against them no problem. If asked in an interview "Why should we use jitter when doing exponential backoff when packets fail", is that a more interesting question? Is it the blank editor with no compiler/docs which makes it hard to write code, or the interview stress of someone watching? How would you try and separate out the best of your co-workers from the rest in a day or two?
  - wayoutthere 5y ago
    I would submit that humans cannot easily be ranked from “best” to “worst”; and even the most genuine attempts at doing so will only capture it for a moment in time as both the individuals’ skills and the business’ needs are constantly in flux. And yeah, I feel you can adequately gauge someone’s skill level across a technical subject area in 4 or 5 simple “how would you” questions. The way they explain it will tell you a lot about their understanding of the subject matter. In the old days (when we were in-person and I was still a technical SME) I would have them use a whiteboard to explain a technical concept to me. This job is not that hard. I think a lot of companies have an overly fond view of themselves and most of these complex interview processes are for their own ego.

datavirtue 5y ago

"people who dedicate lots of time to development outside of work burn out around the senior engineer level" Word. I left the industry to sit around my farm and raise my kids for about ten years. When I came back and started working with people I was shocked at how long it takes to learn anything about tech on the job. I was working on my own trying everything while I was away. I noticed that my "senior" co-workers who had been working the previous whole ten years knew far less about the inner workings of the various tech they used daily than I did. I would rattle off something and expect a comment or answer and would repeatedly see architects and lead devs freeze up. I watched as they completely botched implementations simply because they didn't read the manual. The surprises were many because they used the same mental model to understand everything. One implementation with a vendor required socket programming. They snapped and threw up their hands immediately in a big huff. I pointed out that C# had libraries to support that and that it was fairly trivial and probably way more fun than consuming a HTTP API. It took a few of us to calm them down and get it working but the dev who was assigned to it continued bitching. They were incensed at having to program against a TCP stream. It was so easy and trivial (imagine a binary string the size of an encoded JWT). He fucked it up bad and blamed the network for weeks. In another instance, they were having trouble selecting a protocol for an external message passing framework. After selecting one at random I started asking about the protocol, mentioning that it sounded like it was based on "remoting (RMI binary non-routable transport). They had no idea. That concept of not having any idea about the underlying libraries and tech they selected was spread across an entire project, causing many real life disasters. This all worked out great for me because I got use my deep knowledge a lot to identify root causes and fix thier messes which led to mahoosive salary increases and bonuses. These bros were trying to leetcode everyone they hired. I couldn't do fizzbuzz to save my life. Just not interested in it. Is leetcode a filter to make sure you can work on the same old boring shit without losing it?

Tyr42 5y ago
>I couldn't do fizzbuzz to save my life I don't understand. You clearly could take a spec "output numbers ..." and turn it into code, as you can take more complicated specs and code against them no problem. If asked in an interview "Why should we use jitter when doing exponential backoff when packets fail", is that a more interesting question? Is it the blank editor with no compiler/docs which makes it hard to write code, or the interview stress of someone watching? How would you try and separate out the best of your co-workers from the rest in a day or two?
- wayoutthere 5y ago
  I would submit that humans cannot easily be ranked from “best” to “worst”; and even the most genuine attempts at doing so will only capture it for a moment in time as both the individuals’ skills and the business’ needs are constantly in flux. And yeah, I feel you can adequately gauge someone’s skill level across a technical subject area in 4 or 5 simple “how would you” questions. The way they explain it will tell you a lot about their understanding of the subject matter. In the old days (when we were in-person and I was still a technical SME) I would have them use a whiteboard to explain a technical concept to me. This job is not that hard. I think a lot of companies have an overly fond view of themselves and most of these complex interview processes are for their own ego.