A three-hour test is above what I'd consider acceptable for most potential employers. I can talk with you a bit, but if you want me to come in and do work for half a day, I'm going to refuse, I've got actual paid work to do.
1. grep -r '"append"' to find where it does "switch (cmd) { .. }" – append seems reasonably unique, but maybe there's a better command.
2. Modify switch to recognize "mult" command.
3. Find "append" function that does the work; copy/paste, modify to do multiplication.
4. Converting two strings to a number, multiplying the result, and returning the result as a string is a fairly trivial function.
Unless the memcached source code is hugely surprising, I might be able to get a first working version in 15 minutes or so on a good day if I don't mess up, maybe double on an average day. Add 15 more minutes to build memcached and read the question, and maybe a further 15 minutes of making it nicer/leeway.
A 3 hour limit is long enough so that no one reasonable will stress about running out of time, affecting the performance, and short enough that bozos can't easily trial/error it, ask on Stack Overflow, or whatnot.
Other than that, the stage matters a lot as well – is this the first interview question shotgunned to everyone who applies, the final one and you're hired if you pass, or something in between?
A test might be useful, but I took a quick peek at the source and it really is as straight-forward as I suspected it would be: the input is already tokenized and you can just add a new entry in a large, if .. else if tree, write a multiplication function, and that's pretty much it. You can just test it by started memcached and sending it commands.
I'd whip up a quick patch, but the tar.gz is 14 years old and doesn't compile with latest clang without twiddling -W flags that don't seem to apply, and the git copy doesn't compile due to autoconf woes (sigh...) Messing around with autoconf is not my idea of fun and too much pain for a HN comment, so whatever. But you really don't need 3 hours if you vaguely know what you're doing and are a competent C programmer (which I am only barely).
The memcached protocol really is as simple as "CMD [params]", all of which is parsed for you, and this API is just "MULT num1 num2". There are no tricky bits or hidden complexities here as far as I can see.
If you read the introduction and then spend extra hours doing "other things" (that are bad), it could count against you.
https://quuxplusone.github.io/blog/2022/01/07/memcached-inte...
In the past I've encountered companies that would just throw a multi-hour coding test at you without even giving you any idea of the role they are hiring for. If it's not worth employer's time to get the candidate interested in a position, the position is not worth applying for.
Used to be that it might be "Hey, let's have some conversations and then there's a little project..."
Now I've had multiple employers open with "Thanks for applying. As a first step, we would like you to perform this project. From there, we will let you know of next steps."
Uhh... no.
Well, see, many graduates or experienced job seekers don’t.
I tend to default to C++11 with C++[11,23]-portability.
In general, write maximally portable code without using vendor- or standard-specific features without a/some very good reason(s).
Also, C++11 is a monumental improvement over C++ from the days of rusty sharp edges of 90's C++ where one needed to follow strict standards to avoid nonobvious UB.
But what if my odds are only 10%? Then, on average, I'm going to have to apply to 10 jobs to land one. 10 x half a day is a full working week. Make that two weeks if my odds are only 5%, three weeks if they're only 3%.
That's a problem, especially if I currently have a job. I also have a life; I don't have three spare fulltime weeks to burn to try to land a new job.
I would hope Bobs Burgers aren't asking you to add a new feature to memcached in their interview process.
I’ve fixed a bug in memcached (improperly cleared buffer, null GETs resulting in zero prepend on next GET under high stress) during a five alarm fire and deployed it across a cluster in less than 30 minutes - and I would consider myself a mediocre devops hire.
If you want me to do work for you and judge me on that, I'm available as a contractor.
That’s weird. Seriously. That’s weird. Every job I have had in my 20+ year engineering career had a multihour interview panel. I’m talking like at least four separate hour long interviews all on the same day. Big company. Small company. It literally didn’t matter.
And you’re saying this has never happened to you? I have to ask, what has been your typical interview experience been, and how tiny are these places?
At some point, you have to wonder when know you’re the odd one out, but you didn’t. That’s on you.
Do better next time Tiny.