6 ms·

No doubt, the number of interviewing antipatterns out there is nuts. Leetcode games, hiring by committee, and a market flooded with candidates with resumes that

No doubt, the number of interviewing antipatterns out there is nuts. Leetcode games, hiring by committee, and a market flooded with candidates with resumes that look and read the same. On the flip side, I’m interviewing candidates with a decade of experience (per their resume) that can’t discern the difference between basic data types and how they are stored with the very language they claim expertise. Once upon a time the stereotype was that hiring developers is hard because they can’t communicate. Now candidate after candidate is able to communicate like they are a professional podcaster but they can’t seem to solve problems well. If you’re skilled, don’t despair. Most companies are terrible at hiring and terrible at business as well. Those rejections from the gauntlet of flaming hoops they make your jump through are doing you a favor. Rejection is God’s protection and all that. And I like to think that’s right.

gymbeaux 4y ago
I’ve always been fascinated with the idea that someone can be a software developer for 5, 10, 20 years and bomb in interviews, and I’ve always wondered if they really don’t know these things, or if it’s just the environment- like in my experience I can wax and wax and wax in a non-interview setting, but in an interview setting, even from the comfort of my home office, I seem to block out- not forget, because in the moment I know I know something- parts of my knowledge. You might say “well you should practice interview more” or something to that effect, but I have to wonder, if so many developers seem to “know nothing” despite their supposed experience, perhaps it’s not that they “know nothing”. On my LinkedIn I have the following: what I currently get paid by my current employer (!!!), what I am looking for in my next role, both regularly ignored by recruiters of course, and then I have links to my StackOverflow, Medium and Github profiles, any of which ought to demonstrate my “expertise” as well or better than an interview ever could. Heck if you just read some of my answers to StackOverflow questions, I think you’d see I am capable of writing code for your company…
- chasd00 4y ago
  > I’ve always been fascinated with the idea that someone can be a software developer for 5, 10, 20 years and bomb in interviews i cant remember who said it but many people with 10 years experience really have 1 year of experience and 9 years performing tasks doing the same thing over and over.
  - achempion 4y ago
    The phrase is catchy but a bit too harsh. First of all, software frameworks and technology evolve. Second, it's pretty hard to find someone who worked for 10 years at the same company with the same software project doing CRUD actions. On the other side, if you meet linux kernel engineer who maintained kernel for the past 10 yers, this argument fails short. Same for someone who worked on Postgres internals.
  - jjav 4y ago
    > and 9 years performing tasks doing the same thing over and over. I mean that's what experience is. If I want an expert in x, I want someone who has being doing x for ten years. I don't want someone who has dabbled in ten different things in ten years, thus having very superficial exposure to ten things and expertise in nothing. If I need a heart surgeon, I want the doctor who has been doing only heart surgeries for a couple decades. That's an expert. I certainly don't want some doctor who has been switching from heart surgery to podiatry to dentistry and on and on without specializing in anything.
- re-thc 4y ago
  Most people aren't this consistent. At work does someone say that I will watch you code in a particular time of the day and you will be able to perform on a random question that's useless? No. Interviews have 0 context that's needed for anyone to perform. Usually you can't use your IDE, your settings or your ways of working and you've never paired up with the interviewer so might not feel comfortable. To make matters worse the interview topic is 90% chance not what you do on a day-to-day basis. No 1 is answering leet code questions at work. We're going to be using a library or tool and not to try write an analytics algorithm.
  - ryandrake 4y ago
    Another harsh reality is that for most jobs, the initial interview is by far the hardest part of the job. Once you pass it, the rest is cake. It takes a lot less effort and brainpower to keep a job than it does to get it. I still look back to a FAANG interview a decade ago being the most difficult thing I've ever done in my life, and I've worked my way up from a shit mining town to the middle class, developed a complete complex software product starting from an empty text file, gotten an advanced degree, built a single engine airplane, and managed to stay married for 20 years. But out of all that, a stupid FAANG interview was the most difficult. It's just ridiculous what companies put people through.
- 2muchcoffeeman 4y ago
  I've bombed interviews numerous times only for the answers to come to me when the interview is over. My best outcomes are when I am relaxed (already have a job ;)) and I've gone through some basic material and whipped up some example programs. I've never had a problem in a real world setting or writing code.
  - cloverich 4y ago
    Its just so different talking while being judged by people you dont know, throws things off. I bombed a few last time, one in particular where I was writing a switch statement. They wanted me to use a map. They asked what if the cases kept growing and... it didnt occur to me to use a map. Im sure i looked like a novice. But in my day to day code... i flip between maps and conditionals and switch statements all the time, with ease. Its natural. But while interviewing? It just doesn't come out of me.
    - the_only_law 4y ago
      It’s weird because at the end of the day, it shouldn’t matter. I’m about to interview for a job two states away. If I fail, well I fail. The worst outcome is status quo, but I’m still terrified of looking like an idiot tomorrow.
mattmanser 4y ago
There are developers great at solving business problems, which is what the vast majority of companies actually want. And there are developers who say things like "[other programmers] can’t discern the difference between basic data types and how they are stored with the very language they claim expertise" That's not the actual job we do. Unless you happen to write libraries or crazy high performance code. Most of the time it doesn't actually matter how the data is stored in the language, it actually matters how it's stored in the DB. Because that's where the performance problems are. Most of us don't even have to remember that, even if we ever learnt it. It simply doesn't matter. Most of our jobs are to turn business requirements into working programs. That makes us an expert, not knowing a language spec verbatim. That doesn't matter at all. It's a meaningless metric. It reminds me of a colleague who could tell you all the performance problems of += vs StringBuilder but shipped sweet FA for 6 months. And do you know what the difference actually is? Nanoseconds. NANO. Or the person who seemed to be able to quote the entire SQL manual, yet typed with one finger and spent 3 months building a 10 line SQL statement. Or the colleague who could give you text book definitions of every design pattern you can imagine, but when asked why they'd implemented a complicated mediator pattern for saving simple forms couldn't explain, "that's how it's done!". And when I ripped out the several thousand line monstrosity and rewrote it in 100 lines or so, they still admantantly said it was better even when presented with load tests that showed the new code was orders of magnitude faster. What are you recruiting? Language experts, or coding experts? As you seem to be confusing the two. Sometimes they intersect. Sometimes they don't.
- trentnix 4y ago
  > There are developers great at solving business problems, which is what the vast majority of companies actually want. Many developers find themselves in a position of being a subject matter expert in a particular business or industry, and that becomes the primary value they deliver. They remember where that error message originates or why that column in the database is named so strangely. They know the lingo and business quirks inherent to their industry. Over time they lean more and more on that knowledge and the extent of their software development is mostly spotting patterns in the existing codebase and regurgitating those patterns repeatedly. Their programming muscles atrophy while their subject matter expertise grows. But that knowledge doesn't always transfer well. I've fallen prey to this trap (personally) on more than one occasion, getting lost in what I was doing instead of seeking to better understand what I do. > What are you recruiting? Language experts, or coding experts? As you seem to be confusing the two. I'm recruiting problem solvers, and I think it's necessary to understand the tools you are using to solve problems at least one level deeper than autocomplete shows. Frankly, I think developers are getting good at combining Google search results into a codebase that reads more like a ransom note of copied-and-pasted snippets than a deliberate engineering effort. When I ask a candidate to convert an input string of digits to its output integer (e.g. "001234500" to 1234500) equivalent and they don't seem to discern that's an important distinction, it raises red flags. Sure, tools and language (e.g. Javascript) often abstracts much of the details away, but my experience is that those developers with a familiarity of those details and why they matter (even if they might need an occasional reminder from a search engine) are a cut above.
edgyquant 4y ago
In regards to experience, I’ve noticed this too. I took over the lead position at a company with multiple senior engineers that wouldn’t pass a junior interview with me. No intuition for time complexity and not a care in the world to reuse functions etc (every task was a from scratch build out of mostly duplicate code) etc. the worst was a guy who claimed 15 years experience
ryandrake 4y ago
> Once upon a time the stereotype was that hiring developers is hard because they can’t communicate. Now candidate after candidate is able to communicate like they are a professional podcaster but they can’t seem to solve problems well. LOL I've noticed this too! Somebody must be out there teaching people to do this! I mean I interview people, and they are so over-prepared with their sound bites and their canned speeches, and they deftly try to steer all conversations back to topics they are prepared with. Their style, body language and communication tactics are polished and sophisticated. They sound very pleasing. Their slick enunciation, cadence, and confidence make them sound like 20 year NPR veterans. But the content itself is a millimeter deep. It probably fools the exec class, but it doesn't fool a practicing engineer or technical manager in the trenches.
readonthegoapp 4y ago
How diff data types are stored in diff languages? Got me! I'm not a dev anymore, but even when I was decent to good with multiple languages over the years, I would not have known this. I do remember being in interviews where one smart person on the other side of the table asked me some piece of tech that was mostly specific to their daily use, and when I didn't know it, they were shocked -- shocked, I tell you. :-D

gymbeaux 4y ago

I’ve always been fascinated with the idea that someone can be a software developer for 5, 10, 20 years and bomb in interviews, and I’ve always wondered if they really don’t know these things, or if it’s just the environment- like in my experience I can wax and wax and wax in a non-interview setting, but in an interview setting, even from the comfort of my home office, I seem to block out- not forget, because in the moment I know I know something- parts of my knowledge. You might say “well you should practice interview more” or something to that effect, but I have to wonder, if so many developers seem to “know nothing” despite their supposed experience, perhaps it’s not that they “know nothing”. On my LinkedIn I have the following: what I currently get paid by my current employer (!!!), what I am looking for in my next role, both regularly ignored by recruiters of course, and then I have links to my StackOverflow, Medium and Github profiles, any of which ought to demonstrate my “expertise” as well or better than an interview ever could. Heck if you just read some of my answers to StackOverflow questions, I think you’d see I am capable of writing code for your company…

chasd00 4y ago
> I’ve always been fascinated with the idea that someone can be a software developer for 5, 10, 20 years and bomb in interviews i cant remember who said it but many people with 10 years experience really have 1 year of experience and 9 years performing tasks doing the same thing over and over.
- achempion 4y ago
  The phrase is catchy but a bit too harsh. First of all, software frameworks and technology evolve. Second, it's pretty hard to find someone who worked for 10 years at the same company with the same software project doing CRUD actions. On the other side, if you meet linux kernel engineer who maintained kernel for the past 10 yers, this argument fails short. Same for someone who worked on Postgres internals.
- jjav 4y ago
  > and 9 years performing tasks doing the same thing over and over. I mean that's what experience is. If I want an expert in x, I want someone who has being doing x for ten years. I don't want someone who has dabbled in ten different things in ten years, thus having very superficial exposure to ten things and expertise in nothing. If I need a heart surgeon, I want the doctor who has been doing only heart surgeries for a couple decades. That's an expert. I certainly don't want some doctor who has been switching from heart surgery to podiatry to dentistry and on and on without specializing in anything.
re-thc 4y ago
Most people aren't this consistent. At work does someone say that I will watch you code in a particular time of the day and you will be able to perform on a random question that's useless? No. Interviews have 0 context that's needed for anyone to perform. Usually you can't use your IDE, your settings or your ways of working and you've never paired up with the interviewer so might not feel comfortable. To make matters worse the interview topic is 90% chance not what you do on a day-to-day basis. No 1 is answering leet code questions at work. We're going to be using a library or tool and not to try write an analytics algorithm.
- ryandrake 4y ago
  Another harsh reality is that for most jobs, the initial interview is by far the hardest part of the job. Once you pass it, the rest is cake. It takes a lot less effort and brainpower to keep a job than it does to get it. I still look back to a FAANG interview a decade ago being the most difficult thing I've ever done in my life, and I've worked my way up from a shit mining town to the middle class, developed a complete complex software product starting from an empty text file, gotten an advanced degree, built a single engine airplane, and managed to stay married for 20 years. But out of all that, a stupid FAANG interview was the most difficult. It's just ridiculous what companies put people through.
2muchcoffeeman 4y ago
I've bombed interviews numerous times only for the answers to come to me when the interview is over. My best outcomes are when I am relaxed (already have a job ;)) and I've gone through some basic material and whipped up some example programs. I've never had a problem in a real world setting or writing code.
- cloverich 4y ago
  Its just so different talking while being judged by people you dont know, throws things off. I bombed a few last time, one in particular where I was writing a switch statement. They wanted me to use a map. They asked what if the cases kept growing and... it didnt occur to me to use a map. Im sure i looked like a novice. But in my day to day code... i flip between maps and conditionals and switch statements all the time, with ease. Its natural. But while interviewing? It just doesn't come out of me.
  - the_only_law 4y ago
    It’s weird because at the end of the day, it shouldn’t matter. I’m about to interview for a job two states away. If I fail, well I fail. The worst outcome is status quo, but I’m still terrified of looking like an idiot tomorrow.

mattmanser 4y ago

There are developers great at solving business problems, which is what the vast majority of companies actually want. And there are developers who say things like "[other programmers] can’t discern the difference between basic data types and how they are stored with the very language they claim expertise" That's not the actual job we do. Unless you happen to write libraries or crazy high performance code. Most of the time it doesn't actually matter how the data is stored in the language, it actually matters how it's stored in the DB. Because that's where the performance problems are. Most of us don't even have to remember that, even if we ever learnt it. It simply doesn't matter. Most of our jobs are to turn business requirements into working programs. That makes us an expert, not knowing a language spec verbatim. That doesn't matter at all. It's a meaningless metric. It reminds me of a colleague who could tell you all the performance problems of += vs StringBuilder but shipped sweet FA for 6 months. And do you know what the difference actually is? Nanoseconds. NANO. Or the person who seemed to be able to quote the entire SQL manual, yet typed with one finger and spent 3 months building a 10 line SQL statement. Or the colleague who could give you text book definitions of every design pattern you can imagine, but when asked why they'd implemented a complicated mediator pattern for saving simple forms couldn't explain, "that's how it's done!". And when I ripped out the several thousand line monstrosity and rewrote it in 100 lines or so, they still admantantly said it was better even when presented with load tests that showed the new code was orders of magnitude faster. What are you recruiting? Language experts, or coding experts? As you seem to be confusing the two. Sometimes they intersect. Sometimes they don't.

trentnix 4y ago
> There are developers great at solving business problems, which is what the vast majority of companies actually want. Many developers find themselves in a position of being a subject matter expert in a particular business or industry, and that becomes the primary value they deliver. They remember where that error message originates or why that column in the database is named so strangely. They know the lingo and business quirks inherent to their industry. Over time they lean more and more on that knowledge and the extent of their software development is mostly spotting patterns in the existing codebase and regurgitating those patterns repeatedly. Their programming muscles atrophy while their subject matter expertise grows. But that knowledge doesn't always transfer well. I've fallen prey to this trap (personally) on more than one occasion, getting lost in what I was doing instead of seeking to better understand what I do. > What are you recruiting? Language experts, or coding experts? As you seem to be confusing the two. I'm recruiting problem solvers, and I think it's necessary to understand the tools you are using to solve problems at least one level deeper than autocomplete shows. Frankly, I think developers are getting good at combining Google search results into a codebase that reads more like a ransom note of copied-and-pasted snippets than a deliberate engineering effort. When I ask a candidate to convert an input string of digits to its output integer (e.g. "001234500" to 1234500) equivalent and they don't seem to discern that's an important distinction, it raises red flags. Sure, tools and language (e.g. Javascript) often abstracts much of the details away, but my experience is that those developers with a familiarity of those details and why they matter (even if they might need an occasional reminder from a search engine) are a cut above.

edgyquant 4y ago

In regards to experience, I’ve noticed this too. I took over the lead position at a company with multiple senior engineers that wouldn’t pass a junior interview with me. No intuition for time complexity and not a care in the world to reuse functions etc (every task was a from scratch build out of mostly duplicate code) etc. the worst was a guy who claimed 15 years experience

ryandrake 4y ago

> Once upon a time the stereotype was that hiring developers is hard because they can’t communicate. Now candidate after candidate is able to communicate like they are a professional podcaster but they can’t seem to solve problems well. LOL I've noticed this too! Somebody must be out there teaching people to do this! I mean I interview people, and they are so over-prepared with their sound bites and their canned speeches, and they deftly try to steer all conversations back to topics they are prepared with. Their style, body language and communication tactics are polished and sophisticated. They sound very pleasing. Their slick enunciation, cadence, and confidence make them sound like 20 year NPR veterans. But the content itself is a millimeter deep. It probably fools the exec class, but it doesn't fool a practicing engineer or technical manager in the trenches.

readonthegoapp 4y ago

How diff data types are stored in diff languages? Got me! I'm not a dev anymore, but even when I was decent to good with multiple languages over the years, I would not have known this. I do remember being in interviews where one smart person on the other side of the table asked me some piece of tech that was mostly specific to their daily use, and when I didn't know it, they were shocked -- shocked, I tell you. :-D