What I’m about to say might come off as smug. I don’t mean it to be a flex, it’s just for context.

I’ve been programming since i was 6 years old, and have 26 years of continuous professional experience. 30 years of open source contributions. You are almost definitely interacting with code I wrote on a daily basis.

7 years ago I was caught up in a round of layoffs and I was scouting around for jobs. I got an interview at a startup - it wasn’t a huge tech challenge, but I needed a job.

I did an initial technical interview with the tech lead for the company. All went great. I did a “final HR interview” , again great. Then the CTO stepped in and said that he would need me to complete a coding test before I could be hired.

I failed that live coding test despite producing code that outperformed the code in the “correct” solution by several orders of magnitude.

The CTO was clearly upset by my solution, which he got very angry about and insisted was wrong, without explanation, and despite it beating the spec and passing all the predefined tests.

2 days later the tech lead, who was also present in the test, told me there was nothing wrong with my code. Better still they had actually taken it and put in into production in place of the code that CTO had written, and which was the basis of the “correct” solution.

He also told me that he’d quit after an argument with the CTO about this and asked if I found a good place to work, if I’d let him know.

Sometimes tests are not about what you can do, but how smart they make the person testing you look.

I conducted coding interviews for a few years at a startup before moving to a bigger company where I had a smaller role.

For me, I never cared about if someone got the right answer. I have actually said no to people who got the right answer and yes to people who got the wrong answer (or didn’t finish). The purpose of the interview is to see if I want to work with that person. If someone can write a perfect program, but can’t tell me why it works, that gives me no insight into how they solve problems or if they even know how to solve problems. What I want to hear is their thought process.

First repeat the question, and emphasize the key details. Speak an example input and output of the function so the interviewer (and you!) knows you understand the problem. Then start talking about what kind of algorithms or data structures you might use to solve this problem. Reference other common problems that might be similar, and how they differ. Specify patterns that could be used for this problem or even your comparison problem, and whether or not that will work for this one.

Doing all of these steps with spoken words helps your interviewer understand how you think, and they may give away hints to mistakes in your thought process, or even point out that you are misunderstanding the question entirely. And that’s okay! It’s better to work out the details when speaking about it before writing any code.

Treat the interview like you are solving a problem with a colleage in pair programming. Bounce ideas off them and see what they think. They are very likely to give hints if you talk to them in this way. If you are stuck, tell them! They might be able to reword a part of the question to help you think about the problem in a different way, leading you towards the solution.

AFTER you and the interviewer are both confident that you understand the problem, and you have discussed all the algorithms, data structures, patterns, etc. that you need, maybe spoken through a some pseudocode, or maybe written down a table of example inputs and outputs, only then start coding.

Coding tests are there to present problems from the computer science side of things and rank people on how well they are able to solve them. The whole point is to judge applicants on their understanding of the knowledge they would have gained in university programs. Universities became accreditation factories during a boom in programming and technology hiring and employers needed some way to filter people who just skated by.

You are failing them because you don’t have or cannot express formal training.

Short term, cheat. Use a second computer and look shit up, form an llc and register on all the test websites (they often have free trials just like anything else) so you can send dummy applicants to learn their tests, etc.

Long term, audit some of the many university programs available online up past the 200 level.

One of the examples in this thread looks like the calculator problem (I might be wrong, it’s been 25 years!). They say “you can’t use these libraries, write a pocket calculator, no ui required” and provide a picture of a pocket calculator as the reference. The student is supposed to learn that even stuff that they thought was simple isn’t and that their language has unique quirks that many libraries work around.

Someone who solved this in 102 would crack their knuckles and knock it out. Someone who never had to do something so inane would find it very hard.

Don’t give the test. Tell the examiner to first be able enough to test you.

Let me tell people that most HRs are purely professional and don’t budge 1 bit till they receive money. Simply say to them, I’ll code as much as you want me to after we discuss the payment terms.