Not necessarily means that all good programmers are superb closet organizers, but they should be able to face clutter and leave things much better than how they found them.

I'd love to have any means of better answering that question than going with "did you pay attention in class/last few jobs?" sorts of questions like "Can you work with this linked list on a white board" simple programming problems, but right now I don't know a better way. So I don't consider programming puzzles meaningless on the assumption that the guy who slacked off won't do well with them while the guy who paid attention and loves to program will know and demonstrate a thing or two.

I know with some potential hires I can review a github repository, but that has similar problems. I've handed an interviewee code from his own github repo where he had fixed a defect and asked him to point out the defect he fixed on the page, and he couldn't find it. Does he just have a bad memory, or is he lying about that being his code? How can I tell?

1) There definitely is a better way. It involves engaging with your potential long-term officemate for longer than a 45 minute face-to-face session. Have them write actual, working code (or whatever... depending on their intended role) -- maybe even pay them for the time they spend on this process with you, so they don't feel like you wasted their time if you decide not to hire them. Basically, approach this function with the same level seriousness and goodwill that you'd bring to any business dealing with people outside your company.

What is that you say? You don't have time for that style of hiring process? Well you can either have a better process or a fast/simple process for judging people for long term compatibility. People generally don't get into long term relationships with other people after a 45 minute (mostly one-way) quiz.

2) Do you really expect a working professional to remember the details of each bug that they fixed in their career? Won't it have been better to simply concoct another piece of code with the bug they fixed and see if they can spot it with the familiarity of someone who's seen something like it before.

The goal here is to see how well we can communicate with each other as well as your ability to actually do the sort of work we need done."

Imho, there are only three things you really need to know about the candidate:

1) Will this person fit into the current team with the minimum of fuss?

2) Can this person do the job professionally and in a timely way?

3) Is hiring this person a financial risk we're willing to take?

For the other 98% of companies, there's just no need. I've also never ever had to do strange things with binary trees.

90% of programming is problem solving. Knowing how to solve a problem is much more useful than being able to spout out the right answer.

(To echo the first poster. Number of times in 20 years outside of a job interview I've had to implement a Linked List: 0)

IMHO Google, Facebook et al are largely the cause of the current recruiting mess because companies who don't understand what makes a good employee for their company have been cargo-culting Google, Facebook et al in the hope that will "make it rain" for them.

You can't look for an answer if you don't know what question to ask.

This has to do with that whole "conscious competence learning matrix" stuff, more entertainingly described by Steve Schwartz as "shit you know, shit you know you don't know and shit you don't know you don't know" [1].

The purpose of interview questions about algorithms and data structures is to see whether the candidate has the basic understanding of how the most fundamental data structures work and when to use them; whether they understand the concept of complexity and why it matters.

If you think these things don't matter, you're taking them too literally. Knowing when to use a linked list, when to use a binary search tree and when to use a hash map might be the difference between your software being able to scale or not.

[1]: http://jangosteve.com/post/380926251/no-one-knows-what-theyr...

Asking algorithm trivia questions will tell you nothing about whether or not the candidate can apply that knowledge in the real world.

A large part of what I do involves coming into teams that are struggling with delivery, and helping them get back onto the path of productivity.

More than once, I have had developers that could (and have) leave and easily pass a Google interview. They knew more about computer science than I probably ever will.

And in many of these cases, the code they wrote was actively harmful. Unreadable, tangled messes, that nobody else on the team could unwind.

Knowing how and when to use monads, or bloom filters, or any number of other fun tools separates the supermen from the mere humans.

But before you need to care about that, there are more fundamental concepts that matter. Like being able to write readable code that conveys intent, knowing how to write tests that are flexible yet specific, and so on.

While we're at it, who said anything about monads and bloom filters? The former aren't really data structures or algorithms, the latter would hardly qualify as "the most fundamental data structures".

Also, I don't remember saying anything about the irrelevance of writing readable code and flexible-yet-specific tests.

In short, you're certainly disagreeing, but apparently not with me.

As far as companies attempting to emulate Google or Facebook when it comes to interviewing, this sort of thing is even older than either of those companies -- in the mid-90s it was common to attempt your own spin on the "Microsoft interview".

I totally agree with the basic point, though... for all of the supposed rational thinking that goes on in tech, hiring people is mostly cargo cult and voodoo magic.

I'm currently a CS student and I do find many of the startups locally do involve loads of problem solving on the job, which is beneficial from general algorithm knowledge. Although I believe it's more so the ability to understand the concepts as opposed to spouting knowledge for any specific abstract data type or algorithm.

But by any means all companies are not similar, and outside of the purpose of prodding for problem solving aptness it is definitely not the best topic to discuss in an interview to find the /right/ employee for many of the companies of which do ask it.

I see this argument used time and time again, but it makes no sense to me. Surely they can just search for it when they need it too :)

But in reality, what happened, at least in my experience, is that the top talent almost always left because a) they never really got to use that Longest Common Subsequence algorithm that they quizzed on, so the actual daily work-experience was sappy compared to the hype or b) it was just one more conquest anyway; off to better / greater things that challenged their abilities

The real gems, in my not-so-objective perspective, were the in-betweeners : people who may not be brilliant, but those who worked hard enough to pass the interview and were really thankful to have a great employer. They stuck around and worked sincerely and were an asset to the firm in every way possible.

IMHO, a firm needs 90% ordinary folks, and only a handful of brilliant crazy geniuses.

If you're working on a solution to an actual problem, it's a pretty damn good to have an idea about the complexity of it. You don't need to be an expert, but developing some kind of intuition for it is very helpful.

If your attitude towards these things is "I'll just Google it" then you're not going to be quite as useful when it comes to discussions. Your toolbox needs to be bigger than that.

I have had to implement a sort once in 10 years of professional programming, it was in IE6's painfully slow js to fix a slow table sort. More than most. I didn't do a CS degree, the people around me with CS degrees didn't know the answer.

I googled it.

After the 15 minutes it took to find and implement it I mentioned it to one of the CS people, he promptly reeled off the definition to me, but couldn't see how it solved the problem.

Give me someone who never cuts and pastes over someone who know algos any day.

Firstly you're almost always wrong about what you think will be slow. Add to that it's rare you actually know how a programm will really be used.

Secondly most programs never get stressed so it was a complete waste of time.

Third, you just made the program complex for no actual good reason, just inexperience and flawed logic.

So all that knowledge, those tools, is useless and we know it is. You could fill volumes about the cock ups and bad code caused by premature optimisations.

A for each. That's what you'll use 80% of the time, a for 20% and your algos 0%, for all intents and purposes.

If you don't have a good idea of what is likely to be slow, we have a problem. It's usually I/O, especially synchronous network I/O.

During initial development, maybe you don't know how a program will be used, but maintenance is usually a bigger phase than initial development, so you should have some idea of how things are used.

> Secondly most programs never get stressed so it was a complete waste of time.

What are you working on? Everything I've worked on that has users could go faster. It doesn't take that much complexity to get something that takes 100 ms; and making that take 50 ms instead is an easily perceptible difference.

> So all that knowledge, those tools, is useless and we know it is. You could fill volumes about the cock ups and bad code caused by premature optimisations.

You could fill volumes about the cock ups and bad code caused by completely garbage performance because people didn't stop to think about how to do things right. Simple things like reducing the number of round trips to the database, or avoiding calculations until you know you need them could be called premature optimizations or just doing the job right. Having knowledge of algorithms (and knowing what algorithms are likely to underly the abstraction layers you're using) helps you avoid writing code that will blow up.

Saying it's "I/O" is so abstract and ultimately useless. A simple SQL query could hold a dark secret of a missing index on a table with a billion rows. Yes, that's technically I/O, but for today's programming that's so obtusely abstract it's pointless calling it that. It's a couple of lines of code that all the algo knowledge in the world won't have stopped the problem happening.

It's simply common sense. This is what we're trying to tell you. This is what we're trying to explain to you. Performance problems are almost always unintended consequences rather than "I'll suck it and see". Knowing how to implement the sort yourself won't save you, you have to spot the problem first, which is the hard part.

Basic multiplication is not algos. Knowing that a 100 loops of a thousand loops of a 1ms method is bad doesn't require magical knowledge. Algorithms was always a smoke and mirror trick, the ones you need are usually already in your language written much better than you could and the rest simply hides the truth that performance is mainly down to unexpected I/O bottlenecks usually buried under many layers of abstraction (SQL) or the occasional loop within a loop hidden in a long call stack.

I accept the point that over optimizing is the root of all evil and the rest of the philosophy along those lines. But knowing algorithms and data structures inside out, because where and when you have to choose what - i doubt one can be called a programmer without all that.

And i would say again, i am yet to find some body renowned, who has made their mark as a programmer, and doesn't regard all of this stuff high enough.

Having said all that, if you work in a high level language and develop client facing / application layer desktop/web related stuff - and not involving too much scaling, you won't need these things most of the times. But if not, you can't live with out these.

Lastly, since college and probably since learning to program, the best of the breed usually were the guys who went on to acm and top coder kinda stuff. It is true that building products is not synonymous, but it definitely plays an undeniable part albeit i must agree that it is slightly over valued, nothing else.

And who is renowned in this industry? Game programmers. Not Sass, enterprise or consumer web programmers, who make up the vast majority of working programmers. No, one of the tiny subsets of programmers who do need algos.

You're stuck in your own bubble thinking it's bigger than it is (and seemingly thinking it's "proper" programming). So you're wrong because your premise is flawed. 95% of programmers do "high level language and develop client facing / application layer desktop/web related stuff". Simply open a job website and search for "developer". Add them up by SASS/Enterprise/Consumer Web and then everything else. The first category will be much bigger, 20-30 times bigger.

So the whole line of reasoning is irrational to me. Never tried saying systems programming is more main stream then web or desktop or enterprise.

Talking about renowned, Yes people who have written kernels, operating systems, network stacks / protocols - there is huge list of renowned ones. Do you want me to spell the names out starting with Torvalds or Stallman?

One of the biggest culprits of truely awful programs are graphics card makers. I bet they all know algos, the problem is that they think they know how to program when they're little more than amateurs or hobbyists.

But I still can't find a job in Google.

Large companies tend to already have very stable revenue and now need people to make their systems more efficient in order to decrease expense.

I do think some people at FB/Google need to know this stuff cold, but even that isn't going to be 100% of their engineers.

The reality is that there are some jobs (a small minority) at these companies that require incredibly deep algorithmic knowledge - they really do do some complicated things.

But the majority of jobs at TwitGooFace are your run of the mill programming jobs, where the requirement and the reality don't call for anyone at that level, and hiring someone at that level is just going to make them bored. Indeed, the vast majority of people I know at these companies aren't algorithmic encyclopedia, they're just solidly competent engineers.

Having worked at a "AAA" tech giant and many more places across the country, I'm happy to report that for the most part there's nothing exceptional about Silicon Valley jobs and what they require. For the most part, barring a minority of highly specialized high-level positions, engineering ability trumps computer science knowledge.

Source: worked with multiple Math PhDs. Have a few friends who are Math PhD working on some esoteric problems that I could not understand.

+1

  * Keeping a project on budget and schedule
  * being able to create a budget
  * managing people and resources
  * Grinding out boring, but bug free code
  * Writing clean code
  * Being able to refactor
  * Design software that is maintainable
  * not tick off the people around you

Yes... I ran a small group where we all got too inward focused being clever in our code and optimizations, all the while ignoring (for various reasons) that we had less income each month, and eventually folded.

I've since seen this firsthand at a couple other companies, on the inside and outside, where engineering types get way too focused on trying to hyperoptimize for a theoretically possible scenario X, while ignoring real world tickets that are costing them customers daily. They don't seem to realize that... when enough days pass, and enough customers leave, there is no more money to pay them.

Having lived through a couple failures (personal and professional), it's probably easier for me to spot these behaviors (again, because I used to do it myself). In my case, I wish I'd had someone early on beat that out of me - I simply wasn't aware of what was going on. As much as you can say "people have to learn for themselves", I don't believe that's the right attitude to take when the fate of a dept or company rides on what you're doing - too many other lives are involved.

This is in reaction to your 'budget' stuff above - I don't expect people to be Excel/Quickbooks/Peachtree gurus nor CPAs, but understand that you have to get stuff out, on time, and sometimes have to choose your battles and put out less than optimal code, then have a plan to address the known shortcomings.

I agree too on the CS adapting to engineering being more rare than engineering adapting to CS.

Minimizing the CPU and memory usage of your application is engineering more than science; however, doing it requires a lot of CS knowledge.

The issue isn't if you can write on simple binary search (considering such a search is a intro-to-programming task[1], that should be a given), but if you have an understanding of the topic in general.

When your project calls for a certain performance bound, will you flail around or have some idea what you're looking for?

1: "Guess my number between 1 and 100!"

These are basics. Same for strings, too. A programmer should be able to decisively explain how strings work in their language. Where do you draw the line? Arrays are just another data structure, is it OK if they don't know the properties of arrays since they can look it up?

My point is that you can write a lot of software before you need to know what binary search is, and at the point that you do need it, you will be able to find out about it with ease. Like you said, it is a basic topic, so you don't even need much lead time to bring yourself up to speed.

I think where you are going with this is that if you don't know what binary search is, you won't recognize when you need it, which sounds quite logical, but experience has suggested it doesn't actually play out like that in the real world.

> is it OK if they don't know the properties of arrays since they can look it up?

I think so. For the vast majority of software being written, the only thing you do need to understand is the language's interface to arrays, which are usually presented as abstract collections. The idea of a collection is something that transcends beyond programming and computers and is understood by basically everyone. When the time comes that you do need a lower-level understanding, you can look it up quickly and efficiently.

A effective practice for writing efficient software is lazy loading, and I believe it works well for humans too. I might be willing to accept that it is a skill that not all people have taken the time to acquire, however.

In numerous forums, people ask for code because they don't know what the problem is. In which case, even search can't help.

I'm sure anyone who is a CS researcher would disagree with you, but I'm probably taking your point out of context.

> I have seen java developers knowing only ArrayList and nothing else in the collection.

And I have seen a full-fledged computer science graduate, from a top school for CS, use MS Access for everything, including projects that had nothing to do with databases, because he didn't know how to use any other tools, and didn't appear to have the know-how to take full advantage of that specific environment. Bad programmers are bad programmers.

> In numerous forums, people ask for code because they don't know what the problem is. In which case, even search can't help.

Technically speaking, isn't that still a search? The only difference to using Google is that the results are indexed by humans instead of machines. I think this further emphasizes that most people really can recognize when they need a new tool and can find the right one on demand with very little trouble.

And, like I said, I am willing to believe that it is a skill that is acquired. Skills, by nature, come with varying degrees of ability. Perhaps the least skillful stand out most predominantly in your mind? The best are probably so good at it that you don't even realize that they are doing it.

    intersection = ary1 & ary2

Here's one where they are: In python, the in operator works on both lists and sets. For one, large numbers of elements will perform very quickly. For the other, it will perform very slowly. If a developer doesn't understand how they work, and where it's appropriate to use each, they can still do something completely terrible without even straying away from basic APIs.

Case in point, 10s of Googling produced this link: http://stackoverflow.com/questions/2831212/python-sets-vs-li... ...and I don't even use Python yet.

Is it helpful to understand? Definitely.

Although not too often (compared to factors mentioned already), but it depends upon the domain too. I worked in embedded for the most part where the liberty of using frameworks, libraries - is far scarce, so it matters which area / programming environment are we talking about in general.

Also, i am yet to run into a good interviewer + programmer (whether more experienced or junior) who doesn't value these things as a good predictor of some one's coding ability.

And we are not talking about only scale of companies like Google or Facebook and in my humble opinion, those might get a bit tooo algorithmic as well.

But you should be able to recognize that a design you did won't scale when you have say 100k or more packets (instances) of inputs thrown at it. It won't be a problem ONLY UNTIL your list of traversal, get big enough, and frankly any software worth being discussed - gets big enough at some point.

Or that your linear traversal should dramatically improve if you could code and use a hash table instead.

Ah - and yes, loved the idea of 'can do serious work for at t least four hours a day', but wonder if there is a way to determine that.

I've got ~36000 hours of professional programming behind me and like you, there have been many a time where initial testing has highlighted a performance issues.

So out comes the hash table, the binary search, the double checking of the memory allocations or the some new index on the SQL table.

Now I know Big O tries to formalise these sort of things (or at least I hope that is the case), but is knowing the answers to these Big O questions that important?

Since I have Engineering degree I certainly can’t give a credible answer to a Big O question, but I have absolutely no trouble fixing sluggish code.

> But you should be able to recognize that a design

Unfortunately, at a lot of the places I've worked, not much time is ever allocated to design :(

Managers seem to want easy to read, high level, non technical design documents to take to their managers meetings and once those are approved they then want something coded ready for QA.

Ah... yeah for the design statement :) i can't say much beyond that for most of the companies with established practices - you have to write a design document, often down to the level of writing data structures and function names - run through debates with others to justify your choices BEFORE you can even start to write first line of code.

I understand this partially because of being in Embedded, C/C+ domain where you can literally shoot yourself in the foot due to wrong choices and often product models are different.

E.g. at one place that i worked, code reviews and conventions were very rigid, some what more than say Linux kernel, because the product was an RTOS and associated stacks, which were sold to companies WITH SOURCE since the customers were actually developers developing end applications using our APIs. So even one comment not written according to company's coding convention often won't pass a peer code review - but i believe this is a pure exception rather than the norm.

I know, I am constantly concerned about sorting that list of 100 items!

How about a gateway device receiving some minor 3-4 millions subscribers traffic and processing like 40-50Gigs per second. I suppose worrying about hashing those ips to access individual records is a waste of time, and a simple list should work? right?

The scenario is not as common as may be building a website. But it a whole industry and a whole bread of programmers exist who do this all day. You should go out more :)

(think parsing and searching monster flat text databases from disk)

- How virtual memory works

- How threads work

- How TCP works

- How ports work

- How ethernet works

- How DNS works

- How a web server works.

And so on. A lot of these things are more important than theory (but I think theory is important, too!).

That's not because I'm lazy or scared or even disinterested. I've exhaustively learned everything about anything that what I do involves and how most of what it touches works as well. However the simple truth for me has been that I've never worked on things that needed to know about the things you're talking about.

I constantly do need to know more about the fundamentals of the systems I actually work with - Rails, Angular, HTML, caching, Node etc. I'm sure there will come a point when I need to know more about some of those things too.

However there is a tonne that I don't know even about the things that I need to know about and I will always invest my time in learning those things. That's why I would always focus interviews on the languages and frameworks that someone actually uses. Those may be the ones you describe but for plenty of developers may well not.

I only drill into a framework or language when someone writes that they're an expert on it. Otherwise, learning a new framework or language might be bumpy but if they have skill then it shouldn't be a problem.

TCP? DNS?

More like persistent cache misses in SQL or some weird edge case caused by an errant vertical tab or a filename getting too long or some limit in array length causing your compiler to do weird stuff.

Knowing how any of that list works is more for sysadmins than programmers.

Lists like these reflect your own experience. I care more if an engineer can quickly grasp the "big ideas": Maybe they don't know about threads, but do they express disbelief that they solve a real problem, or an unwillingness to explore them? A willingness and aptitude for learning is so much more important because the state of the art is a moving target.

If you write code, you should know what your code is running on. You should understand some of the layers of abstraction or at least be curious about them! Even if it's not related to your job, you shouldn't take the magic underneath for granted.

I see a big correlation between programmers who take a lot of this stuff for granted with cargo cult programmers - people who tend to think of things as "if I do x, y comes out" instead of "if I do x, this will trigger y, which causes z".

I've seen a lot of things in HTTP land that I wouldn't have been able to figure out without tcpdump. The most exciting thing is that livehttpheaders doesn't always tell the whole truth. :( But also subtle things like (TCP) load balancers mungling option fields, forged reset packets (and determining from whence they may have come), weird packet corruption.

Yes, absolutely I don't expect people coming from an offline world to know the internet stuff... but who's really offline these days?

But honestly I like to see any knowledge in low level systems - especially operating systems. I think it's important for people to know what their code is running on!

For all the fear of being "culturally unfit" for a company, highlighting what kind of role you play and how you interact with your coworkers is fundamental.

Are you diligent and consistent with your work? Are you the kind of person that bursts through work in a flash? Do you prefer to work alone or in a team? How do you feel working with people below your position or above it? etc.

These questions have the issue, however, that you rarely ask them in an interview. You just gauge them from a conversation, that really doesnt speak to any of them. If someone is a complete technical ace, but is silent 100% of the interview besides technical points, i still get red flags. A co-worker is not a cog in a machine, its someone you will be spending 40 + hours a week with.

I disagree with hard theory NOT being important. Im a drop-out but i still went through all the algorithms and data structures classes out there and they gave me knowledge to communicate about hard problems, even though Im not the one solving them (we got some phds for that). And above all, at least in our case currently, several of the algorithm questions we do are actual problems we had in our product. In particular i wouldnt even call O(n) "hard". Its maybe the single most important performance computer science knowledge you need, and its not hard to calculate for the vast majority of applications.

The reality for most engineers is that it depends on outside factors 99%. Engineers try to be rational. Here is what the real-world answers to your questions look like and I bet you never heard them.

Are you diligent and consistent with your work? IF it's being rewarded, yes. If I get yelled for missing the deadline, then no. Do I get credit for doing diligent work or the credit goes to somebody else who managed to get more visible things done less dilligently?

Are you the kind of person that bursts through work in a flash? That's a straight-out stupid question. There is work that should be done in a burst(like a fix) and there is async work that can be done in chunks or in the background(planning, monitoring or support). Nobody is exclusively committed to burst/no-burst, or at least it's very rare.

Do you prefer to work alone or in a team? Nonsense question. It's more of a question for you rather than the interviewee. Everybody wants to be on a good team and everybody hates to be on a bad team. Also is teamwork rewarded, how are politics resolved? How do you manage politics? Who gets credit/blame for the teamwork?

How do you feel working with people below your position or above it? Same as the previous question. How do you manage politics? How is credit/blame distributed? What power do I have to push changes up and down the chain? How would you handle an under-performing member up the ranks?

I dont see any correlation between "bullshitters" and providing information. I definitely dont see a correlation between "non-bullshiters" and utter lack of information. And also I don't know the correlation between "bullshiters" and actual technical knowledge.

The questions above were phrased quickly, and as i mentioned, its the questions you dont ask in an interview, but an information blank you have to fill out.

There are many ways you can answer and provide information about your work and professional that aren't empty phrases.

"I made this cool site with Rails, Angular, CSS transitions" -> purely technical

"I made this cool site with Rails, Angular, CSS transitions with consistent monthly releases, coordinated with open source contributors @ github. I also assisted community members in the technical setup of the project." -> technical + diligent + teamwork. And verifiably so.

Remember that we are talking about resume screening here, its a piece of paper that could be all lies , technical or non technical, its all about standing out and finding the right fit.

There you go, what did you learned about me?

If you base your hiring on what people wrote about their own personality, you will hire plenty of great salesmen. They will all be able to guess what the boss might like and generate nice sounding sentences to him.

They can still be poisonous jerks. And if they do, they will be perfectly able to hide the toxic culture they created from you.

Also, its delusional to believe a resume is not a selling tool. There are good and bad resumes and its pure salesmanship. Finally, you will have to prove that there is a correlation of any kind between salesmanship and technical ability.

A hire is a full package deal. If you interview a total wiz, but he comes to the interview naked, you will not hire him. Well, I doubt I would vote for a hire.

It's up to the interviewers to make that determination with the help of professional references.

What in the actual fuck. What do you expect to see? "I am clean and not a raging asshole"?

That is what I would expect someone who has had to wrestle with big-O problems but didn't recognize them to say. I honestly don't know what you're working on if its actually true. I had a time complexity issue just this week. On front-end code, no less. I probably work on an issue involving time complexity once a month, if not more often.

then maybe you're not solving very challenging problems.

Can you explain what you mean by this? Are you not familiar with the term, or do you not believe it exists?

Some companies don't need the latter. Some companies do. The latter companies do want to hire someone who can do both, and not be stuck to a special set of tasks that they can do i.e. they want a generalist who can be assigned to any project of varying complexity.

Personally speaking, many of the tasks I do don't involve the algorithmic skill set. But some do - now without that skill set would I just outsource it to the "brighter" folks in my company or would the company just prefer that everyone who they hire know that stuff ?

It's also subjective and can be taught. If I asked people to name some functions in an interview, what would I really learn?

Similarly, the other things you mention, while important, don't seem particularly testable. They don't give me anything I can give to the hiring committee to back up my answer.

Actually learning something real about a stranger in 45 minutes is pretty hard. Asking them to solve a problem means you can have a technical conversation in front of a whiteboard. It doesn't answer much but it does let me know whether it will be worthwhile asking the candidate to help me solve a tricky problem, or whether they'll be coming to me for help all the time. After all, ideally I'm looking to hire someone smarter than me.

In the 7 years I've worked and contracted web dev across 6 different companies I have never, let's reiterate, NEVER had to implement a sorting algorithm. However, if needed it would be quite simple to research and implement the best solution.

All of the other points are what actually matter.

Augh, PTSD trigger.