June 7, 2011 at 9:39 pm
Comments posted to this topic are about the item Why Can't We Code?
June 8, 2011 at 1:29 am
Demonstrating something you have done is getting harder by the day, because all work is hidden on inaccessible servers when at an interview location. So it is just your word and then you are on a slippery slope and people can make things up. Even when you can show it, it is no real proof you are the one that made it in the first place. Sure an interviewer can ask details, but with no real knowledge of the system or clear definition of how it should work, the interviewer will be no match for someone prepared to make up an interesting story.
This really is the key issue I think when trying to interview someone to get a picture of his/her skill set.
June 8, 2011 at 1:51 am
I disagree slightly with the premise. The ability to create a website or put an app out are both very specific programming skills which might not be relevant--for instance, most of my coding experience is in Windows programming (using C and the Windows API, real old skool!) and that doesn't lend itself well to websites or apps! I suppose I could truck up with a application on my laptop, but the interviewer has no proof I actually wrote it...
June 8, 2011 at 1:53 am
I've had to interview for DBA positions in the past and I've looked to quiz my interviewees on some basic DBA concepts, such as backup and restores or performance troubleshooting. I'm not looking for a clear cut answer of exactly what needs to be done in a given situation (after all, each situation is different!), but I'm looking for someone who applies a bit of thought to the process and comes back with a logical, well reasoned argument for doing something a particular way. From this you can find out a lot about a person.
The technical skills can be learned, but it's a very different and difficult position to find yourself in if you have to amend someone's way of thinking.
June 8, 2011 at 2:02 am
I think that the employers should get familiarized to the user communities - follow up the forums, and even attend the meetings. In each community there are a few people who are constantly willing to help and offer good advice. They should talk to those people about the openings they have, maybe inviting them to interviews.
I realize that this involves work that many can find cumbersome and that a HR clerk with no technical knowledge may think that this is not an option. But constantly offering free help over a few years leaves no room for lies, unlike a CV and even a "personal" site (which can be done by someone else) or so.
June 8, 2011 at 4:08 am
New Nickname: Evil Steve. There's an E in my last name somewhere. 😉
[rant]
Anyway, having done a number of interviews lately (as a consultant, go figure...) I'm sick and bloody tired of the amount of people who have blantantly lied about their experience.
For the love of all gods, stop feeding my arse smoke and sunshine about your recent experience. I'm not looking for the mechanics of the lazy writer here. If you tell me you've done optimization, and I ask what your top three things to look for in an execution plan are (open ended question), don't blank stare at me. If you're going to tell me you've worked in SSIS for two years and I ask what are some of the collections in the foreach object, don't tell me about how the dataflow works.
My FizzBuzz is broken. Time to fix that.
[/rant]
I don't expect DB Devs/DBAs/ETL'ers to code. I sure as heck really don't expect a hard-core DB person to be able to put a solid website up, that's just silly, wrong skillset. I couldn't do it and I consider myself pretty competent.
I'm not entirely all sure I ever want a serious coder as a DB Developer. They think differently, have different core skillsets, and have different priorities.
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA
June 8, 2011 at 4:32 am
Craig Farrell (6/8/2011)
I don't expect DB Devs/DBAs/ETL'ers to code. I sure as heck really don't expect a hard-core DB person to be able to put a solid website up, that's just silly, wrong skillset. I couldn't do it and I consider myself pretty competent.
Same. I dabble in C#, sometimes. Anything I write in that language should be considered suspect and would likely make good front end developers laugh.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
June 8, 2011 at 6:24 am
I agree--If they've done nothing, they've got no passion. This isn't easy work. If they don't like the puzzles and the problems, they're better off in Accounting or HR. It's been a while but last time I had to hire it was for a junior C programming position that included bits and pieces of lots of jobs, and I recall interviewing three candidates. Two were there with fresh IT degrees of one sort or another. One was there with a completely unrelated degree, and his job was not involved with IT in any fashion--but he'd been working for a while. The IT grads stood out for their complete lack of experience. What have you done? --"I did my classes!" Well, what have you done beside that? Have you taken your PC apart? Installed a new OS? Built an application for yourself or friends? --"No. Outside of class, I only had my parent's PC. I wouldn't take any chances that I might break it." One of them went on to tell me what a sterling student he was, how many organizations he had volunteered for, what clubs he belonged to, and so on--some college advisor had apparently fed him a line that those things would get him a job. I think he probably was a decent person. But I didn't hire him or the other IT grad. In fact, the one I felt so sorry for that I took him aside after the interview, told him to get his hands on a computer, take it apart, put it together, and make it do something useful. I hired the third guy. He'd spent years before and ten years since college teaching himself stuff. He'd gotten to the point in his other career that he wanted out. We had a nice conversation about hacking Atari's, OS's, C pointers, and C++ classes and inheritance. Was he a perfect hire? No--who is, including me? Could he program? Yup. Did his other degree matter to me? Nope. He could have been collecting garbage in his past job, whatever, just so long as it was honest work. Now, if I'd absolutely needed someone with years of experience with a particular product or discipline, could I have used him? No, but the same interview principle would have applied. If the interviewer knows the subject, the truth will out. This doesn't include giving HR a bunch of questions--they'll bungle it every time. There's no secret method beyond that. Oh--and never expect the guy to know exactly the same set of skills you have even if he's been doing the same job on paper. The only thing to look for there is the honest answer that he or she doesn't know, hasn't done it much or whatever. No one knows everything, not even the guys that think they do. If the person is for real--and your expectations are real--there'll be plenty to talk about where detail matters. It's not a perfect method. I've had new-hires not work out but never because they didn't have the skills.
June 8, 2011 at 7:34 am
Over and over again, I have seen managers hire ineffective technical personnel when 1) the manager has never done similar work and/or 2) the manager is hired externally and knows nothing of what it takes to do the job in the hiring company and/or 3) there is so much turnover that nobody knows what it takes to do the job (which is frequently not well documented). I've seen these situations primarily in large corporations so I'm not sure if this occurs much in small firms. What seem to be driving forces are the tremendous rate of technical change, the rapid turnover (external transition) or migration (internal transition) of employees, and the limited application of the "promote from within" philosophy. Many of these issues can be dealt with, but at the cost of time/resources and management forethought which seem to be in limited supply.
June 8, 2011 at 7:41 am
I'm in the same boat as a few others. Web development and design would actually be a distraction from what I get paid to be good at.
The best thing I even did for my resume was write articles for SSC, and include that in a summary of my accomplishments at the top of the resume. Impressed a lot of managers.
I interviewed a LOT last year. Most of the tech screenings were laughably bad.
Had one interviewer insist that, for his company, there was mission critical data that it would be okay to lose because the disk space for log backups would be too expensive to allow implementing point-in-time DR. Either the data is mission critical and can't be lost, or it's okay to lose a certain percentage of it as it isn't mission critical.
Had another interviewer who asked three questions: Number of clustered indexes per table, difference between temp tables and table variables, and what's a covering index. Somehow, I don't see those three really telling you the difference between "I've read part of a book about databases" and "I'm a top flight professional in the field".
Had another who spent 20 minutes grilling me about how to securely set up a DMZ and firewall, for a DBA position, and this was after I told him, "I have no idea. I've always had competent network ops people set that kind of thing up and I've not had to deal with it directly myself". 20 minutes of confirming that I really did have no idea, as I had asserted. What's that good for?
I had one good tech screening. The manager put a laptop in front of me with a copy of Management Studio on it, and a connection to their dev environment. Said, "take a look at it, tell me what you see". Inside of five minutes, he knew I could do what he needed. He read my SSC articles, checked my forum posts, and made the job offer that afternoon. That's good screening! (I got offers from all the rest, but that's not the point.)
At my current company, the manager brings in the whole dev team (it's only five people) for a portion of the interview. They ask questions relevant to current and future projects, and to the actual environment. It makes for a decent "good fit" test, as well as being extremely relevant to whether the new guy will be able to code or not. It works beatifully.
But no questions about binary sorts and that kind of thing.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
June 8, 2011 at 7:44 am
When I was looking for a job, I found technical tests and interviews to be quite worthless to be honest. They would ask about term definitions that you never actually talk about in real life. They would ask me to code something that you maybe did a few times before maybe something you do quarterly, or that was a long series of code. And for a person like me who relies on organization instead of code memorization, it was quite pointless. It in no way tested my skill as a programmer, it instead tested my skills as a memorizer.(Which I have no skills in as I don't even know the lyrics to one song, and I rarely know the real names of actors in movies or TV shows, even ones I watch regularily that flash the actors' name on the screen.)
At the job I would simple copy and paste what I've done before, instead of wasting time actually typing the code. If I don't have the code, my Google skills come into play, and if that doesn't work, I create my own solution guessing at what properties/methods to use. Unfortunately, I don't think I've ever been tested in those skills. I moved to a new job after the employor saw my resume and I explained the mission critical systems I supported and created, and how much money they saved the company. Only the most basic of DBA questions and no .NET questions were asked, outside of explaining my experience. Which in this case, was the correct way to interview/hire who they needed.
June 8, 2011 at 7:59 am
GilaMonster (6/8/2011)
Craig Farrell (6/8/2011)
I don't expect DB Devs/DBAs/ETL'ers to code. I sure as heck really don't expect a hard-core DB person to be able to put a solid website up, that's just silly, wrong skillset. I couldn't do it and I consider myself pretty competent.Same. I dabble in C#, sometimes. Anything I write in that language should be considered suspect and would likely make good front end developers laugh.
I doubt that what you write would be suspect. My experience is that people that are good programmers in one langage are good programmers in other languages.
Turning that around, I have never bought the argument that you can't expect front-end developers to be good at SQL programming because they somehow require differerent mind-sets. I just think that bad developers get exposed more quickly when they turn to SQL programming because their bad code has a more obvious impact on the application.
June 8, 2011 at 8:29 am
Question Guy (6/8/2011)
I moved to a new job after the employor saw my resume and I explained the mission critical systems I supported and created, and how much money they saved the company. Only the most basic of DBA questions and no .NET questions were asked, outside of explaining my experience. Which in this case, was the correct way to interview/hire who they needed.
I agree with you but in my case I had to face interviewers who were keen on finding out what I didn't know.
In one case, one guy was continously asking me about SSAS when I already told him I had no experience in it.
M&M
June 8, 2011 at 8:54 am
Michael Valentine Jones (6/8/2011)
. . . My experience is that people that are good programmers in one langage are good programmers in other languages. . . .
Being a crack closse-to-the-metal C++ programmer is a significant obstacle to mastering Prologic or Forth. That might be an extreme example; however, I have to deal daily with programmers who are highly experienced but are unable to switch between C# and T-SQL mindsets. (Although they of course think they are masters of both.)
June 8, 2011 at 8:54 am
peter-757102 (6/8/2011)
Demonstrating something you have done is getting harder by the day, because all work is hidden on inaccessible servers when at an interview location. So it is just your word and then you are on a slippery slope and people can make things up. Even when you can show it, it is no real proof you are the one that made it in the first place. Sure an interviewer can ask details, but with no real knowledge of the system or clear definition of how it should work, the interviewer will be no match for someone prepared to make up an interesting story.This really is the key issue I think when trying to interview someone to get a picture of his/her skill set.
The point of the article is that you should do something publicly. Put out a design or a web site or something else that you have done, that you can talk about. It doesn't have to be exactly what you did at work, but build something that shows the same skills in a public place.
It's up to you to showcase this, not just depend on your employer to release something or allow you to show your work at that job.
Viewing 15 posts - 1 through 15 (of 57 total)
You must be logged in to reply to this topic. Login to reply