April 15, 2013 at 2:33 am
TravisDBA (4/12/2013)
Major,I understand exactly what your saying, but I cant address that particular aspect properly because I don't work with the end user directly. My laisons are more with the PM's. But I tend to agree with djackson, I expect people to have a pretty clear idea of what they want before they come and waste a lot of my time. Not that doesn't happen in the long run sometimes anyway as Lynn so aptly stated. However, if people would just do some research (legwork, google,wikipedia,etc.) beforehand a lot of that would be minimized. But you are never going to get rid of it totally and I fully understand that. 😀
...which brings us full circle back to my original point. If you're trying to hire someone who does need to think on their feet in a meeting (or set of meetings) with constantly evolving requirements, the interview needs to test exactly that ability. Your job apparently doesn't involve that, but the ones DJackson was describing do seem to have done. As a result, the interview techniques wouldn't have been appropriate for hiring you, but seem to have been perfectly reasonable for DJackson in those particular roles.
I also agree with all variations on the theme of "I'd expect a user to have some idea of what they want before they start asking" so long as it still recognises the user shouldn't have to be unreasonably technically literate. In practice, I'm happy to settle for the user having a clear idea of the problem and a conviction that "there must be a better way". I can work with that.
Semper in excretia, suus solum profundum variat
April 15, 2013 at 8:01 am
marat-oz (4/14/2013)
Steve Jones - SSC Editor (7/25/2008)
...We may ask about things we haven't solved, just to see if they approach it like us or have an interesting take...Seeking advice from the person who hasn't been hired yet, I believe, is ethically wrong. I know few cases when employers during the interview were asking such questions, getting the answers and not hiring people after all.:(
True story marat. I have also known people who have interviewed people in the past and have asked for "code examples" up front, and then kept and used the code, and did not hired the person after all. He told and showed the person he deleted it, but he simply recovered it from his recycle bin after the interviewee left. 😀
"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"
April 15, 2013 at 8:08 am
majorbloodnock (4/15/2013) If you're trying to hire someone who does need to think on their feet in a meeting (or set of meetings) with constantly evolving requirements, the interview needs to test exactly that ability. Your job apparently doesn't involve that,
Major,
No, I don't have to think on my feet daily with constant evolving requirements, I only manage about 50+ database servers.:-P Government environments are much stricter on the guideleines of where you can go or what you can ask in interviews, that is pretty much what I was saying. Once again, as stated multiple times before, the end user conversation that came up as a result of all this I can't really comment on because I don't work with the end user, only the PM's. 😀
"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"
April 15, 2013 at 8:09 am
majorbloodnock (4/12/2013)
My turn to apologise for not being entirely clear.I fully expect the business users I talk with to know what they want. However, I do not expect them to know (or necessarily fully understand) what they're actually trying to achieve. Translating a user's wishlist into a design that recognises the underlying business processes is a skill in itself, and if users could do it, they'd quite possibly be in a different career.
Personally, I find my users are very open and quick to give me what they want. However, I usually have to burrow quite a bit to get to the underlying requirements, and as soon as I explain the way I'm thinking, they will like as not come back with "Oh, I didn't realise you could do that! Well, in that case....". At that point we enter round two where they're reconsidering their request in the light of more possibilities than they expected.
None of this is me giving up on end users, and nothing they're asking me is a trick question, but it does require me to think on my feet a great deal.
SMILE
I see that frequently too. My best users are those that are willing to let me play devil's advocate with them for a minute. They also now know when that isn't necessary, and in those cases tell me up front "I need exactly this and nothing more". The worst users tell me to provide something, and when I start asking questions respond with "I don't want to be a bother." For those who are willing to discuss things, the number of "I didn't know you could do that" comments have gone down considerably due to seeing I can usually do what they want, and sometimes I can do things they didn't even think to ask.
Those are fun tasks to work on.
Dave
April 29, 2013 at 10:10 am
Wow. Many issues and comments.
One issue concerning asking applicant how to resolve a situation. That's how I got my first two jobs in the field. In each case, I replied I'd have to look it up. In each case, I sent an email back to the interviewer. In each case, the interviewer was impressed that not only did I know where to go to find the answers, but that I had the gumption to follow up the interview with the necessary research and then an email detailing the answer. So that got me hired each time. The issue was standing out from the crowd.
Concerning user developer relationships. The biggest problems in this agency derive from the fact that the contractor's developers do not communicate with the users, and on the rare occasions they do they don't listen to and try to understand what the users are trying to say.
Example. Exisiting code on a web site produces an output which states such and such. The user wants the output changed slightly to add a line of text. A system change request is submitted for that work.
In the course of viewing the code, the developer on the task, who is not the original developer that designed the web app, realizes that the OD generated each type of output using a different function. But since the majority of the output is the same, best practice would call for one function to construct the output calling other functions to supply those parts of the output that differ with each circumstance.
However, instead of getting back to the subject matter expert to explain the situation and request to modify the System Change Request and the Plan of Action and Milestones to show the additional work and its rationale, (at which time he would have found out that the agency could not afford a total fix, and right now it was imperative that this little change be deployed to production as it was affecting the warfighter), he takes it on himself to implement these changes.
However, he makes errors in making the changes which results a lot of endproducts which had been working just fine up to that point, becoming totally bolluxed, with the SME, their management, and the developer's management not having any understanding why something that was working fine, without any problems that no one was authorized to touch, is suddenly broken.
No only has the original problem not been solved, but the government ended up paying for a great deal of unauthorized work has been performed in such a shoddy fashion that now nothing is working, and will cost the government even more to get it put to rights.
This all came about because a developer who did not communicate with the user and chose to make changes without running it past his management or the SME. Thanks to him, the production application is still waiting for that one little improvement should have taken 2 days, more than 1 year later, and the each of twelve deployments to test has been found in error in new places that were working just fine in production.
So it is imperative that the developer talk to the users to not only understand what they probably cannot articulate, but they also need to understand the user's complete situation so that they don't propose or worse carry out tasks for which the users can't afford the time or the money or both.
April 29, 2013 at 10:33 am
ejoell 66477 (4/29/2013)
Wow. Many issues and comments.One issue concerning asking applicant how to resolve a situation. That's how I got my first two jobs in the field. In each case, I replied I'd have to look it up. In each case, I sent an email back to the interviewer. In each case, the interviewer was impressed that not only did I know where to go to find the answers, but that I had the gumption to follow up the interview with the necessary research and then an email detailing the answer. So that got me hired each time. The issue was standing out from the crowd.
One thing I will say about open-ended questions is that they tend to be asked to differentiate you from the pack. Government interview scripts notwithstanding, in most cases the open-ended questions get asked to those you actually think have potential: I know I might skip them if someone is clearly not a fit. I personally know I've made it "past the gauntlet" if the interviewer is attempting to find out what I am made of: doesn't mean I will always get the job, but it usually means I'm doing better than the average candidate.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
Viewing 6 posts - 91 through 95 (of 95 total)
You must be logged in to reply to this topic. Login to reply