10 ms·

> Does your process involve invention? If so, please describe the three most recent things you have invented and why it was necessary to invent something new.

> Does your process involve invention? If so, please describe the three most recent things you have invented and why it was necessary to invent something new. If you're asked this in an interview, you can't respond "no". If I were being interviewed, I'd hear it as somewhat like "Do you like unicorns, which are awesome? If so, describe your three favorite awesome activities with unicorns." Which is fine, if you're on one of the teams that likes to innovate, but I'd just suggest that there's probably a more neutral phrasing that might allow a candidate to respond "I prefer to use existing solutions to problems, and here's why". Maybe: > The last three times you faced a "build or buy (/use open source)" situation, which did you choose, and why? Which may give you a better grasp of how the employee understands the economics of the situation, rather than just asking him to talk about the last three times he chose "build" given that choice.

coconutrandom 15y ago
Your second part is spot on, but the first question is not about the "yes/no" but the "why". Of course we invent, but the question is to find to what extent they are willing to go.
raganwald 15y ago
The question of bias is an excellent one to ponder. I agree that my phrasing is biased, but so is: The last three times you faced a "build or buy (/use open source)” situation, which did you choose, and why? ...in a way, as it only covers places where there is a perception that there was a straight-up choice. One of the things I am interested in is places where the invetion-oriented folks didn’t perceive there was a buy/borrow option, because they had bought into a requirement that seemed to necessitate invention.
- ChuckMcM 15y ago
  When I was at Google I wished they had a few 'uncoders', people who made it their goal in life to leave the source tree with fewer lines of source than they found it. True story: I went to a talk given by one of the 'engineering elders' (these were low Emp# engineers who were considered quite successful and were to be emulated by the workers :-) This person stated when they came to work at Google they were given the XYZ system to work on (sadly I'm prevented from disclosing the actual system). They remarked how they spent a couple of days looking over the system which was complicated and creaky, they couldn't figure it out so they wrote a new system. Yup, and they committed that. This person is a coding God are they not? (sarcasm) I asked what happened to the old system (I knew but was interested on their perspective) and they said it was still around because a few things still used it, but (quite proudly) nearly everything else had moved to their new system. So if you were reading carefully, this person created a new system to 'replace' an existing system which they didn't understand and got nearly everyone to move to the new system. That made them uber because they got something big to put on their internal resume, and a whole crapload of folks had to write new code to adapt from the old system to this new system, which imperfectly recreated the old system (remember they didn't understand the original), such that those parts of the system that relied on the more obscure bits had yet to be converted (because nobody undersood either the dependent code or the old system apparently). Was this person smart? Blindingly brilliant according to some of their peers. Did they get things done? Hell yes, they wrote the replacement for the XYZ system from scratch! One person? Can you imagine? Would I hire them? Not unless they were the last qualified person in my pool and I was out of time. That anecdote encapsulates the dangerous side of smart people who get things done. Sometimes they are too smart and do too much. So when the question of 'invention' comes up I like to wrap it around discovery. Sort of 'Tell me about a time where you built something that you had no idea how to build it when you started.' Things I look for are how did you go about discovering the path? What resources did you engage? What options did you consider? When did you 'call the vote'[1] ? My experience has been that things built by two or three people, working as peers, are often much 'better' (meet the needs better, cover more cases, have a more consistent model) than things built by one person. [1] 'call the vote' - in parlimentary terms when continuing debate will not help you make a better decision, it is time to stop debate and to vote on the decsion. Good leaders look for this point, and move forward once all the voices have been heard.
  - raganwald 15y ago
    Marvellous anecdote and some incredibly sage advice about interpreteting someone’s evidence of how smart they are and how much they get done. Thank you.
  - rokhayakebe 15y ago
    Similar story here. The company I work for had a system that worked just fine, but apparently lots of things weren't done the right way, documentation was lacking etc... They decided to rewrite the whole thing, incorporate processes and after nearly 18 months of hard work they relaunch the app. That was the last time anything worked properly. Now we are left with a beautiful system that just doesn't work.
  - euroclydon 15y ago
    Your asking us to assume that an unspoken goal in that particular software development endeavor was to not grow the total amount of code or libraries or systems, unless absolutely necessary. But was it? What if minimal system growth was a goal, but weighted at 0.5 and just get something running was also a goal, weighted at 0.99, because there was lot of money to be made with a working system.
    - ChuckMcM 15y ago
      Actually I don't think I was asking that at all, if you read it that way then I didn't communicate it clearly. The topic of conversation here is interviewing, and the importance of trying to develop as qualified an understanding of a potential candidate as possible in an interview. Reginald posited the 'mother of all interview questions' around the question of invention and perhaps more subtly the question of building it yourself versus leveraging the work of others. Its a great question because it starts a lot of interesting discussions around how someone evaluates tasks they are given and allows them to talk about what tools they can bring to bear on those problems. I related that anecdote from Google because I gave more importance in my mind to 'invention' rather than 'discovery' before I went to work at Google. Google is, in my opinion, the technical equivalent of Mecca for invention. One of the things I learned from my time there was that you could go overboard on invention. Not simply 'not invented here' syndrome, but literally lowering the barrier to creating new systems so far, that the net result is a negative rather than a positive. (Google doesn't see it that way, which I understand too, this is simply an opinion after all). I practical terms you are absolutely correct that getting something running will have a weight. maintainability will have a weight, and maybe continuity will have a weight too. And if someone ponders those weights, gets some feedback to test their understanding of the relative importance of them, and executes based on that feedback, that is a very good thing indeed. The person I was listening too at Google either didn't do that, or didn't understand the implications of their choices with respect to the impact on the company, or perhaps the simpler answer was they just didn't think about it. Had they thought it through, I'm sure they would have mentioned it in their talk as the talk was supposed to be about best practices and that would have been a great point to get across.
ww520 15y ago
Exactly. Software design is a matter of tradeoff. Build vs buy is one of them.
joe_the_user 15y ago
Yes, All programming is inventing. But not all good programmers see programming as inventing. I'm not sure you wind-up better by weeding out those who don't programming as inventing.
giardini 15y ago
> If you're asked this in an interview, you can't respond "no". I don't see why not! It would save lots of time. This is a poor question as phrased. If you want to know about the developer's attitude toward reuse versus DIY, then simply ask that. The common usage of the word "invention" today invokes questions about intellectual property, patent rights, copyright et al - topics most developers would likely rather avoid.

coconutrandom 15y ago

Your second part is spot on, but the first question is not about the "yes/no" but the "why". Of course we invent, but the question is to find to what extent they are willing to go.

raganwald 15y ago

The question of bias is an excellent one to ponder. I agree that my phrasing is biased, but so is: The last three times you faced a "build or buy (/use open source)” situation, which did you choose, and why? ...in a way, as it only covers places where there is a perception that there was a straight-up choice. One of the things I am interested in is places where the invetion-oriented folks didn’t perceive there was a buy/borrow option, because they had bought into a requirement that seemed to necessitate invention.

ChuckMcM 15y ago
When I was at Google I wished they had a few 'uncoders', people who made it their goal in life to leave the source tree with fewer lines of source than they found it. True story: I went to a talk given by one of the 'engineering elders' (these were low Emp# engineers who were considered quite successful and were to be emulated by the workers :-) This person stated when they came to work at Google they were given the XYZ system to work on (sadly I'm prevented from disclosing the actual system). They remarked how they spent a couple of days looking over the system which was complicated and creaky, they couldn't figure it out so they wrote a new system. Yup, and they committed that. This person is a coding God are they not? (sarcasm) I asked what happened to the old system (I knew but was interested on their perspective) and they said it was still around because a few things still used it, but (quite proudly) nearly everything else had moved to their new system. So if you were reading carefully, this person created a new system to 'replace' an existing system which they didn't understand and got nearly everyone to move to the new system. That made them uber because they got something big to put on their internal resume, and a whole crapload of folks had to write new code to adapt from the old system to this new system, which imperfectly recreated the old system (remember they didn't understand the original), such that those parts of the system that relied on the more obscure bits had yet to be converted (because nobody undersood either the dependent code or the old system apparently). Was this person smart? Blindingly brilliant according to some of their peers. Did they get things done? Hell yes, they wrote the replacement for the XYZ system from scratch! One person? Can you imagine? Would I hire them? Not unless they were the last qualified person in my pool and I was out of time. That anecdote encapsulates the dangerous side of smart people who get things done. Sometimes they are too smart and do too much. So when the question of 'invention' comes up I like to wrap it around discovery. Sort of 'Tell me about a time where you built something that you had no idea how to build it when you started.' Things I look for are how did you go about discovering the path? What resources did you engage? What options did you consider? When did you 'call the vote'[1] ? My experience has been that things built by two or three people, working as peers, are often much 'better' (meet the needs better, cover more cases, have a more consistent model) than things built by one person. [1] 'call the vote' - in parlimentary terms when continuing debate will not help you make a better decision, it is time to stop debate and to vote on the decsion. Good leaders look for this point, and move forward once all the voices have been heard.
- raganwald 15y ago
  Marvellous anecdote and some incredibly sage advice about interpreteting someone’s evidence of how smart they are and how much they get done. Thank you.
- rokhayakebe 15y ago
  Similar story here. The company I work for had a system that worked just fine, but apparently lots of things weren't done the right way, documentation was lacking etc... They decided to rewrite the whole thing, incorporate processes and after nearly 18 months of hard work they relaunch the app. That was the last time anything worked properly. Now we are left with a beautiful system that just doesn't work.
- euroclydon 15y ago
  Your asking us to assume that an unspoken goal in that particular software development endeavor was to not grow the total amount of code or libraries or systems, unless absolutely necessary. But was it? What if minimal system growth was a goal, but weighted at 0.5 and just get something running was also a goal, weighted at 0.99, because there was lot of money to be made with a working system.
  - ChuckMcM 15y ago
    Actually I don't think I was asking that at all, if you read it that way then I didn't communicate it clearly. The topic of conversation here is interviewing, and the importance of trying to develop as qualified an understanding of a potential candidate as possible in an interview. Reginald posited the 'mother of all interview questions' around the question of invention and perhaps more subtly the question of building it yourself versus leveraging the work of others. Its a great question because it starts a lot of interesting discussions around how someone evaluates tasks they are given and allows them to talk about what tools they can bring to bear on those problems. I related that anecdote from Google because I gave more importance in my mind to 'invention' rather than 'discovery' before I went to work at Google. Google is, in my opinion, the technical equivalent of Mecca for invention. One of the things I learned from my time there was that you could go overboard on invention. Not simply 'not invented here' syndrome, but literally lowering the barrier to creating new systems so far, that the net result is a negative rather than a positive. (Google doesn't see it that way, which I understand too, this is simply an opinion after all). I practical terms you are absolutely correct that getting something running will have a weight. maintainability will have a weight, and maybe continuity will have a weight too. And if someone ponders those weights, gets some feedback to test their understanding of the relative importance of them, and executes based on that feedback, that is a very good thing indeed. The person I was listening too at Google either didn't do that, or didn't understand the implications of their choices with respect to the impact on the company, or perhaps the simpler answer was they just didn't think about it. Had they thought it through, I'm sure they would have mentioned it in their talk as the talk was supposed to be about best practices and that would have been a great point to get across.

ww520 15y ago

Exactly. Software design is a matter of tradeoff. Build vs buy is one of them.

joe_the_user 15y ago

Yes, All programming is inventing. But not all good programmers see programming as inventing. I'm not sure you wind-up better by weeding out those who don't programming as inventing.

giardini 15y ago

> If you're asked this in an interview, you can't respond "no". I don't see why not! It would save lots of time. This is a poor question as phrased. If you want to know about the developer's attitude toward reuse versus DIY, then simply ask that. The common usage of the word "invention" today invokes questions about intellectual property, patent rights, copyright et al - topics most developers would likely rather avoid.