kashav 2022-04-17 23:21 UTC link

Got the same question for a new grad position around 2019. Only had an hour that time. Great question.

notreallyserio 2022-04-17 23:43 UTC link

I'd find this question frustrating because it feels like a trap. I was looking for the trick -- was I missing something in the question that made the obvious approach untenable? No, the answer is simple, just add a way to multiply numbers with the multiply operator.

detinho 2022-04-17 23:45 UTC link

What kind of skill does this type of test measures?

I think the main ones are:

* How much about the language the candidate knows. Not the control flow and data types, but how to navigate and where to look for information. And that leads to bellow

* how quickly one can understand a codebase (at least part of it) and start delivering

What else?

If that's one of those "think out loud" tests it's possible to get a clue of how the candidate thinks, but it's not specific of this test.

ankrgyl 2022-04-17 23:55 UTC link

Author of the interview question here. I came up with the idea after working at the company for a couple months and realizing that the skill of "diving into an unfamiliar area of the code and quickly figuring it out" was very important for us. Database codebases are large and complex -- so much so that almost every new feature you work on for the first year or so feels a lot like doing the question.

Over the years of evaluating with it, we learned a lot about its quirks (both false positives and false negatives). At one point, someone got so frustrated that they threw their laptop on the floor. Happy to answer any questions about it!

victorronin 2022-04-17 23:59 UTC link

Got mixed feeling

- As people pointed out, it's advanced FizzBuzz (really advanced) - I can easily see a lot of people being unable to solve it, not because they can't do it, but because of a "performance anxiety". The bar here is quite high, and the result is binary (does it work or not). - I like that it is quite close to real life (that people have to read code, figure it out, write code). On another hand, again, what is not real, that you are parachuted into a unknown (quite big) codebase and expect to add a small feature in 3 hours.

kcarter80 2022-04-18 00:03 UTC link

Why couldn't a potential hire be given 5 minutes to think about a solution and then be asked what their plan is? What benefit is added by 36x-ing the time allowed that justifies putting the candidate through such pain?

k2xl 2022-04-18 00:31 UTC link

Somewhat got confused by the question given part 1. I didnt think we were asked to modify the source but just write a middle layer. Considering you want to stay in sync with the main codebase for memcache with updates and what not, my (potentially incorrect) solution was somewhat hacky

1. Client saves value in local memory. Then issues a command to update the number to a string version of the number (maybe with a flag telling any client to parse it as integer for get). Assuming setting a value is “safe”, this would cause other concurrent clients to error if they are trying to incr (according to example from part 1) 2. Client that did this update now multiplies that local variable. 3. Client updates value to final answer.

If a failure/crash happened you could still sort of retrieve the original value since it is a string version of itself.

Anyway it is hacky and sort of messes up if someone attempts to get the variable while it is a string. So I probably would fail this question.

abhishekjha 2022-04-18 00:44 UTC link

Why is the type1 programmer being looked down upon? I mean I am sure that I want to make sure how the lock implementation is. I also want to know if it is modular enough to be called somewhere or is it baked in the add step. I sure do want to multiple times read the add implementation and make sure there isn't a magic somewhere.

And finally this problem looks a lot like can you see a pattern!! I mean sure but a lot of people who might go to interview with standards of competitive programming might take the whole 3 hours because there's a lot to rule out.

I guess this is a fair question with a proper IDE and grep tools. The timing does look outrageous but if you are interviewing at a company which builds databases as a product, you better know how basic operations are provided.

Redis source code is fun to read as well.

icedchai 2022-04-18 00:47 UTC link

So I hacked it out in under a half hour. Basically, I wound up cloning some code paths instead of modifying "add_delta". Not sure if I'd pass or fail... but it is a good question to see if someone is comfortable navigating a new code base.

davidst 2022-04-18 01:05 UTC link

This is a great interview question I don't want to be 'that guy' by picking at what may be a detail but there is another response to look for from a candidate.

We should think very carefully about adding a multiplication command because it introduces a failure mode that may be unanticipated by the client. Code that previously worked could begin to fail after this command goes into use.

Specifically, if the client needs to revert a series of operations on integers, and if the operations are transitive, there is no need for a mechanism to ensure they occur in any particular order (the usual caveat about working within the limits of precision applies.) This holds true for addition and for multiplication, in isolation, but is not true if they are combined. Change the order and the end result will change. Adding multiplication puts a burden on the client to understand this risk and be explicit in the ordering.

Some people may argue that the client should already understand it and they have a point. We can't defend against every possible misunderstanding. I think there is a good discussion to be had on this question and if the candidate were to go there, it would be a favorable sign of experience on their part.

mihaitodor 2022-04-18 01:14 UTC link

To everyone praising how good this challenge is, calm down. There's nothing great about making somebody sweat for 3 hours during an interview. It's even worse if "someone got so frustrated that they threw their laptop on the floor" like the top comment claims.

Yes, it would be great to avoid hiring people who have a bad temper and tend to throw tantrums when nervous, but, then again, it's beyond me why anyone would need to prove they can cope with such pressure without breaking down. We're talking about a desk job here, which requires writing good quality code according to some requirements during normal working hours, not disarming a bomb with a timer attached to it.

loxias 2022-04-18 01:22 UTC link

I miss questions like this. Things that are closer to actually measuring "so, can you code?" and not if you can do CS puzzles, or how well you can shoehorn corporate "values" into answers.

I "passed the shit out of this question" and have failed my last several interviews... :( I miss 2010.

sanderjd 2022-04-18 01:52 UTC link

Yep, I love this kind of thing and it's waaay more similar to my actual job than the little self-contained problem on a "whiteboard" style.

The similar but different style question that I got (at Stripe, fwiw) in my recent job search that I also really loved was: Here's a failing test against a complex codebase; figure out what's wrong and then fix it. This flexes similar muscles I think: figure out enough of the flow of a complex codebase to understand where the problem manifests, and how to modify things to fix it without breaking other stuff. The really nice thing is: if all the tests pass at the end, you've done it. Then, time allowing, you can go work on improving the fix; making it more consistent with the architecture, etc.

cafxx 2022-04-18 01:53 UTC link

> Via its incr and decr commands, memcached provides a built-in way to atomically add k to a number. But it doesn’t provide other arithmetic operations; in particular, there is no “atomic multiply by” operation. Your programming challenge: Add a mult command to memcached.

Protip for people in junior roles: if you're interviewing for a more senior position, the correct answer would *not* be to jump in straight and waste 3 hours implementing something that then you have to maintain forever.

The best answer, from an *engineering*[1] perspective, would instead be noticing (or knowing) that memcached supports a CAS command (https://github.com/memcached/memcached/wiki/Commands#cas) that would allow to implement equivalent functionality without changes in memcached, and try to confirm why that would not be a viable solution. If, and only if, CAS is confirmed not to be a viable solution (e.g. excessive contention, unacceptable pX latency, ...) then you should spend the 3 hours (+ all the maintenance effort required until the end of life for that solution).

The risk, in case you jump acritically on the solution, is to show you did not spend any time trying to actually understand the problem and you did not consider the pros and cons of viable alternatives (and this is a problem both during an interview, as well and especially when you're doing actual work), something that is normally frowned upon in senior roles.

Obviously, being an interview, it's all play pretend so you'll eventually have to complete the coding exercise, but if I was interviewing you for a senior position and you skipped the part above it would be a pretty big red flag (same in the unlikely case I were to ask to implement some functionality that is commonly found in the standard library of most programming languages: huge red flag if you don't ask why the functionality provided by the standard library is not a viable solution).

[1]: w.r.t. software engineering being "programming integrated over time" (https://adamj.eu/tech/2021/11/03/software-engineering-is-pro...)

hoosieree 2022-04-18 02:11 UTC link

"Chesterton's Fence" is pragmatic for getting things done quickly, but I hope people actually come back later to decide if the fence should stay or go.

Leaving fences without questioning why they exist builds tech debt.

elisbce 2022-04-18 02:46 UTC link

This is far from a great engineering interview question, let alone the best.

1. This question is heavily biased towards specific software experience and familiarity with the domain and tooling, while at the same time too shallow in terms of algorithmic and logical depth.

It is like asking how to parse a CSV file in Fortran. The difficult part is not the problem per se, it is picking up an unfamiliar language and tooling on the spot.

For example, someone from Windows background who wasn't familiar with the memcached / Linux environment and tooling / Messy open-source codebase might find it difficult to adapt within the time limit. That doesn't automatically make them bad coders. It is like requiring Emacs and DVORAK keyboards for coding at interviews -- In theory it's all the same, but it's cumbersome and slows you down if you are not familiar.

Challenges like this during interviews can lead to high false negatives. People might get stuck on small side things and not working on the main thing enough.

2. This question takes too much time to set up and complete.

Interviewers don't have three hours to wait. Interviewees can probably only do one such problem during an onsite and nothing else. Are you going to make a judgement and decision solely based on the performance of this one challenge? I don't think that's a good idea.

Also the interviewer needs to explain everything. For a three-hour challenge, this is at least 15 minutes time doing nothing but setting the problem up.

3. This challenge is actually not that great to identify senior / great coders while mediocre coders with specific experience can pass easily.

vesche 2022-04-18 03:10 UTC link

Thanks for sharing this. It took me less than an hour to complete and I thought it was pretty fun. These sort of interview challenges that involve rapidly diving into a foreign codebase are really great, but it has to be done correctly. I once frustratingly & embarrassingly failed a live coding interview where I was asked to fix some sort of linked list issue in a fairly large C code base that wouldn't compile. I much prefer a challenge that involves implementing a new feature in a working code base (like this memcached question) as it's closer to reality and will also provide a better experience for the candidate.

trinovantes 2022-04-18 05:48 UTC link

I think I've been reading too many interview questions lately that I originally thought this was a trick question that required implementing mult with only the provided incr

I like that this was a more of an engineering question about diving into an unfamiliar codebase than a gotcha math/algorithm question

gorgoiler 2022-04-18 08:02 UTC link

Type -1 candidates quit on the spot when they discover that memcached has, in the years since they last worked with it, been bastardized to do things other they GET and SET!

The beauty of memcached in the 2000s was that it felt extremely opinionated about features — that is to say, it didn’t have any.

That bool incr argument in the source code feels like a hint from the authors. The arithmetic feature was meant to do two things and two things only, represented by I/D = +/- = true/false. Add (pardon the pun) any more operations and here be dragons. In particular once you add MULT, some clown is going to ask for DIV, and so are you now going to convert ints to floats or force integer division on everyone? Let’s place bets on how long until we get a “bug” report that 12,999,999 DIV 10 should be 13 not 12.

Maybe I’m being unfair. The integer increment thing in memcached seems useful. The useful part of it is the fact that it increments atomically, not that it does the heavy lifting of adding one for you :P If N people increment it you get a number that is N bigger. “Add 1” is also a pretty easy thing to get consistent if you have two people contending for a lock.

If it were a strongly typed language it would have a type like Counter (not Number) and it makes no sense to multiply a counter. The hint is also there in the INCR and DECR commands. They are probably not called ADD and SUBTRACT for a reason.

Feature rejected! Now let’s go code up MULT anyway :)

tomtung 2022-04-18 14:17 UTC link

My previous employer used something very similar: either adding small features or fixing known bugs of a past build of some open source software in 1-1.5hrs. We prepared one such interview question for each supported language (C++, Python, and Java), and, to help calibration, each question consisted of a series of requirements that required progressively more complex changes.

Both interviewees and interviewers seemed to like these questions. I do hope this approach gets more adoption in the industry. It takes more time to prepare, but the high-quality signals it provides are worth the effort imo. Such questions are also harder to leak compared to typical whiteboard coding questions and thus more reusable too.

Syonyk 2022-04-17 23:50 UTC link

It's "Advanced FizzBuzz."

"Can you understand a complex code base, figure out how to zoom in on the section of interest, and add a function?"

Far, far too many people interviewing for coding positions can't do that. Though I question how many could whip out FizzBuzz in 5 minutes and would then fail the more complex version. At some level, either you can code, or you can't. And, importantly, at some point in your career (if you go down the standard management track), you will typically lose the ability to code. If you've not done it in 5 years, you probably can't do it, in a practical sense. Not that you can't re-learn, but you can't just jump into a coding interview and ace it, either.

If you find yourself at a point in your career where coding interviews are a thing, "having a side hobby project that requires coding" is a very useful way to be really quite good at coding interviews. Plus, if it's your hobby project, there's no "Hrm... can I talk about that?" sort of problems when you're asked about a time you X'd with Y. You can talk about your personal hobby project absolutely as much, and in depth, as you want.

teraflop 2022-04-17 23:50 UTC link

This might just mean that you've been overly conditioned to expect bad interview questions that do rely on a "trick". But if so, I'm sure you're far from the only person in that position. Would you be less frustrated if it came with a disclaimer, along the lines of "this is not a trick question"?

(I realize this might sound sarcastic, but I'm serious. I think the way interview questions are presented is very important, and often overlooked.)

teraflop 2022-04-17 23:59 UTC link

I'd say your second bullet point encompasses a number of sub-skills, such as:

* Understanding common coding patterns, and inferring design intent from them

* Quickly prioritizing "critical" vs. "nice-to-have" components of a desired feature (and reprioritizing as you learn more about the implementation constraints)

* Being able to take a partially-complete or slightly buggy implementation, and quickly identify what's wrong with it (e.g. by interpreting compiler errors or using a debugger)

* Gaining confidence in the correctness of code by spending a reasonable amount of time on testing, without going overboard

avip 2022-04-18 00:01 UTC link

The skill of "getting something done without breaking anything" which is basically our profession.

ed25519FUUU 2022-04-18 00:05 UTC link

This is the right way to handle this problem. Everything after 5-10 minutes waste both your time and the interviewer’s time. There’s nothing you can discover that’s important after walking through their plan other than to figure out if they are familiar with code bases like the one you’re using.

davidw 2022-04-18 00:12 UTC link

"They gave him an intelligence test. The first question on the math part had to do with boats on a river: Port Smith is 100 miles upstream of Port Jones. The river flows at 5 miles per hour. The boat goes through water at 10 miles per hour. How long does it take to go from Port Smith to Port Jones? How long to come back?

Lawrence immediately saw that it was a trick question. You would have to be some kind of idiot to make the facile assumption that the current would add or subtract 5 miles per hour to or from the speed of the boat. Clearly, 5 miles per hour was nothing more than the average speed. The current would be faster in the middle of the river and slower at the banks. More complicated variations could be expected at bends in the river. Basically it was a question of hydrodynamics, which could be tackled using certain well-known systems of differential equations. Lawrence dove into the problem, rapidly (or so he thought) covering both sides of ten sheets of paper with calculations. Along the way, he realized that one of his assumptions, in combination with the simplified Navier-Stokes equations, had led him into an exploration of a particularly interesting family of partial differential equations. Before he knew it, he had proved a new theorem. If that didn't prove his intelligence, what would?

Then the time bell rang and the papers were collected. Lawrence managed to hang onto his scratch paper. He took it back to his dorm, typed it up, and mailed it to one of the more approachable math professors at Princeton, who promptly arranged for it to be published in a Parisian mathematics journal.

Lawrence received two free, freshly printed copies of the journal a few months later, in San Diego, California, during mail call on board a large ship called the U.S.S. Nevada. The ship had a band, and the Navy had given Lawrence the job of playing the glockenspiel in it, because their testing procedures had proven that he was not intelligent enough to do anything else."

eyelidlessness 2022-04-18 00:14 UTC link

If I encountered this test, here’s what I’d think (or hope) is being evaluated:

- Do you understand the problem, or seek better understanding if not? (Obviously the problem here isn’t extrapolating arithmetic, but identifying the importance of an atomic operation.)

- Do you recognize the value of the change, or question it if it feels non-obvious?

- How do you think about approaching an unfamiliar codebase/code path?

- How do you think about the challenges you encountered while working on the problem?

- What else felt important to you that I’m not looking for?

All of these questions provide a lot more information than “can you write code?”

Especially meaningful for evaluating actual fit is reactions to walking into pre-existing code. In fact I think this has been, at least subconsciously, my best heuristic for assessing colleagues’ skill maturity. “Juniors” will stare at a problem or ask a lot of easily answered questions; “mid level” devs will bang their heads trying to answer without asking; “senior” devs will have a good intuition for which challenges are discoverable and which are best solved by asking a human or a google or whatever, or at least for recognizing the distinction after some time exploring the problem.

theamk 2022-04-18 00:23 UTC link

Because the ultimate goal is code, not the plan?

I have seen people who can talk very nicely, but are lost once they actually have to touch the code. I have also seen people who are really bad at articulating their plans, but are OK with coding them.

js2 2022-04-18 00:25 UTC link

I would pass the shit out of this question because it's right in my wheelhouse, but I don't consider myself a particularly exceptional programmer. I have a CS degree, but I'm positive I'd fail a FAANG interview w/o advance prep. I'm really comfortable at modifying existing code[1], gluing together existing solutions, and know enough C to get through this question.

But the OP says this:

> When you’re maintaining a large codebase, there are always going to be codepaths you don’t fully understand

Ugh... I hate modifying code I don't understand. That doesn't mean I need to understand the entire code base, but if I'm modifying a portion of the code base, I'm loath to touch it till I understand what it's doing.

Also, of all the work I do, I consider this the least expressive of my ability. It's such a mechanical thing to do and doesn't require a whole lot of thinking?

So I guess I can see how this skill—for a job at your company—is necessary but in no way sufficient.

[1] e.g. https://github.com/git/git/search?q=jaysoffian&type=commits, https://github.com/google/breakpad/commit/6446cfcff088b8682b...

theamk 2022-04-18 00:32 UTC link

The result is not binary - you can have it fully working, or forget binary protocol, or syntax accepted but multiplication not happening; or correct code changes done, but code does not build...

That is one of advantages of longer questions (compared to 5 minute one): even if task is not fully done, there are plenty of other signals.

ankrgyl 2022-04-18 01:04 UTC link

Fun fact: we tried it out with Redis, but the question worked out to be too easy because of how nicely the codebase is laid out.

ww520 2022-04-18 01:16 UTC link

Yes, type1 is actually better than type2. Type2 is hyper-focus and is just blindly copying and pasting the incr portion as multi. Type1 actually is curious about the code base and wants to explore it a bit, to see how the locking is working and validate its correctness, to explore different approaches to see if incr can be used to implement multi. Type1 will end up learning a lot more about the codebase and do well in the long term.

t_mann 2022-04-18 01:21 UTC link

This seems so much more relevant than what FAANG companies are asking apparently (never did an interview with them), ie undergrad algorithms and data structures problems, but in a really tricky way. I wonder why your approach to interview questions isn't the norm.

jimbokun 2022-04-18 01:22 UTC link

I think the test is whether you can grep an unfamiliar code base to find the implementation of existing functionality, understand it, and modify it to add very similar functionality.

Like do the commands have to be registered somewhere? Is it a string mapping the operation name to a function pointer? A cascading if-then statement? Etc. etc.

It's just a test of diving in and understanding existing code in a relatively short amount of time.

jimbokun 2022-04-18 01:26 UTC link

> * How much about the language the candidate knows. Not the control flow and data types, but how to navigate and where to look for information. And that leads to bellow > * how quickly one can understand a codebase (at least part of it) and start delivering > What else?

Those things are really the vast majority of programming in a professional setting.

ip26 2022-04-18 01:26 UTC link

That was my reaction as well. To me, it seems like you cannot take it for granted that the existing locking, adequate for incr, is also adequate for mult.

It could be that in database circles, nobody ever uses any magic and only very strong locks are employed, and perhaps the candidate is supposed to be aware of this.

IggleSniggle 2022-04-18 01:32 UTC link

I went down a very similar train of thought, making the same assumption. I think this makes us “type 1” engineers: wrongly assume that we are not allowed to break the existing code contract, and attempt to use it to implement a new solution “over” the old. Extending without modifying.

I took that as a kind of lesson in and of itself. I’ve certainly had to face code monstrosities and cut through multiple layers to discover the simple rewrite before. If somebody had modified instead of extended sooner, if someone assumed the existing solutions were not so sacred, maybe a monstrosity could have been avoided in the first place.

jldugger 2022-04-18 01:35 UTC link

> Basically, I wound up cloning some code paths instead of modifying "add_delta"

This is more or less covered in part 2, and is indeed considered the path to passing.

sanderjd 2022-04-18 01:58 UTC link

Years of crappy tricky interview processes have broken our brains.

theamk 2022-04-18 02:09 UTC link

During interview, we are not modelling the whole process -- no one would tell a senior engineer just a single sentence "please implement mult command" -- there will be a longer preceding story: maybe the latency has to be very low, or it is a request from a stubborn customer, or you are profiling optimization... So for the reasons of time, we assume that the previous steps have been done, and it was decided that the mult command is the way to go.

If I were interviewer and a candidate would mention CAS command, I'd compliment them for their memcached knowledge, and tell that the it is not a viable solution. And this would not affect my evaluation of this stage one way or another.

3np 2022-04-18 02:22 UTC link

From the part2/spoilers:

> This challenge is particularly well calibrated for an interview because there is only one correct answer: “change bool incr to int opcode” (or anything isomorphic to that). The codebase and problem statement together very clearly imply that there are currently two arithmetic opcodes, and your job is to extend that to three arithmetic opcodes. [...] Cloning even one of these functions is probably suboptimal, but I might spend twenty minutes before realizing that.

I just completed it sans writing tests (took ~30min), considered and discarded that approach, instead duplicating the code-paths (leaving incr/decr untouched and instead making mult_ versions of everything). I did reuse the delta_result_type, though.

Briefly my reasoning was that this would make the fork easier to maintain against hypothetical future upstream changes and keep the logic simpler, while guaranteeing that I didn't miss to implement any particularity - compiler would complain about missing constants or functions as long as I covered entrypoints.

A bit of rule-of-three thinking: If in the future there would be even more arithmetic functions added, maybe it would be prudent to refactor and generalize parts of it? But not at this point.

Curious to hear if you agree with OP that my approach was incorrect or with me that it's equally valid (:

jameshart 2022-04-18 02:37 UTC link

This is a REALLY SOLID response to the question, and I'd hope it would get some strong 'hire' points.

But, to be fair, there's already technically this issue in the memcached API as described in the post, in that it supports both append and add, and "append 0" (on a value that add could also act upon) is effectively the same thing as "mult 10". If a field contains "1" and successive "add 1" and "append 0" commands come in, depending on what order they arrive in the result could be 20 or 11.

So I think the interviewer would be justified in saying 'yeah, let's assume we've evaluated that risk and we plan on adding some really thorough documentation warning people about that risk, so can you just go ahead and try and implement it?'

But absolutely, this was the thought that came into my mind when reading the spec too. Not enough developers think about APIs in terms of compositional, algebraic terms, and being able to see that adding 'multiply' and 'add' together at the same precedence in an API might cause trouble is a really valuable skill.

CamperBob2 2022-04-18 02:37 UTC link

Because there are people who are very, very good at bluffing their way through that first 5 minutes. If that's all it takes to pass the interview, your company is about to make a mistake, potentially a big one.

Jach 2022-04-18 02:41 UTC link

I guess it seems like you kinda chose this question by chance, but for new similar types of questions, do you now do them yourself (or get a coworker to try) to get at least an n=1 sample for how long it ought to take? I like to give a 2x margin of time over my / a coworker's time, so anything that takes us over 30 minutes is right out or needs to be simplified when we only get an hour with the candidate. An experience with an intern at my last job who struggled with our large codebase (mostly in the way of being comfortable despite not having or being able to fit everything in working memory all the time) led me to conclude the same as you, i.e. it's an important signal (at least for our company's work) to be able to jump in and effectively work in a somewhat large existing codebase.

I'm amused at the comments suggesting this is too easy (or your own suggesting the same for redis), I think if I tried this I would have filtered almost everyone, at least if they only had an hour (minus time for soft resume questions to ease them into it, and questions they have at the end). So many programmers have never even used grep (and that's not necessarily something to hold against them at least at my last job where the "As hire Bs and Bs hire Cs and Cs hire Ds" transition had already long since occurred). I've made two attempts at the idea though by crafting my own problem in its little framework, the latter attempt I used most involves writing several lines of code (not even involving a loop) into an "INSERT CODE HERE" method body, either in Java or JavaScript, and even that was hard enough to filter some people and still provide a bit of score distribution among those who passed. Still, I think it's the right approach if you have a large or complicated existing codebase, and even in the confines of an hour seems like a better use of time approximating the gold standard "work sample test" than asking a classic algorithm question.

zamfi 2022-04-18 02:55 UTC link

I think it depends on the need of the company. I’m reminded of Joel Spolsky’s “smart and gets shit done” adage (and then book): type 1 is smart, and you want some of these people.

But you don’t want people who, then faced with a task that can take 3 hours-and has been given time pressure that requires it to take 3 hours—instead spend 12 hours because they can’t live with the ambiguity of being uncertain that they’re using locks the right way.

The approach described in part 2 is highly opportunistic. You generally want to hire staff who can be opportunistic when necessary, even if that is not always the right approach.

jodrellblank 2022-04-18 02:58 UTC link

Having just gone through this question for fun, the codebase DECR command has this clipping code in it to avoid the value going negative:

       if(delta > value) {
           value = 0;
       } else {
           value -= delta;
       }

A caller reverting operations by sending the same values with the operations flipped around must already keep track that they didn't ask to drop below 0, or they may not get back to the original value.

Plus, the atomic update happens with a lock/release between each operation, so while you might get the same result at the end of your rearranged ordering, clients may see intermediate results and changing the order would change which values they see, which may or may not matter.

theamk 2022-04-18 03:22 UTC link

If "3 hours" is "such pressure" for you, then maybe some teams are not a good fit for you?

For example, I have broken the build in the past - and this prevents everyone else on your team from merging PRs. In this case the expectation was that I fix it "soon" - once I finish my current meeting/lunch/conversation.

If someone is prone to breaking down from pressure given 3 hour deadline, they would have a breakdown right there.

pphysch 2022-04-18 04:45 UTC link

The question appears to be highly relevant to the position. I would hire the candidate that completes the feature request over the 10x Programmer that cannot.

balls187 2022-04-18 05:47 UTC link

Never worked at a DB business, but feel confident that

> "diving into an unfamiliar area of the code and quickly figuring it out" was very important for us.

Universally applies to all software jobs.

What's I find interesting (based on my own personal history) is not only the ability to solve a task in an unfamiliar code base, but also do so without creating side effects (like say quadrupling the size of a binary since you incremented a poorly named constant that is reused as a size of a memory allocation by multiplying itself with itself).

andrewflnr 2022-04-18 07:09 UTC link

Given that they're specifically hiring for high-performance database work in C++, I think it's a appropriate to have a pretty dang high bar. For less-intense work, I would definitely want to formulate a less intense version of this style of problem.

Editorial Channel

What the content says

Structural Channel

What the site does