Dev Interviews

Having to hold interviews was the worst part of the job, by far... Brings about a certain kind of guilt, to sit there and try to sell battery acid as ice-cold lemonade.
- Debugging interviews are great, because it really allows you to see how someone thinks. You give them a working test and some buggy code, then ask them to debug it and take as much time as they need while you look over your shoulder (virtually). IDC what the methodology is or the time it takes, if you can solve logic puzzles, you'll make a decent programmer.
  
  if you can solve logic puzzles, you’ll make a decent programmer.
  I mean, that's what Google did several years ago. They stopped because data showed it didn't mean anything.
  That said, debugging existing code is a more realistic test of what you'll be doing on any programming job, as opposed to writing anything from scratch.
  
  Oh, I didn't mean the content, I meant the purpose of it. In my experience, it wasn't just about testing the interviewees, it implies having to 'sell' the company as well, to give the interviewees reasons to want to be hired. That's the bit which generated the guilt.

Maybe it’s like teaching kids the quadratic equation; where it’s less about learning the thing and more about understanding how to problem solve and use logic.
In this case maybe the point is to show an understanding of algorithms and that you can explain them out loud.
- The quadratic equation is the basis for most other math and physics. It’s used all the time.
  The good thing about quicksort is that it’s a good demonstration of an O(n log n) algorithm, and that’s about it.
  
  "The basis for most other math and physics" they do a complete fucksewage job at demonstrating that in school. I remember several years in math class "And here's the quadratic equation, the one that's all over 2a" and it was an exercise in plugging and chugging.
  Math is a useful, powerful and allegedly beautiful thing. it's such a shame it's illegal to teach it competently.
  
  If I’m not mistaken, quick sort is worst case O(n^2), merge sort is what actually achieves O(nlogn), the point is that quicksort is on average more memory (and time?) efficient
- If it's about problem solving and using logic, why do we need to memorize quicksort? That's not an example of using logic or problem solving
  
  it's actually about testing your ability and willingness to jump through hoops that serve no discernible purpose, one of the most vital skills for working within 99% of human organizations
  
  You don’t need to memorize quicksort. If you understand how it works, it’s trivial to work out the exact details.
  
  I meant that as 2 separate thoughts. The quick sort is about understanding algorithms and ability to communicate them.
- If it were a question about the tradeoffs of different sort algorithms and how they might apply to a given problem, I would agree. That's not what these interview questions are about.
  
  Maybe it’s about being able to communicate an algorithm verbally. Unless these are written interviews, then yeah, probably pointless.
  Also, I do think being able to understand how an algorithm works is probably important on its own.

Yeah I need to find a new job soon, like things are going Bad at the company and it's not looking good for anyone.
I've wanted to find a new job for well over 6 months, but I just don't have it in me to study after work or on the weekends.
Its like I've got burn out handcuffs or something.
- Try posting on mastodon with #fedihire, it'll get boosted, maybe it'll help.
- I feel that...
- Do they ask to implement quick sort to people with job experience? I thought they only did that to juniors.
  
  Im at 3.5YoE, and have gotten LC for all of my interviews
  
  Leetcode is a plague with a sales team

We don't ask this sort of shit during our interviews.
- Honestly, I just ask if they can solve FizzBuzz. It shows me how they approach problems, how they communicate their process, and that they know basic programming concepts. The rest of the interview just kinda tells me if I'd get along with them as a person. Most other things, good and bad, only show up over time.
  Then again, I work with software that isn't exceptionally complex.
- You ask other, equally inane shit?
  
  Precisely!
  
  I ask them how they'd do the job we're recruiting for, on a simplified example project.
  One this morning admitted she had the wrong preconceptions about the role, but understood exactly why we were asking what we were asking.
  I call that success.

Been coding for 10 years. Wouldnt know how without looking up the rules for quicksort. Guess they want programmers fresh out of college or highschool then and I dodged a bullet?

Honestly when I was doing interview I always tried to ask simple questions about data structures or technologies from CV like what's the difference between array / list and set, or set and map, I got 90% people failing those answers, sometimes it was stress and you could feel it, so I even helped them with answers and always tried to encourage them so they get rid of stress and start thinking. All of people I hired turned out to be good workers and still work in those companies. I think we just slowly forget how to talk with each other. With all the technology around us, we're losing empathy.
- Hell ask me what is the difference between a class and an interface and it would be hard for me to put into theory as well. The only reason I remember the correct answer is because I remember being confused.
  If I do strictly my point of view, I am so bad with theory, and I usually don't think about how to write shit - I just do. I don't know how the ORM works inside, I just know how to use it, and most caveats are just hard coded in my brain.
  So I failed the theoretical interviews in most companies, but those who hired me never kicked me out themselves (as I am a contractor me and rest of the team was part of yearly layoffs, in three companies, but it was purely because money / mergers / conversion to employees).
  
  I don't think good job interview is about answering right or wrong questions. It's more about talking with human you could work with and if that human is able to think his way out because it's engineering job after all.
  I am contractor as well I only did job interviews as a side quest and I also frequently fail my job interviews, there is nothing bad there.
  Personally I didn't like 90% of job interviews and there were plenty of them. Most of those people tried to convince me they are smarter and better then me and I am lucky I am speaking with them. But unfortunatelly that's how it looks like.
  Most people that excpect right or wrong answers are just morons in my opinion because programming is about being wrong 90% of the time.
  Good Luck

You must prove yourself by reciting the holy incantation flawlessly if you want to become a member of our order.

For the most part it’s best to use system provided sorting implementations, but somebody has to write those implementations, so every once in a while somebody needs to do it (in practice by looking up a reference implementation of course).
But also it’s good to understand things like big O scaling and why we use quicksort rather than a naive insertion sort and when to use quick sort vs merge sort or some other form of stable sort.
- Glibc's qsort will default to either insertion sort mergesort or heapsort. Quicksort itself is used when it cannot allocate extra memory for mergesort or heapsort. Insertion sort is still used in the quicksort code, when there is a final 4 items that need to be sorted.
  Normally it is simply mergesort or heapsort. Why I know this? Because there was a recent CVE for quicksort and to reproduce the bug I had to force memory to be unable to be allocated with a max size item. It was interesting reading the source code.
  That is if you are not on a recent version of qsort which simply removed quicksort altogether for the mergesort + heapsort
  Older version still had quicksort and even some had insertion sort. Its interesting to look at all the different versions of qsort.