| dan_oz ( @ 2006-10-10 10:57:00 |
An interesting interview
Long have I scorned those that say "I can solve *some problem* I just can't explain how I did it", or any variation of this that includes "showing your work". This situation is most often resultant from a limited number of data bits or variables, a limited number of potential configurations, and a clearly intuitive answer or solution. If you can't explain what you did, you didn't solve the problem, you just combined the given bits until you got something that looked right - which is why the best tests that I took in college would yield numerically similar answers if you were just plugging and chugging with data bits and didn't understand the problem.
Thing is, I now believe there's another slant to this problem: vocabulary. Someone may understand a problem, be able to solve the problem, and could explain to YOU how to solve the problem - but they might not have the vocabulary to do so. I happen upon this thanks to an interview I had yesterday.
I walked into Duke's OIT building and asked for someone in a department that I'd seen posting some noteworthy jobs. They were nice enough to talk to me and even sat down with me for 45 minutes or so for an impromptu interview. There's a manager type and a tech type. We discuss what I'd created for UVA, what systems I was familiar with, so on and so forth. Things seem to be going pretty decent. Finally, the manager type looks at the tech type and turns him loose.
"So I see you use Object Oriented Programming - tell us about how you got into that."
Vague. I'm not sure what he wants so I describe some of the objects that I've developed and used doing webstuff. At one point, I mentioned how I create objects to handle all of the tasks relevant to certain bits of data. I include an example where I go to a "People" object and nab database ids for all of the "Groups" that they belong to. He asks, "Why couldn't you return an array of Group objects instead?" Well, I certainly could. Is it called for? Do I need to load up an array of group objects that have all their data set, or do I just need the ids? What am I trying to do, here?
"Most of what you've talked about so far has been from a Domain standpoint. What about Controllers and Views and such."
Alright, here is where I don't know what to say. I don't know the theoretical abstracts for these terms. I know that controllers handle requests from the users - they DO things. Views are essentially display templates. But what's the guy asking? I decide to short circuit the conversation. I say something to the effect of,
"I'm not sure what you're looking for, really. I don't have a CS degree and a lot of the theoretical background to Object Oriented programming was never presented to me in any way but the practical. I've heard both of those terms, and even worked with them when considering things like small 'Ruby on Rails' projects, but I can't say that any project I created from the ground up has dealt, specifically, with things like 'Controllers' or 'Views'."
The tech-type responds with:
"Yeah, for the position we have open we need someone who has this stuff as a second nature. We've written code that would have you lost in a heartbeat, and we've got junior level people that are learning about it - but I'm already working with them. For this position we need someone who understands all these concepts."
At this point, I like to flatter myself that the manager type threw a "What the fuck are you SAYING?" look. The tech type lamely follows up with, "Don't get me wrong - you've got valuable skills that we don't want to lose, I just don't think that this position is the one that you're looking for."
They then went on to tell me about a position in THEIR networks group that they're going to try to get me in on. I guess. I'm (re)learning on this job search that your unemployment isn't as important to anyone as it is to you, and tons of people would LIKE to help and INTEND to help - but actual followthrough is a rare and precious thing.
Back to the topic at hand, though, I suddenly felt like a baseball player with a high batting average that can't explain how I hit a curve ball. Well, I COULD if I could just articulate what it is that I do, but I plainly didn't speak the same language as the guys that wrote the baseball book. So, yeah, I was on the flip side of an issue that I'd always considered annoying. At least I clearly knew that the problem was vocabulary and terminology rather than experience, skill, or poor results.
Oh well, I hope they find what they want. In the meantime, I'm redoing my resume. It now reads like this:
*****
Dear potential employers. I am, essentially, an IT application developer. I have been given numerous tasks by my current employer and have completed all of those tasks in a satisfactory and timely manner. Occasionally on short deadlines! I have also identified problems on my own, and created tools that solved those problems. If you don't believe me, ask my current employer.
If you would like an independent problem solver in your business venture, let me know.
Word.
Long have I scorned those that say "I can solve *some problem* I just can't explain how I did it", or any variation of this that includes "showing your work". This situation is most often resultant from a limited number of data bits or variables, a limited number of potential configurations, and a clearly intuitive answer or solution. If you can't explain what you did, you didn't solve the problem, you just combined the given bits until you got something that looked right - which is why the best tests that I took in college would yield numerically similar answers if you were just plugging and chugging with data bits and didn't understand the problem.
Thing is, I now believe there's another slant to this problem: vocabulary. Someone may understand a problem, be able to solve the problem, and could explain to YOU how to solve the problem - but they might not have the vocabulary to do so. I happen upon this thanks to an interview I had yesterday.
I walked into Duke's OIT building and asked for someone in a department that I'd seen posting some noteworthy jobs. They were nice enough to talk to me and even sat down with me for 45 minutes or so for an impromptu interview. There's a manager type and a tech type. We discuss what I'd created for UVA, what systems I was familiar with, so on and so forth. Things seem to be going pretty decent. Finally, the manager type looks at the tech type and turns him loose.
"So I see you use Object Oriented Programming - tell us about how you got into that."
Vague. I'm not sure what he wants so I describe some of the objects that I've developed and used doing webstuff. At one point, I mentioned how I create objects to handle all of the tasks relevant to certain bits of data. I include an example where I go to a "People" object and nab database ids for all of the "Groups" that they belong to. He asks, "Why couldn't you return an array of Group objects instead?" Well, I certainly could. Is it called for? Do I need to load up an array of group objects that have all their data set, or do I just need the ids? What am I trying to do, here?
"Most of what you've talked about so far has been from a Domain standpoint. What about Controllers and Views and such."
Alright, here is where I don't know what to say. I don't know the theoretical abstracts for these terms. I know that controllers handle requests from the users - they DO things. Views are essentially display templates. But what's the guy asking? I decide to short circuit the conversation. I say something to the effect of,
"I'm not sure what you're looking for, really. I don't have a CS degree and a lot of the theoretical background to Object Oriented programming was never presented to me in any way but the practical. I've heard both of those terms, and even worked with them when considering things like small 'Ruby on Rails' projects, but I can't say that any project I created from the ground up has dealt, specifically, with things like 'Controllers' or 'Views'."
The tech-type responds with:
"Yeah, for the position we have open we need someone who has this stuff as a second nature. We've written code that would have you lost in a heartbeat, and we've got junior level people that are learning about it - but I'm already working with them. For this position we need someone who understands all these concepts."
At this point, I like to flatter myself that the manager type threw a "What the fuck are you SAYING?" look. The tech type lamely follows up with, "Don't get me wrong - you've got valuable skills that we don't want to lose, I just don't think that this position is the one that you're looking for."
They then went on to tell me about a position in THEIR networks group that they're going to try to get me in on. I guess. I'm (re)learning on this job search that your unemployment isn't as important to anyone as it is to you, and tons of people would LIKE to help and INTEND to help - but actual followthrough is a rare and precious thing.
Back to the topic at hand, though, I suddenly felt like a baseball player with a high batting average that can't explain how I hit a curve ball. Well, I COULD if I could just articulate what it is that I do, but I plainly didn't speak the same language as the guys that wrote the baseball book. So, yeah, I was on the flip side of an issue that I'd always considered annoying. At least I clearly knew that the problem was vocabulary and terminology rather than experience, skill, or poor results.
Oh well, I hope they find what they want. In the meantime, I'm redoing my resume. It now reads like this:
*****
Dear potential employers. I am, essentially, an IT application developer. I have been given numerous tasks by my current employer and have completed all of those tasks in a satisfactory and timely manner. Occasionally on short deadlines! I have also identified problems on my own, and created tools that solved those problems. If you don't believe me, ask my current employer.
If you would like an independent problem solver in your business venture, let me know.
Word.