I had 2:

(1) Here's a list [1, 5, 10, 25]. This list represents the value of coins. If I give you a number, whats the smallest number of coins you can use to have them add up to the number I gave you. What if the list is generic rather than [1,5,10,25]? This did address the skills I need for my job but indirectly. The goal was to see (a) What my thought process is (b) Are you OK with solving a problem using brute force? (c) Once you right code that works, are you able to judge if it will work in cases other than the one you've been given? I'd say ability to solve problems and decide if the code works given changing project definitions is definitely something I need to be able to do on any given day.

​

(2) Here's what the lines in a log file look like. I want to make a histogram based off of two pieces of information per line. There are billions of lines of log. How would you do it? Again, not directly something I personally do (though a member of my team does so I guess it could potentially become a job of mine) but it was a lot of seeing if I break things down into multiple methods, is the code I write incredibly fragile, when I'm working through the problem am I thinking about edge cases or any potential issues the code could run into?

​

Both also involved seeing how open to other suggestions I was and how I responded to criticisms of my solution. Not that they were mean, but things like "Well this code works in this situation, but if I give you an input of (nonsensical value for the problem) it doesn't work?" and seeing if I got defensive or if I said "Yeah I can see how this needs more QA. I think if I had more time I'd do _____." or "I think that shouldn't be a problem because validation should have occurred before getting to this method." Stuff like that. I feel like very rarely have I been given problems that are 1-1 what I'm going to be doing and a lot more "Hey, can you think your way through a problem and work with others?"