Yeah, it does seem like the best jobs are the ones that you don't have to jump through arbitrary hoops for. Ideally, your employer or client will respect you as a human being who has something valuable to bring to the table.

When I find "good jobs", they almost always crop up from serendipity in areas that I am genuinely interested in at the time. Looking back it feels like dumb luck, but the sort of dumb luck that is helped along by trying to make your own opportunities.

If you ever have a chance to talk candidly with an executive or entrepreneur about a subject that you are passionate about...well, at least take the meeting. Those sorts of discussions aren't interviews per se, but sometimes your vision will click with someone else's, and that's where the magic happens.

> Yeah, it does seem like the best jobs are the ones that you don't have to jump through arbitrary hoops for. Ideally, your employer or client will respect you as a human being who has something valuable to bring to the table.

Even better if they actually know you!

> If you ever have a chance to talk candidly with an executive or entrepreneur about a subject that you are passionate about...well, at least take the meeting. Those sorts of discussions aren't interviews per se, but sometimes your vision will click with someone else's, and that's where the magic happens.

This is great advice. Talking to business folks when you aren't working for them is a great way to practice this skill and you never know what you might end up running into. Another good thing to do is to try to connect two people who might benefit from the connection (discussing a technology, an opportunity, etc). Sometimes something will happen, sometimes not, but the goodwill will be remembered.

A few years ago I joked about never wanting to submit a resume again. If you spend time on your network (all the time, not just when you need a job) and do good work, hopefully you'll get to a point where you can contact people you know who are looking for help.

Sure you'll still need to "interview" but the stakes are lower: they know you and you know them.

You can't believe how many people are unable to do the basic things like sort an array.

These kind of questions is not to see how smart you are, it is to weed out all the ones who don't event get the most basic parts of programming. And I can assure you as someone doing a shitload of interviews, that a huge part of candidates doesn't understand the basics of programming such as sorting an array.

If all candidates had a minimum competence, sure we could do other kinds of things. But right now, you will first have to pass the "I can do newbie programming" tests.

You're not interested in the candidate, you're interested in litmus tests. Not the kind of place I ever want to work.

Why would any company want me to write an array sort instead of calling the .sort() method on the standard array class? Is that really the sort of thing they want their devs to code and debug and maintain by hand?

Having a deeper understanding of how things work is important in knowing how to use even the high level constructs well. How do you choose between an ordered and unordered map? If you've implemented them even one time I bet you'll have a clearer understanding of where each one excels.

If you couldn't remember how to implement quick sort or merge sort that would be one thing, but if you had no idea or never considered how a fast sort could operate that's another problem. I would never ask this in an interview but to use it as an example, it wouldn't be recall of an implementation that I'd be looking for but seeing if the candidate can identify a divide and conquer approach to the problem.

Good architects know a thing or two about material science, good electricians know a thing or two about physics, why programmers programmers be averse to understanding algorithms (i.e. the nature of computation)?

You should use sort() and ask whether it's okay to use the built-in?

They will always say it's fine and move. It would be extremely uncommon in the current decade to come across an interviewer who minds using the standard library.

And if they do mind, well, one of two things:

* they are a pedantic, roll your own type of place that is full of custom frameworks and libraries that you're better off avoiding

* they are big enough or specialized enough that they really need that level of knowledge

I imagine the former is more common.

And if you are applying to the latter, you should know that from your research. You do research companies before you interview there, right?

It demonstrates a basic understanding of underlying principles.

If you can't do a sort, how will be be able to do more high level complex things?

I think testing whether someone can recall the implementation of quick sort and has practiced writing it quickly is not really testing for building complexity or solving problems.

It’s testing for practiced solutions of memorized algorithms and a bit of role play.

I get there’s some IQ challenge to preparing this and it’s hard to evaluate skill, but I don’t think this tests much beyond that.

Want to test true basic programming capacity? Do fizz buzz, ask someone to reverse names in a string with loops - everyone should be able to do that without thinking.

That’s actual basic stuff.

High level or more complexity? Discuss a relevant problem the company needs to solve and how they’d approach it.

Better yet discuss a problem and debug it together. Most programming is debugging anyway.

Note that koonsolo never mentioned quicksort, only sort. You can easily make it a newbie question by just accepting any sort that returns a correct output, even with a quadratic complexity in the best case. Any programmer should be able to write that in less than 10min.

And as the post you answered to alluded to, the point of the question is really just to filter out candidates who can't even write simple code, just like fizzbuzz. That's the kind of question you could ask in a first round, and then proceed to more relevant questions.

I haven't written a sorting method in years and couldn't remember it on the spot in 10 minutes, despite having analyzed the big ones 6 years ago. Yet, I have no problem creating a giant, modular, cookie-cutter enterprise structure, which is generally more sought after and something many hardcore leets seem to struggle with, especially once it comes down to doing more than just a fancy UML graph.

We really don't need True Scotsmans on this site.

Again, you can make it a newbie question by just accepting any sort, including one you come up with on your own (so no need to remember). I'm sure you can design your own sort given enough time, granted 10 minutes might be too short to get it nice and clean, but with a bit more you're on the level of difficulty of fizzbuzz.

To make my point clear, you can implement a dumb and inefficient sort by implementing a min function, taking this min, then iteratively call it on what's left of the array and append the values to a new array which you then return. That won't get you into FAANGM, but maybe that's enough to get some discussion started in an interview at a company that's not too much into leetcode and is trying to evaluate other skills like communication. And I do think that 99% of people who write code every week could come up with something like this or better fairly quickly.

That's reasonable to me if that's the standard.

The reason I jumped to quicksort in my initial reply is any sort short of quick or merge sort (or some other nlogn variant) would fail you at FAANG.

You could do the naive n^2, but it better only be in the first two min and hand waved off as obviously inefficient, almost a joke that you implemented it at all on the way to writing the nlogn version, bonus points if you talk about how merge sort is nlogn in worst case and quicksort is n squared in the worst case, but in practice often faster.

Some people consider me a senior, yet the only sorting algorithm I actually remember and can write from scratch without consulting anything is bubble sort. And maybe insertion sort. And that's it. Both horribly inefficient. In real life I use whatever the language provides, for example Collections.sort in Java.

The more general problem is just how far removed from reality are all these questions. I once tried interviewing for Google, just for fun because they sent me an email about it. They asked me about quicksort, I said that I'm able to implement it in any language I know given an hour and the ability to google things. They were apparently not very satisfied with this response.

Why do you need to recite things from memory on the interviews while you'll be able to consult whatever the hell you want on your actual job? No one knows.

Knowing how to implement sort does not mean you can't do higher complexity things. These are not the basics of programming, I think. Someone the other day refused my candidacy just because I was unable to comment more broadly on the abstractions used in C# async library, which is completely off the point. If you need to do some tweaking on async, you go to microsoft or google and find it out. Most of the time you just need working knowledge of how to use async await and a few other things.

I have never implemented sort after the second university compsci course. I might still be able to write one if I think about it a bit, but just not relevant at all.

This is a common falacy that comes from academia.

If you can't divide numbers, how will you ever do algebra?

Guess what? They're different skills.

A person who is good at algebra, may not be good at all at division. I know a few who fall into that category. The use a calculator.

If you reimplement the standard library for basic tasks, when will you ever get the time to build useful things?

This is a good strategy for senior engineers to avoid the leetcode interviews. And to any recruiters and hiring managers reading this, there’s the other side of this. If you want responses from high quality senior engineers, then start your LinkedIn email with “NO Leetcode”. Response rates will likely increase by a lot.

I very rarely respond to recruiters cold emailing me, but if it had NO LEETCODE in the subject line I'd probably respond to every single one.

Same here. I ignore all cold emails or mark them as spam. If I saw something like NO LEETCODE in the subject I'd be likely to read it. If it sounded like a reasonable place to work I'd share the job with my network.

> We still tolerate PhD Comp Sci algorithm questions for frontend developer gigs

Go and look at some Javascript answers on StackOverflow, and then consider why lots of websites are so slow!

Some random examples:

* Deduplicating an array; top answer is N^2: https://stackoverflow.com/a/9229932/265521

* Deduplicating array again: top answer is still N^2!: https://stackoverflow.com/a/14438954/265521

I've seen loads of similar examples. Maybe there is code that doesn't use any algorithms at all but it's probably not very interesting code.

> a national, Austin based real estate firm

I can't help notice the irony that they wanted to put you through a gauntlet of leetcode style interview questions only for you to be working on what are most likely basic CRUD apps.

Thank you, this is brilliant advice. Despite decades of experience I was nervous due to this trend and spent way too much time on hackerank. The company I ended up with didn't ask any of that crap (despite being founded by a PhD), and we couldn't be a better fit.

Of all the companies I have interviewed with, the only ones I ever joined had sane, non-leetcode interview processes. I have actually reached a point where I see companies asking those questions as churn factories to be avoided rather than schools of practice. If/when I find myself interviewing again I will be declining leetcode interviews.

> The interviewers had no idea I would decline the challenge, and I politely ended the call.

This happened to me too, despite assurances from the recruiter beforehand.

Don't believe recruiters. They'll tell you anything to get you in the company's hiring process.

That's exactly how I handle these interviews nowadays. Granted, it'd hard to know what's your price when you're young and you would take everything in the early years. But now I'm mid 30 and have seen and executed enough interviews to know that the rational thinking and kind human is so much more worth than a code monkey that is twice as fast. Why? It's the same reason why code should be readable - you have to live with it. And the only way to achieve this is by asking for the way of thinking, now what's the solution is.

thank you for the advice

yep, this makes sense, vote with your wallet.