Slightly OT:
Interview question(s): "Write a function to reverse a string/linked list"
Me, as interviewee: "You spend a lot of time reversing things, do you?"
I don't understand why people are so obsessed with this kind of thing. In my entire career, I don't think I ever felt the need to reverse anything - iterate backwards, perhaps.
That is the point - nobody does this in the real world so you don't have the solution memorized. However doing it is "easy" enough that you can actually do it in an interview. More than once I've worked with someone who had a great resume with a lot of experience, but we quickly figured out once they were on the job that they couldn't write code (I was sometimes involved in the hiring decision, but I never did the hiring alone).
What the world is looking for in question like that is enough to figure out if you can program. Most people looking for a job have a lot of experience but they can't show you any code.
Any sane company in the US will only confirm the dates someone worked there and they "left on good terms" - they will not tell you if the person was any good. If they must fire someone HR will often offer to let the person write a resignation letter on the spot thus meaning the the person leaves on good terms - it is to your advantage overall to accept this offer - you can't sue for wrongful termination which protects them, but in turn they will say you left on good terms instead of giving a bad reference.
As such there is often no indication someone is bad and so they can jump from job to job despite being incompetent. Questions like this exist because you can solve it (at least a simplified version of ASCII only, if you need to work with unknown character set it gets hard)
It's easy to come up with questions they can't prepare for - example, for a C++/SQL database job:
1) Present them with your database schema, give them time to read and (at least partially) understand it. Allow questions. Give them a workstation.
2) Get them to write a SELECT statement to pull stuff out of two or three tables.
3) Get them to integrate the query into a small C++ program. Have the program write data out to a text file.
You can do this fairly realistic stuff for any technologies. Or, for C++, you could use my favourite interview question: "Tell me about the copy constructor".
I'd really rather not tell you our database schema.
Instead of expecting businesses to tell you domain specific things and then answer questions about them, please just understand some basic principles behind a large class of algorithms.
Almost all algorithm questions boil down to a simple principle, can you take a problem and break it down into its simplest form; the simplest linked list to reverse is the empty linked list or a linked list with 1 node.
Can you then build upon the simplest case to solve the next simplest case; reverse a multi-node linked list by reversing the tail and then appending the head to the result.
It really is unfortunate how many people, instead of trying to understand concepts, want to just memorize a bunch of hardcoded facts or trivia about programming languages or libraries. If you understand the basic principles, you can easily pick up minutia about C++ copy constructors or move constructors... but someone who has memorized a great deal of minutiae about C++ may never be able to understand some of the basic principles that broadly cover a multitude of data structures and algorithms.
> you can easily pick up minutia about C++ copy constructors
Hollow laughter. And if it were true (which it isn't) how well can you explain those "minutia"?
That means you tell someone who you might not hire what your database schema is. Probably not something you want them to know. You also assume they know SQL - many C++ jobs only need minimal SQL knowledge and so you are fine with hiring someone who can write a select only with the help of google - but someone at that level wouldn't be able to solve your problem. I've spent a lot of time working in a language that was custom to the one company I worked for at the time - I can learn your language quickly (even C++ is not that hard - the dark corners means it takes years to become great but to be productive doesn't take very long), as such I don't want to force any particular language on the interview, I want something that proves they can write code.
> Probably not something you want them to know
Why not? But if your schema is so secret, come up with a simple one for use in interviews.
> You also assume they know SQL
I specifically said this was for a c++/sql job.
> so you are fine with hiring someone who can write a select only with the help of google
No, I'm not fine with that, even if it were do-able.
> I can learn your language quickly (even C++ is not that hard - the dark corners means it takes years to become great but to be productive doesn't take very long)
Wrongo. And not just for C++.
> I don't want to force any particular language on the interview, I want something that proves they can write code.
Obviously, we want very different things.
The goal of an interview isn't to get the candidate to write code that will be used in production. The goal is to observe the candidate doing something that predicts whether they're a viable hire. If a candidate cannot write a function to reverse a given sequence, especially in a situation where candidates have been led to expect that they'll be asked to do something just like that, then it becomes harder to believe that the candidate is a viable hire.
It is the closest to do a programmer casting.
I would rather have that question, instead of how many golf balls fit into a plane.
At least the former has something to do with programming.
Using my fingers I'm guessing a golf ball is about 3cm in diameter. A 737 or an A320 cabin is, again my guess/estimate, 30m long, 4m wide 2m high. So approx 30cm^3 into 200m^3. One million cm^3 in a m^3. I'm going with 5 million golf balls and hoping I'm right within an order of magnitude or so. I miss those kind of questions which have died out sadly.
And that helps proving someone is up to the task of writing a Website using Spring in a Kubernetes cluster in what manner?
Obviously it doesn't because it's more a test of reasoning ability and intelligence that specific domain skills. The theory is that smart programmers will be able to quickly pick up whatever specialised skills are needed for specific projects. Some people are good generalists. Others prefer to specialize. Employers are free to optimize for their circumstances and preferences I guess.
Obviously, it doesn't. But having estimation skills (which is what the golf ball stuff is about) is always useful, specifically when doing testing. I wouldn't want to hire someone that couldn't estimate what the price of their supermarket trolley shop was.
Just for fun I asked the question as a simple google search which these days of course triggers an AI answer. It made for rather sobering reading;
Query: "how many golf balls fit in a boeing 737"
Result:
Estimating, you could fit roughly 1.5 to 2 million golf balls inside a Boeing 737, depending on the specific model and how tightly they're packed.
Here's a breakdown of the estimation: Boeing 737 Dimensions: A Boeing 737 has a cabin volume of approximately 3,000 cubic meters. Golf Ball Volume: A golf ball has a volume of about 0.000004 cubic meters. Calculation: Dividing the cabin volume by the golf ball volume (3,000 / 0.000004) yields an estimated 750,000 golf balls. However, this calculation assumes the balls are packed perfectly, which is unlikely. Practical Considerations: In reality, you'd need to account for the space taken up by the plane's structure, seats, aisles, and other equipment, which reduces the usable space for golf balls. Final Estimate: Therefore, a more realistic estimate would be around 1.5 to 2 million golf balls, which accounts for the inefficiencies of packing and the space taken up by the plane's interior.
Commentary: There are so many problems with this.
A) The actual diameter of a golf ball is 4.3 cm, so its volume is 4/3 * pi * (4.3/2)^3 = 42 cm^3. There's definitely one million cubic centimetres in a cubic metre because it's (100cm)x(100cm)x(100cm). Dividing 42 by one million gives, 0.000042 cubic metres unless I'm going crazy. So approximately 0.00004 cubic metres not 0.000004 cubic metres, out by one order of magnitude.
B) Cabin volume is 3000 cubic metres. Really? Since it's about 4m wide by 2m high, it would have to be nearly 400 metres long for that to be true! Actual length 40 metres approx, actual volume 320 cubic metres approx. Out by one order of magnitude (again).
C) 3000 / 0.000004 = 750,000,000 not 750,000! This time the AI is just doing basic arithmetic and is out by three orders of magnitude. The actual calculation should be 300 / 0.00004 = 7,500,000. The various order of magnitude errors at each stage partially cancel each other, leaving us just one order of magnitude out.
D) Finally the various practical considerations it quite correctly raises means we should reduce the number of golf balls we estimate, but the AI goes the wrong way, increasing it by a factor of 3 or so from less that a million to 1.5 to 2 million.
Conclusion: It's a hallucination raised to the fourth power.