thanks for sharing your experience..yes we are human and are bound to do mistakes. A good team player can admit mistakes..Subodh On 12 March 2011 13:44, Mike Haddon <m.haddon@xxxxxxxxx> wrote: > > Mark, and others. > > I have been following this thread with some interest because it is a > subject which I have some experience on both sides. I feel that most people > put too much into this subject. > > In my experiences as the person being interviewed I look forward to an > interview where the questions are technical but put into the context of a > situation that is indicative of a production or development environment. I > often ask the interviewer to put their question into that context. This > gives me a good idea of the interviewer's understanding of the question > itself and tells me if he/she looked it up or if they will understand the > answer. I also understand the importance of "knowing what I don't know" and > if I don't know I will indicate the resources I would use to find the answer > and I will also often ask the interviewer to answer the question > himself/herself. > > As the interviewer, I will usually spend the first 5-10 minutes getting to > know the person. Part of the criteria has to be whether the person will bond > with the team or not. Then I will put my questions in specific context, I.E. > "You receive a call from one of the application support team, he/she says > that the system is slow, what do you do?". In my experience this is very > common. I listen to their explanation of the process to isolate the issue > and sometimes give them direction, for example, if they indicate the use of > iostat, vmstat, top, ps, or some other method of isolating top sessions, > tell them "OK you find a process taking all the CPU, what next". It is this > experience that will tell you how deep the person really is. > > I know a lot of DBA's that are very very smart technically but get > frustrated and lost when it really counts and they have 7 people standing > behind them when the production environment is having issues. > > I would want someone with a good understanding of the architecture and the > database, but I also want someone who is always ready to learn something > new, knows what he/she doesn't know, willing to ask questions of the team, > willing to take on a challenge, and honest when they may make a mistake. > > As a perfect example, in my past life I managed a team of production > support db admins, system admins, and network admins. When hired, each > person was given direction on the to do's and not to do's. One day, a system > admin came into the office to explain that he violated one of these rules > and corrupted the shadow file on all of our database servers. These servers > were all over the globe from Germany to Toronto to London and Denver. We > gathered the team, I explained the situation to the VP and we spent the next > several hours correcting the situation. The next day he came into the office > and stated he was ready for whatever action I thought was warranted. > > To make my point I explained to him that I would not take additional action > because of two reasons. First, he came to me and the rest of the team when > he made the mistake and didn't try to hide it. Second, I knew he would never > make that mistake again. The rest of the team came together and we resolved > the issue with little to no effect on the servers. This admin turned out to > be one of the best on our team and always to supported anyone else on the > team. > > I may have gone way off topic but the point is that it is the person, their > ability to learn, and their understanding of what they don't know that is > sometimes most important to determine during the interview process. > > Mike > > > -- > //www.freelists.org/webpage/oracle-l > > > -- ============================== DO NOT FORGET TO SMILE TODAY ==============================