4 ms·

I've been writing code for 30 years, invented three algorithms, have managed engineering teams and been trusted with half-million-dollar tech budgets, but becau

by trhr 4y ago

I've been writing code for 30 years, invented three algorithms, have managed engineering teams and been trusted with half-million-dollar tech budgets, but because I don't have a C.S. degree, I rarely get into a final round. Maybe changing the expectation that good developers must excel at LeetCode is a place to start fixing the shortage that causes this problem in the first place. I excel at perceiving contexts and understanding when to change approaches, but since you can't test that in a tech screen, it's basically a worthless skill to have.

vecter 4y ago
You sound like you have a really valuable experience and skillset. In your opinion, how would you go about technical interviewing in a way that makes sense?
- le-mark 4y ago
  Have a conversation with someone who can recognize the experience, and not be threatened by it. Look for the candidate to tell war stories about technical challenges, leadership challenges, interpersonal challenges and how they solved them and what they learned. Read their resume and recognize multiple stints of increasing responsibility at quality companies means something.
- ChrisMarshallNY 4y ago
  I can: A) Relate to the GP, and B) Answer the question For (B), my experience was that LeetCode was worthless, as I was looking for a senior-level engineer, to come into an established team, and start being a contributor, ASAP. I spent 25 years, hiring experienced coders, and ran an established team, that was part of a much larger, established organization. Headcount was really difficult for me to get, and the company was cheap. They were a huge name, and assumed that everyone was fighting to join the company. If you were a photographer, that was the case. If you were a programmer, that was definitely not the case. So I had a challenge. I suspect that the low-end salary chased away most people that were only looking to hop onto a short-term, salary multiplier gig. Pretty much everyone that I interviewed was serious about getting involved in some extremely interesting work (C++ image processing pipeline development). I got folks to talk about their passions and projects. The best way to figure out how folks work, is to ask them to wax eloquent on problems they've solved, and projects they wrote. I would have killed for large GitHub portfolios. I loved long résumés, and would definitely have spent a lot of time, reviewing them, if they were offered. I think I basically made good choices. There was never a technical misfit. In a couple of cases, the person couldn't integrate too well into the team. I had a very relaxed environment, and each team member had their own proclivities and workflow. We made it work; I suspect the fact that they all had decades of experience, helped. I kept people on board for decades (not an exaggeration). Remember I said that headcount was such a bitch to get? That was a big reason for me wanting to keep people. Also, the Japanese team would barely acknowledge their existence, until they had been at the company for at least a year. In my experience, someone who is good at interview tech questions, is good at interview tech questions, but that does not give me any clue, as to how they will be, when they hit some of the rather hairy (often threaded) algorithms we had. I had to take risks. If an employee did not work out for at least a couple of years, I got grief. So I got highly competent, experienced C++ engineers to join, for low-ish salaries, and I kept them, for many years. I guess that's not a valuable skill, in managers, anymore. I think I did OK. [UPDATE] I made it more about me, to try to make the comment a bit less abrasive.
  - comfypotato 4y ago
    It’s ridiculous to say that the go to hiring strategy for most of the highest paid positions in the world is useless. The only trend I see that I agree with from leetcode dissenters is that it doesn’t make sense when you have issues maintaining headcount. I’m a newb, and I definitely have no experience hiring, but it doesn’t take ANY intelligence to know that leetcode makes sense when you have a long list of halfway decent applicants. Whether or not it’s ethical. I don’t know. Having to take the time to practice for an interview is going to select privileged folks.
    - ChrisMarshallNY 4y ago
      > It’s ridiculous to say that the go to hiring strategy for most of the highest paid positions in the world is useless. Hey, be nice. I was talking about my experience, in my career, which was fairly unique. I managed to make some very picky people fairly happy, for a long, long time.
      - comfypotato 4y ago
        Need to work on my writing. Was annoyed at your leetcode dissentism and and wasn’t able to contain the annoyance. My b, dog. Hope to have a similarly long and satisfying career.
    - trhr 4y ago
      > leetcode makes sense when you have a long list of halfway decent applicants It lets you build a team of people who are good at leetcode, but I won't be on that team. Which is a shame, because my t-shape is wider and deeper than most engineers. I just can't solve fake problems about how many ways there are to combine a string quickly. Why isn't there a refactoring section of the tech screen? Hand me 5,000 lines of garbage code and let me figure out what it does, why it does it, and how we can improve it. Those are the kinds of problems I actually have practice solving.
      - comfypotato 4y ago
- trhr 4y ago
  Interviewing is outside my skill set, so take this with a grain of salt, as it's just the sort of question I'd like to answer: "We have an application that needs to run inside a vehicle, which means the power will be killed at regular, but unpredictable, intervals. How would you design this to ensure data integrity?" It's weird enough that few people will have solved it before, but it can be solved at every layer between circuit and application, so you can actively brainstorm with the candidate to draw out some of their solutions into more detail. And if they start with, "well, I'd build a react app," you can go straight into the trash can with their resume, because you can have that whole discussion without deciding on so much as a language, much less a framework, so you can see who jumps too hastily to wrong assumptions.
  - codeisawesome 4y ago
    (Parent comment did mention the grain of salt, so my response below is to the spirit of the comment itself and not directed at the person). > And if they start with, "well, I'd build a react app," you can go straight into the trash can with their resume, because you can have that whole discussion without deciding on so much as a language, much less a framework, so you can see who jumps too hastily to wrong assumptions. So you would reject someone based on the first thing they say? That’s called prejudice - maybe they don’t have the systems programming lingo in place to describe the ideas you are looking for, but might actually have some ideas trending in the right direction given some nudging. Also, that sounds like you gave a systems programming problem to someone who may have specialised in react the last two years - did you read their resume? Seeing how complex this discussion gets every time on what is the “right” way to interview and how biased people can get (things haven’t changed in a generation - it used to be about picking the wrong Java library I heard) - no wonder Leetcode has emerged as a “fair” standard-bar that everyone in computing has an actual shot at clearing. That said, Leetcode-style does bias towards people who have time, resources, and not many responsibilities, especially with problems trending to ever more esoteric algorithms. I don’t know the solution.
    - trhr 4y ago
      I perhaps explained poorly in two cases: I'd knock serious points for anyone who mentioned any languages (except in the context of talking about low-level features of that language that would help solve the problem), and I don't see it as "systems programming" because it absolutely could be answered at the application level. It could also be solved with a battery pack (systems level) or immutable storage (hardware level), to name a couple others. The point is giving folks an opportunity to talk in the areas of their experience, and the strongest devs have taken a break from VSCode to do other stuff which adds value to solving problems holistically.

by trhr 4y ago

vecter 4y ago

You sound like you have a really valuable experience and skillset. In your opinion, how would you go about technical interviewing in a way that makes sense?

le-mark 4y ago
Have a conversation with someone who can recognize the experience, and not be threatened by it. Look for the candidate to tell war stories about technical challenges, leadership challenges, interpersonal challenges and how they solved them and what they learned. Read their resume and recognize multiple stints of increasing responsibility at quality companies means something.
ChrisMarshallNY 4y ago
I can: A) Relate to the GP, and B) Answer the question For (B), my experience was that LeetCode was worthless, as I was looking for a senior-level engineer, to come into an established team, and start being a contributor, ASAP. I spent 25 years, hiring experienced coders, and ran an established team, that was part of a much larger, established organization. Headcount was really difficult for me to get, and the company was cheap. They were a huge name, and assumed that everyone was fighting to join the company. If you were a photographer, that was the case. If you were a programmer, that was definitely not the case. So I had a challenge. I suspect that the low-end salary chased away most people that were only looking to hop onto a short-term, salary multiplier gig. Pretty much everyone that I interviewed was serious about getting involved in some extremely interesting work (C++ image processing pipeline development). I got folks to talk about their passions and projects. The best way to figure out how folks work, is to ask them to wax eloquent on problems they've solved, and projects they wrote. I would have killed for large GitHub portfolios. I loved long résumés, and would definitely have spent a lot of time, reviewing them, if they were offered. I think I basically made good choices. There was never a technical misfit. In a couple of cases, the person couldn't integrate too well into the team. I had a very relaxed environment, and each team member had their own proclivities and workflow. We made it work; I suspect the fact that they all had decades of experience, helped. I kept people on board for decades (not an exaggeration). Remember I said that headcount was such a bitch to get? That was a big reason for me wanting to keep people. Also, the Japanese team would barely acknowledge their existence, until they had been at the company for at least a year. In my experience, someone who is good at interview tech questions, is good at interview tech questions, but that does not give me any clue, as to how they will be, when they hit some of the rather hairy (often threaded) algorithms we had. I had to take risks. If an employee did not work out for at least a couple of years, I got grief. So I got highly competent, experienced C++ engineers to join, for low-ish salaries, and I kept them, for many years. I guess that's not a valuable skill, in managers, anymore. I think I did OK. [UPDATE] I made it more about me, to try to make the comment a bit less abrasive.
- comfypotato 4y ago
  It’s ridiculous to say that the go to hiring strategy for most of the highest paid positions in the world is useless. The only trend I see that I agree with from leetcode dissenters is that it doesn’t make sense when you have issues maintaining headcount. I’m a newb, and I definitely have no experience hiring, but it doesn’t take ANY intelligence to know that leetcode makes sense when you have a long list of halfway decent applicants. Whether or not it’s ethical. I don’t know. Having to take the time to practice for an interview is going to select privileged folks.
  - ChrisMarshallNY 4y ago
    > It’s ridiculous to say that the go to hiring strategy for most of the highest paid positions in the world is useless. Hey, be nice. I was talking about my experience, in my career, which was fairly unique. I managed to make some very picky people fairly happy, for a long, long time.
    - comfypotato 4y ago
      Need to work on my writing. Was annoyed at your leetcode dissentism and and wasn’t able to contain the annoyance. My b, dog. Hope to have a similarly long and satisfying career.
  - trhr 4y ago
    > leetcode makes sense when you have a long list of halfway decent applicants It lets you build a team of people who are good at leetcode, but I won't be on that team. Which is a shame, because my t-shape is wider and deeper than most engineers. I just can't solve fake problems about how many ways there are to combine a string quickly. Why isn't there a refactoring section of the tech screen? Hand me 5,000 lines of garbage code and let me figure out what it does, why it does it, and how we can improve it. Those are the kinds of problems I actually have practice solving.
    - comfypotato 4y ago
trhr 4y ago
Interviewing is outside my skill set, so take this with a grain of salt, as it's just the sort of question I'd like to answer: "We have an application that needs to run inside a vehicle, which means the power will be killed at regular, but unpredictable, intervals. How would you design this to ensure data integrity?" It's weird enough that few people will have solved it before, but it can be solved at every layer between circuit and application, so you can actively brainstorm with the candidate to draw out some of their solutions into more detail. And if they start with, "well, I'd build a react app," you can go straight into the trash can with their resume, because you can have that whole discussion without deciding on so much as a language, much less a framework, so you can see who jumps too hastily to wrong assumptions.
- codeisawesome 4y ago
  (Parent comment did mention the grain of salt, so my response below is to the spirit of the comment itself and not directed at the person). > And if they start with, "well, I'd build a react app," you can go straight into the trash can with their resume, because you can have that whole discussion without deciding on so much as a language, much less a framework, so you can see who jumps too hastily to wrong assumptions. So you would reject someone based on the first thing they say? That’s called prejudice - maybe they don’t have the systems programming lingo in place to describe the ideas you are looking for, but might actually have some ideas trending in the right direction given some nudging. Also, that sounds like you gave a systems programming problem to someone who may have specialised in react the last two years - did you read their resume? Seeing how complex this discussion gets every time on what is the “right” way to interview and how biased people can get (things haven’t changed in a generation - it used to be about picking the wrong Java library I heard) - no wonder Leetcode has emerged as a “fair” standard-bar that everyone in computing has an actual shot at clearing. That said, Leetcode-style does bias towards people who have time, resources, and not many responsibilities, especially with problems trending to ever more esoteric algorithms. I don’t know the solution.
  - trhr 4y ago
    I perhaps explained poorly in two cases: I'd knock serious points for anyone who mentioned any languages (except in the context of talking about low-level features of that language that would help solve the problem), and I don't see it as "systems programming" because it absolutely could be answered at the application level. It could also be solved with a battery pack (systems level) or immutable storage (hardware level), to name a couple others. The point is giving folks an opportunity to talk in the areas of their experience, and the strongest devs have taken a break from VSCode to do other stuff which adds value to solving problems holistically.