5 ms·

>One problem we just encountered in production that I'm trying to work into a prompt was our impression generation created a large amount of duplicates. Identif

>One problem we just encountered in production that I'm trying to work into a prompt was our impression generation created a large amount of duplicates. Identifying the duplicates and eliminating them takes some simple verbal requirements but has a lot of depth. If they cant't do max/min/mean/median, they surely can't do answer that (which our least senior developer was able to do, with guidance (mostly on optimization)). Does that problem not require separate thought processes though? In terms of a max/min/mean/median style problem, the candidate needs to come up with an algorithmic solution to find those values. In the later case of finding duplicates, there is minimal (depending on problem complexity, I suppose) amount of algorithmic complexity and the focus is more on data structures; for instance, does the candidate know they could use a data structure like a hashmap or variant to find unique items with the drawback being an additional storage unit. So, I guess what I'm trying to trace back to is how you say if they can't answer one then surely they can't solve the other, but (while relatively 'simple' problems) I'd argue they take different mindsets to solve. Obviously in the grand scheme of things one mindset works for both, but in this it can vary a bit. Anyway, late-night thoughts so hopefully that's not a jumbled-up response.

eximius 8y ago
I agree with what you've said, though you have some mistaken assumptions. They aren't exact duplicates. Instead, the code to send an impression was firing repeatedly, so it'd be more like that person refreshing the page once per second thousands of times (except the page content never changes if they don't refresh). At it's most basic, you're essentially just finding chains of impressions based on lag from the last impression. In practice, we also need to maintain data integrity (foreign keys) and deal with several other issues stemming from common cases where the assumption 'if they are within X seconds, count as duplicate' doesn't hold. So you could completely ignore performance and still have a question that could prompt a lot of discussion with a candidate (though performance should be part of that discussion). I'm not sure if we'll end up using it due to the relatively large amount of baggage associated with the problem (table layout and business requirements), I've just been toying with reducing the problem down to a simpler prompt that would be feasible. I'm fairly new to interviewing/hiring, but I really like questions that cut across multiple 'areas of competency' and are amenable to asking followup questions ('what if we wanted to add X?'). Algorithmic questions have their place, but have less day-to-day relevance. We can teach algorithmic stuff on the job.
TangoTrotFox 8y ago
A self declared mathematician that can't tell you what the answer to 4x + 7 = 19 is, is not going to be a good mathematician even though it's generally not the case that solving trivial algebraic problems makes up any meaningful chunk of a mathematicians daily work. I think your point would be fair for more complex problems, but getting the max of a list is something anybody of a logical mind could easily do even without knowing any formal programming language. And for those that do know a formal programming language it comes down to the most incredibly trivial basics of a language - comparison/variable/iteration. In other words a self declared software developer who can't tell you how to get the max of a list is not going to be a good software developer.
ryanobjc 8y ago
Reading this, one could be confused into thinking that you’re arguing that a developer shouldn’t have to prove they can write find max of a list. Is this task too below them? Does it not adequately demonstrate knowledge? What else? I think what you’re might be missing is the basic fact that programming is so stupid lucrative, especially compared to the other jobs that are out there, people will do anything to get these jobs. I’m pretty sure you want your new hire to know HOW the magical library list.max is written. Writing code is surely more than piecing together other people’s utility functions and ideas? By way of analogy, should your new EE hire be able to compute basic ohms law voltage drop over a resistor? We teach kids this formula. Is this knowledge too below a senior electrical engineer to still know? Of course not. Finally, someone’s attitude towards answering these questions will tell you a lot about what kind of person they are to work with. If they are surely and refuse to implement list.max, well then, what will their attitude be when it comes to grungy code tasks?

eximius 8y ago

I agree with what you've said, though you have some mistaken assumptions. They aren't exact duplicates. Instead, the code to send an impression was firing repeatedly, so it'd be more like that person refreshing the page once per second thousands of times (except the page content never changes if they don't refresh). At it's most basic, you're essentially just finding chains of impressions based on lag from the last impression. In practice, we also need to maintain data integrity (foreign keys) and deal with several other issues stemming from common cases where the assumption 'if they are within X seconds, count as duplicate' doesn't hold. So you could completely ignore performance and still have a question that could prompt a lot of discussion with a candidate (though performance should be part of that discussion). I'm not sure if we'll end up using it due to the relatively large amount of baggage associated with the problem (table layout and business requirements), I've just been toying with reducing the problem down to a simpler prompt that would be feasible. I'm fairly new to interviewing/hiring, but I really like questions that cut across multiple 'areas of competency' and are amenable to asking followup questions ('what if we wanted to add X?'). Algorithmic questions have their place, but have less day-to-day relevance. We can teach algorithmic stuff on the job.

TangoTrotFox 8y ago

A self declared mathematician that can't tell you what the answer to 4x + 7 = 19 is, is not going to be a good mathematician even though it's generally not the case that solving trivial algebraic problems makes up any meaningful chunk of a mathematicians daily work. I think your point would be fair for more complex problems, but getting the max of a list is something anybody of a logical mind could easily do even without knowing any formal programming language. And for those that do know a formal programming language it comes down to the most incredibly trivial basics of a language - comparison/variable/iteration. In other words a self declared software developer who can't tell you how to get the max of a list is not going to be a good software developer.

ryanobjc 8y ago

Reading this, one could be confused into thinking that you’re arguing that a developer shouldn’t have to prove they can write find max of a list. Is this task too below them? Does it not adequately demonstrate knowledge? What else? I think what you’re might be missing is the basic fact that programming is so stupid lucrative, especially compared to the other jobs that are out there, people will do anything to get these jobs. I’m pretty sure you want your new hire to know HOW the magical library list.max is written. Writing code is surely more than piecing together other people’s utility functions and ideas? By way of analogy, should your new EE hire be able to compute basic ohms law voltage drop over a resistor? We teach kids this formula. Is this knowledge too below a senior electrical engineer to still know? Of course not. Finally, someone’s attitude towards answering these questions will tell you a lot about what kind of person they are to work with. If they are surely and refuse to implement list.max, well then, what will their attitude be when it comes to grungy code tasks?