July 2, 2010 at 6:58 am
I think most DBA's are of the accidental variety rather then the "I want to be a DBA when I grow up" variety.
Being a DBA or programming in general, is a journey and experience is the greatest teacher. I think the most important skill for either, is the ability to adapt and learn, so that you can solve the problems at hand. Efficiency will come as skills increase.
July 2, 2010 at 7:02 am
Grant Fritchey (7/2/2010)
I'm not so sure about testing. The interview process where I work includes considerable time at the white board. We talk about queries & table structures & TSQL. I'll put up queries with problems and see if the interviewee can solve them. It's not testing. It's interviewing. It's assessing their attitude, aptitude, knowledge, approach... All of this makes up a good hire. Slapping people in front of a test... not so much.I remember one interview I did years ago where I got put in front of a test, filled it out, and the interviewer said "Pretty good, but you missed this easy one here." I don't remember the details, but they had a logic error. I walked them through the correct solution, showing where their method broke down. They got all excited because they actually had the bad code in production. Another guy got the job... he "passed" the test.
I understand your distinction between "a test" and "an interview", but I consider both of those to be testing, one's just implemented intelligently. 😉
---------------------------------------------------------
How best to post your question[/url]
How to post performance problems[/url]
Tally Table:What it is and how it replaces a loop[/url]
"stewsterl 80804 (10/16/2009)I guess when you stop and try to understand the solution provided you not only learn, but save yourself some headaches when you need to make any slight changes."
July 2, 2010 at 7:14 am
I guess I don't know about testing. I was hired 8 years ago, 2 weeks before I graduated from school ( and I'm 50 years old), as an RPG developer with no testing at all. I may have had an advantage in being hired, since the person they hired before me was my teacher in school.
I have since evolved into the best developer, by my bosses admission, that they have. I have learned SQL and .NET largely own my own, with the little help that MS online classes provides. As far as Google is concerned I freely admit that I live on Google for even simple things that I just don't recall and I rather doubt that I could do my job as efficiently as I do without it, especially since the IT world changes as fast as it does. I know that I could probably find the answers that I need from Books Online, or another resource, but in using one of the search engines I get the answer I need on the first page or two (most of the time) and have learned things that may not have been exactly what I was looking for. It seems to me that there are always a dozen ways to do anything and sometimes it's just a matter of opinion as to what is the 'best' way of getting the work done.
July 2, 2010 at 8:07 am
I am ok with a basic code test in the interview process but I would hope that this does not become an extensive process. I for myself may never get a job again if it becomes an extensive process. I consider myself to be a fairly decent programmer. I learn new concepts and languages quickly and I have a proven track record of turning out code with low defects and perform reliably. I write code in 7 different languages from sql to cobol.
However I admit that I rely heavily on snippets. If you asked me to write even a small program on paper I could give you a pretty good base but I would not be able to give you exact syntax.
I have used certain functions frequently and yet I still have to look at code examples or snippets every time I use that function. Does this make me a bad programmer? In some peoples view I suspect the answer is yes, but I have advanced in every company I have worked for and I am proud of that record. I have never been limited in my ability to get a job done quickly and accurately by not having remembered exact syntax and structure. This is even largely unnecessary in this day in age with the intele-sense functions put in place.
I think if testing is done it should be more from a practical stand point. One of the biggest challenges I have run into as an employee and a manager of developers is the ability to grasp business rules. My suggestion would be to test understanding of concepts of programming but also to test other abilities. I cannot tell you how many times I have had to struggle with someone that cannot demonstrate an ability to determine if a system is in balance or design a package based on the limitations placed upon it by business rules.
Dan
If only I could snap my figures and have all the correct indexes apear and the buffer clean and.... Start day dream here.
July 2, 2010 at 8:22 am
I agree with some of the points otheres here have already made. First, you need people doing the interview who will understand the results of the test. Hell, you need people who will understand the questions. I've been on interviews at many places where they don't have anyone with the skills needed to evaluate a technical person and they're just reading off a list. If your answer works, but doesn't match what they have, they won't consider your answer "right". I can picture a test that costs Jeff Moden a job because they're looking for cursor loops and long, convoluted answers to running total problems and he gives them a tally table and a "quirky" update.
I had a job once where my manager wasn't a technical person and we needed to hire someone new. I offered to be in on the interview process and sat in on the first 3 interviews. I rejected all 3 because of some glaring problems. My manager's solution? Stop letting me help screen applicants. We ended up hiring someone who did a really poor job and "lost" his work just before his contract ended. I ended up spending quite a bit of time trying to help this person and had to do the project myself anyway after he left.
Another thing is that testing only works on very junior people. If you want someone to come in and do exactly what you tell them, testing can work. If, that is, you already have someone who can supervise/mentor the person and tell them what they need to do. If you want creative solutions, testing won't work. If you mean in-depth interviews as "testing" then you need someone who can understand the answers. At that point you don't really need testing, you just need to talk about the person's work history and how they've solved problems in the past. That gives a much better understanding of how they get things done than putting them under pressure to solve an artificial problem.
I've been on too many interviews where I'm asked "how would you fix this" and I try to figure out the answer without the benefit of tools, being able to try different things or research on the internet. When I finally come back with "I don't know, but this might work" and get a response of "We tried that. I was hoping you knew the answer" I'm left with the feeling that the interview wasn't serious and I've just wasted my time. That's yet another "test" that doesn't help.
--------------------------------------
When you encounter a problem, if the solution isn't readily evident go back to the start and check your assumptions.
--------------------------------------
It’s unpleasantly like being drunk.
What’s so unpleasant about being drunk?
You ask a glass of water. -- Douglas Adams
July 2, 2010 at 8:25 am
I used to be strongly against testing, but in recent years, I've come to change my mind. There are too many people out there who claim to be programmers/developers/DBAs, some of whom claim years of experience, that don't have the slightest idea of how to write code. For the most part, though, I think that tests should be language-neutral - aptitude is the important thing to discover; syntax can be learned or looked up. Testing also doesn't have to mean a pen-and-paper test; it can also be a conversation about how you would solve a particular problem, like Grant described. The important thing is to have someone technical conducting the interview (so they can accurately interpret the response) and to ask questions for which the answers can't be easily faked by the candidate.
Ed Leighton-Dick | Consultant | Microsoft Data Platform MVP | MCSE | PASS Regional Mentor
July 2, 2010 at 8:34 am
I thought I would add something that I used to do when I conducted interveiws. I would ask the candidate to rate themselves on a scale from 1 to 10 on several different software or program languages. so I might ask them to rate themselves on windows OS, exchange, c#,VB,vos,lms
If they rated themselves a 10 on every one I knew immediately they were just blowing smoke. If they did not say they had never heard of atleast one of them since lms was a prapriatary sytem to the company then I new they were realy blowing smoke.
On a rule I looked for someone who rated themselves honestly. If you are rating yoruself a 10 in more than a couple packages chances are you are not being honest with yourself. I might even argue that few people can rate themselves a 10 in many of them. This was simply a quick way to determine if someone was just telling me what I wanted to hear and nothing less.
Dan
If only I could snap my figures and have all the correct indexes apear and the buffer clean and.... Start day dream here.
July 2, 2010 at 8:38 am
James Stover (7/2/2010)
I'm a believer in contract-to-hire. It gives everyone a chance to "kick the tires" and if it doesn't work out, you cut your losses. Oh sure, the contractor can walk away but so can your FTE. For the contractor, it's easy these days to explain away a 3-month stint (for example): "Oh, it was a 3-month contract." Enough said.Three months is a comparatively small investment for a long-term hire and it's unlikely a huge amount of IP is going to walk out the door if it doesn't work out. It confuses me why people are hung-up on full-time positions. It's really an illusion for both sides.
This is great. I got a great IT manager/lead developer role like this. Usually you know in 2-3 months, and then you can phase things along across another 1-3 months if you do a 6 month contract.
July 2, 2010 at 8:41 am
I was a developer then became a DBA. When I was looking for my last job I had an opportunity to interview for a entry level Java job (I only had 1.5 yr. experience as a .Net developer). The interview involved several test with different people.
I liked the test not only did it show me what they were looking for it gave me insights on who I might be working with.
The first test was pretty much a paper and pencil test that was very clinical, which for me was a waste because I'm not the greatest with terminology as I am with rolling up the sleeves and getting to work. When I reviewed the test with a potential coworker, I found him to be quite arrogant and rude (insight).
I think this style of testing only gave me an insight into the test giver and very little show of my knowledge.
I moved on to the next test which was a whiteboard hand coding project where we went over fundamentals (instead of Java specifics). The guy that was working with me on the test really knew his stuff and was glad to give hints and talk through the logic.
I was really impressed with this test and was able to work well with test giver.
So if it comes down to testing and what I'd recommend is to have a generic psuedo code test that can challenge logic more than syntax and to have the interview present working with the interviewee. Not only do you get to work on their knowledge you get to see first hand their team skills and see if you can build a rapport.
More often than not someone will have the skills, but if you can't communicate with them and draw out the needed skills, then what's the point of testing them if you have no connection.
Let's dial up that server with no wire attached...crap that doesn't work well.
July 2, 2010 at 8:45 am
A few of you have noted that an intelligent interview is needed. I think that is part of the problem. I used the word "test", but didn't mean a multiple choice set of questions, or write code to do this list of things.
Testing is finding a way to assess and evaluate performance. Having someone walk through scenarios, or solve actual problems. Maybe a full day of working with a couple people to solve things you really do. Have them work with you to re-implement something you've already done, give them the info you had at the beginning to get started and then hints, background, reasons, you learned as you moved. See how they think, examine a problem, work through potential solutions. They don't have to write code, or much, for you to assess their skills.
July 2, 2010 at 8:55 am
I would think that I am in the "test for entry positions / interview for mid to upper level positions" type of person. I have been interviewed, pitched my services as a consultant and been on interview panels "grilling" an applicant. Over time, I have come to think that while a short, three or
four question 'test' on specific job related DBA/Programming/design questions is in order, I still lean towards an open, even rambling discussion, with an applicant about the position, their work history, their "best" projects / "worst" projects can make you aware of many more things besides a person's technical skills. I also agree that a probationary period is an effective tool to give any new hire the opportunity to show their stuff. You can't learn everything about a new hire in the interview process so having this period to evaluate their thinking and interactions with the remainder of the team / department is invaluable.
We all want some one that can come into a new position with basic (or better) skills and can hopefully work on projects without constant mentoring or oversight. But we also want this new person to "fit in" with our team. The best DBA/ programmer in the world could be your worst candidate if their attitude is abusive, or you suddenly find out that your new hire seems to spend a lot of time searching Google for answers instead of asking for help. You won't learn that in a 3 hour interview.
July 2, 2010 at 8:56 am
Being a developer is a very dynamic job. You may begin working on one platform, and end up somewhere completely different. Over the course of just a few years, you could end up writing code in 4 or more different languages.
When I started my job, I was hired as a web developer. I knew PHP quite well, and enough SQL to manage a MySQL database on the web back end. I had many other capabilities, however, and when they started to realize this, my job description really branched off. Our website is now managed completely externally, and I don't write a lick of code for it. I do, however, write heaps of T-SQL code on a daily basis, as well some spatterings of C# application code. Although I did know C++ and SQL before joining the company, neither T-SQL nor C# were listed on my resume in any way. This is the nature of technology.
When I sat down for my interview however, I prided myself on my ability to learn things quickly. I think I also demonstrated that fairly well in the interview process. They did "test" me by having me look at a database diagram, and made sure I knew what I was looking at. But I really think that's all that was necessary. I think this was accidental, because no one else really understood databases really well. But I think they were also looking for a core competency, with the ability to branch into new things.
Really, I think that's what every hiring manager should be looking for with most tech jobs. They evolve so quickly, you want to make sure you've got someone who can evolve with it. Besides, even if someone knows a programming language inside and out doesn't mean that they're going to understand you're environment. You need someone who adapts quickly.
We are getting to the point where we need another person under myself. Personally, I'll be specificly looking for someone who's a little "wet behind the ears", but has those core competancies and a willingness to learn. Of course this should be a fairly inexpensive hire, but also we won't end up with a bunch of predeveloped prejudices. Instead, we get some fresh clay that we can mold to fit our needs.
My $0.02.
--J
July 2, 2010 at 9:04 am
The best DBA/ programmer in the world could be your worst candidate if their attitude is abusive, or you suddenly find out that your new hire seems to spend a lot of time searching Google for answers instead of asking for help. You won't learn that in a 3 hour interview.
Umm or reading SQL Server Central forums . . . 🙂
July 2, 2010 at 9:12 am
Steve Jones - Editor (7/2/2010)
A few of you have noted that an intelligent interview is needed. I think that is part of the problem. I used the word "test", but didn't mean a multiple choice set of questions, or write code to do this list of things.Testing is finding a way to assess and evaluate performance. Having someone walk through scenarios, or solve actual problems. Maybe a full day of working with a couple people to solve things you really do. Have them work with you to re-implement something you've already done, give them the info you had at the beginning to get started and then hints, background, reasons, you learned as you moved. See how they think, examine a problem, work through potential solutions. They don't have to write code, or much, for you to assess their skills.
A more intelligent interview is exactly what's needed Steve, with testing on a computer or pencil and paper being a part of it. Most interviews I've walked out of I chuckle because there is no way they could have assessed my abilities based on the questions they asked. I've given tests when interviewing and have used the results as one input among many to assess a candidate. I find a comprehensive interview more efficient than hiring someone for 3 months and finding out they can't do the job.
LinkedIn - http://www.linkedin.com/in/carlosbossy
Blog - http://www.carlosbossy.com
Follow me - @carlosbossy
July 2, 2010 at 9:18 am
If you where a box of crayons what color would you be and why?
I love when these types of questions get asked!
Can someone tell me how this tells them anything about me?
Dan
If only I could snap my figures and have all the correct indexes apear and the buffer clean and.... Start day dream here.
Viewing 15 posts - 16 through 30 (of 52 total)
You must be logged in to reply to this topic. Login to reply