Database Underground | Sean McCown | October 2006

MORE ENTRIES

October 2006

October 26, 2006 | Comments: (0)

I was discussing some of the missing features with one of the SQL Server product managers a couple weeks ago, and he said something that I hadn't really thought about before. I asked him how some of these things could have made it out of beta, and he said that beta cycles are very good at shaking out usability issues. He's right too. Think about how you look at beta software. You always judge it for major features, and if something's missing from the GUI, you always just assume it'll be added for the final release. I've said that many times myself... "oh well, they'll get around to it. This is just the beta."

The problem is that everyone says that and you can't test against everything. So things get overlooked. The thing to do is complain about every little thing as early as you can. On more than one occasion MS has told me that every single issue gets a developer assigned to it and you can see the progress of your issues.

Personally, I love that. Not only will you get some really good ideas, but you're making your customers part of the cycle and if they know their issues are actually going to be addressed in one way or another, they're more likely to submit them. Everyone wins.

So go to the website they've setup to track these issues and complain about whatever you like. They can take it. Be very liberal with the amount you use this service too. Use it as much as you like. The only way they're gonna shut us up about it is to actually fix the issue.
Here's the link: http://connect.microsoft.com

Posted by Sean McCown on October 26, 2006 08:33 AM

October 25, 2006 | Comments: (0)

SQL Server 2005's Schema Problem--An Elegant Solution

There's a problem with schemas in SQL2K5 that I encountered again this week, and I put my head to it and developed a very elegant solution that I thought I'd share with everyone.

Problem:
When you connect to SQL through membership in a Windows group, you cannot define a default schema for the group. This means that if you want everyone to be in a specific schema, you can't do it by default. When users connect through membership in a Windows group, SQL will automatically create a separate user (mapped to the AD acct), and a schema of the same name. So say you belong to the 'Sales' group in AD, and that group has rights in SalesDB. When you connect for the first time, SQL will create a user in that DB called domain.username and map it's default schema to domain.username as well. This causes you to have tons of user accts in your DB that you have no use for because you're supposed to be connecting through your group 'Sales'.

What you want is for all of your people to create their objects in 'dbo'. As it stands you have 2 choices by default to handle this.
1. You can just map the users directly in SQL and forget about putting them in a Windows group first.

2. You can go in every now and then and change the default schema for all the new users. But you can see how that would become unmanageable after just a very short while.

OK, all of this is a huge shortcoming in the way MS handles its schemas. Don't get me wrong, I understand that they're trying to protect against someone belonging to several groups that all have different default schemas defined... because how would SQL decide what your default schema is if you have several? But I also think there are other ways around this problem that would suit our needs much better. For starters, just don't force new users into their own schema. In SQL, if you don't define a default schema, it defaults to 'dbo', so in this case that would solve the issue from their side very well. In fact, everything should default to 'dbo' unless otherwise specified.

Solution:

OK, I've got a couple solutions of varying elegance.

1. Create a job that changes all of the default schemas for all of the new users. Just take the code below and paste it into a job step window for the DB you want it to run in. If you have several DBs, then add a new step for each DB and it'll just cycle through all of them. It only takes the new ones by looking at the ones where the name = default_schema. It's that easy, and you can change them to whatever you like. The logic is at your whim. Anyway, here's the code.

DECLARE @currUser varchar(100),
@SQL nvarchar(200)

DECLARE Users CURSOR
READ_ONLY
FOR select [NAME] from sys.database_principals
where
[principal_id] > 5 AND
[type] = 'U' AND
[name] = [default_schema_name]

OPEN Users

FETCH NEXT FROM Users INTO @currUser
WHILE (@@fetch_status <> -1)
BEGIN

SET @SQL = 'ALTER USER [' + @currUser + '] WITH DEFAULT_SCHEMA = dbo'
EXEC (@SQL)
--print @SQL

FETCH NEXT FROM Users INTO @currUser
END

CLOSE Users
DEALLOCATE Users

OK, that's not too bad. It'll work for a while at least. The problem is though that anyone can just come along and disable the job and you wouldn't know it for a long time. So I've created another method for dealing with this and it's actually much better. It won't correct the default schema issue, but it will keep objects in the right schema.

2. Create a database-level DDL trigger to move the object to the new schema. I've created this trigger that will transfer an object to 'dbo' once it's created. Now, you can obviously put them anyplace you like, and since I've only done it for SPs, you can expand it to any object. The point here is that you can do it and it doesn't have to be manual.

Here's the code:

CREATE TRIGGER EnforceSchema
ON DATABASE

WITH Execute AS 'sa'
AFTER CREATE_PROCEDURE

DECLARE @SQL char(100)

DECLARE @eventdata AS XML, @ProcName AS SYSNAME, @schemaname AS SYSNAME,
@eventtype AS NVARCHAR(100), @msg AS NVARCHAR(MAX), @abortflag AS BIT;

SET @eventdata = eventdata();
SET @ProcName = CAST(@eventdata.query('data(//ObjectName)') AS SYSNAME);
SET @schemaname = CAST(@eventdata.query('data(//SchemaName)') AS SYSNAME);

SET @SQL = 'ALTER SCHEMA dbo TRANSFER ' + '[' + @schemaname + ']' + '.' + @ProcName
EXEC (@SQL)
GO

OK, so just run that in the DB you're trying to protect and you'll be fine. There is something you should know about this though. If you don't want users to have this kind of permissions, you have to run it as a different user. I chose 'sa'. The problem is, and I don't know why they did it this way, they probably just coded this bug into it... anyway, the problem is that it only checks the current DB for the user to run it as, so you have to specifically add 'sa' to the current DB and give it db_owner rights. OK, you probably don't have to give it db_owner, but it's already a sysadmin, so just shotgun the rights and don't worry about getting it fine-grained. However, you can run it under anything you like, but realize that the acct you run this trigger under has to be given explicit rights in the current DB, it can't just be a sysadmin.

OK guys, I hope this helps someone out there. Let me know if you like this solution and I'll post more stuff like this as I develop it.

Posted by Sean McCown on October 25, 2006 10:56 AM

October 23, 2006 | Comments: (0)

Essential Skills for DBAs

I quite often get asked, 'Sean, since you're such an industry leading expert, what skills do you think a DBA should have?'

Well, that's actually something that's close to my heart. The answer is yes. There are so many skills that make up a good DBA it's hard to know where to start.

I think a good place to start is outside the typical DBA skillset. I think every DBA should have web programming skills. This is without a doubt one of the more useful outside skills to have because almost anything you do as a DBA would be done better if you posted it to the web. We also seem to be called on to do all kinds of things that have nothing to do with DBs. You should not only know basic HTML, but you should also know ASP in either VBScript or JavaScript (both is better). You'll find these skills so incredibly useful in your daily work and you'll wonder how you ever go by without it.

Another excellent skill to have is some kind of compiled language. Even if you never plan to be a programmer past anything SQL related, you still need to know something about programming in one of the compiled languages. This is essential because these programs are what's hitting your DB and you need to know what they can do and how they behave. It's no longer acceptable to be a DBA in a vacuum and not know anything outside of SQL.

The same goes with networking and Windows. These are essential skills for DBAs because we're quite often the first ones who get called when there's a problem with an app. Since nobody really knows anything about SQL, they always figure it's the DB causing the problem, when quite often it isn't. But you're going to have to have numbers when you kick it back to the Windows guys. It's one thing to say, I can connect to the DB just fine, and another to say, I've run nslookup on it and it's a DNS problem.
All of these extra skills also give you knowledge of the grand scheme of things so you know what questions to ask. If you had no idea of anything Windows or networking, then you'd never know to ask the user if they were connecting with the FQDN or not. these are things you do to find out if it's even your problem or not. Because the first thing the Windows guys are going to ask you is how do you know it's not the DB. And you'll need to be able to say, because he can connect using the IP, but not the FQDN.

These are just a couple skills I think good DBAs should have to do their jobs. But I really think it's necessary because as I've said before, we're really expected to know more than everyone else. I've even been called on to do Exchange before. After all, I am the DBA, I must know Exchange too, right?

And with WinFS coming in the future, I think DBAs are going to be the next gods of the industry. We'll automatically have a say in Windows desktop rollouts, server builds, etc that we've never had before. Exchange is the same thing. Eventually Exchange is going to be SQL-based, and the Exchange admins will do what we say. It's a good position to be in. Maybe then companies will start taking DBs seriously for a change.

Posted by Sean McCown on October 23, 2006 11:26 AM

October 20, 2006 | Comments: (0)

Just when you thought the Backup Wars were Dead...

OK, here's the latest news on the backup wars... and this time I had nothing to do with it.

Red-Gate has commissioned a report from the Tolly Group to run a comparative benchmark between them, LiteSpeed, and Idera... a decision I would imagine they're already regretting. Get the report here. I hear the benchmark was my idea. After Idera released their benchmark earlier this year, I was talking to the Red-Gate guys at TechED and said that we should all get together and do a fair benchmark with everyone on the same platform. Apparently they ran with that idea. Which is fine, but I'm not sure that Tolly has done it the right way.

The report has come out a few times now. My Quest reps tell me that the report has changed a few times since it was released in Sept. And depending on the changes, that could be something or nothing. I'm not going to make a big deal out of that unless they've changed the numbers between versions.

However, what I do find interesting is that Red-Gate has come out on top. I've personally run a lot of independent tests against all 3 of these vendors, and haven't ever published the results because their EULAs prevent it. Let me say though that while Red-Gate is a good tool, it is single-threaded and has never been able to prove itself the hands-down winner over either of the other two.

So what does the report say that I find suspect? Well, for starters, they tried to make up for their lack of multi-threading by writing to 3 files while pinning LiteSpeed and Idera to 1 file. It's certainly interesting from a performance tuning perspective, but it reads more like a report on how to make Red-Gate perform in the same league with the others by overcoming its limitations. I was curious about whether just adding 3 files would be a fair multi-threading comparison, so I put LiteSpeed in my lab last night and ran a couple quick backups. I backed up a 200GB DB with a single file, and then ran the job again with 3 files. Oddly enough, I saw just over a 20% increase in performance by striping... and yes, to the same RAID array. So it appears that even though you can make Red-Gate perform better than expected, a single-threaded application simply can't compete with a mulit-threaded one. It just can't. It should be just as easy to add a striped backup to the Tolly results, and I'm really curious why they didn't do striped backups with LiteSpeed and Idera to show what the difference would have been. If it truly doesn't add that much to the equation, then they should have shown that. So I'm thinking that it clearly makes a difference.

I'll tell you one thing though. This report has shaken out one very important FACT. Idera released their benchmark earlier this year where they claimed to be the fastest backup on the planet because they performed it on solid state disks, and didn't compare it with anyone else. And while the Tolly report shows an unfair bias towards Red-Gate, it does put LiteSpeed and Idera in equal light, and LiteSpeed comes out with almost double the throughput of Idera in more than one graph. In fact, by looking at the Tolly graphs, LiteSpeed beats Idera in almost every benchmark. It just goes to prove that Idera's earlier benchmark was released to intentionally deceive the marketplace. If not, then Idera would have released comparative benchmarks with their competitors on the same platform, and not gone so far outside of the industry standard hardware to be able to make their claim as the world's fastest backup.

I don't believe there was any such intent from Red-Gate. Their reps have already told me that they merely commissioned the report, they had nothing to do with it after that. But it does seem a little odd that a single-threaded app could win by such margins when they paid for the report. I do believe though that Red-Gate themselves at least tried to do it right. They went to an independent firm and asked for a report. I think the issues here lie with the Tolly Group's test.

There's more to be had here. I still haven't contacted the Tolly Group, and I haven't heard back from my inquiries to Idera. There are some unanswered questions that I'm not going to bring up until I get something from these guys and can tell you what actually happened.

Until then, this is what I know so far.

Posted by Sean McCown on October 20, 2006 07:25 AM

October 19, 2006 | Comments: (0)

Here are my Interview Questions

Someone wrote and asked about the dumb questions I have been told to ask interviewers. Here are some of them. I found them in my email box from my last round of interviewing. And you know what, no matter what I do, I just can't imagine any of these words coming out of my mouth...

• What are the characteristics of the most successful people here?
• What are the key skills and abilities necessary to be successful in this position? What are you looking for?
• What defines outstanding performance here? How is that performance evaluated?
• What would I have to do to be considered a key resource on your team?
• What value would I bring to the team?
• How would you position me on your team?
• How would my skills help meet your goals?
• What goals does your group have that you are excited about?

OK, that's the list... if any of you like them, then feel free to use them, but if someone came in and asked me any of these I don't know what I'd do. I'll tell you what the most successful people here do, they don't ask me questions like that.

As well, here's something on thank you cards I was also sent.

Thank You Cards

Why send a thank you card? Because your competition probably isn't, and sending a card can make the difference in who gets the offer. Sending a card is professional and shows genuine interest in the opportunity. MiscRecruitingCompany recommends sending a thank you card versus a letter because it stands out and is more likely to be read quickly by the hiring manager.

MiscRecruitingCompany recommends that you use plain, simple thank you cards readily available in any card shop or grocery store. There should be no writing on the card except for the thank you on the cover. A plain tan color is just right. If you are interviewing for a contract position, an email followed up by a "snail mail" card is appropriate. When interviewing be sure to get the correct spelling (write it down) of each person you interview with. Use blue ink. First, thank the interviewers for their courtesy in meeting you, then reference some of the strengths you bring to the table that interested them in your interview, and close by asking for the job.

Sample text:

"Dear Robert,

Thank you for your courtesy this morning. I enjoyed meeting you and your team. To recap, I believe my two years of SQL development matches your needs and that I will be able to help your team meet it's rollout deadline. I am looking forward to hearing some great news.

Take care,

John Doe."

You know though... no matter how long I go on, I'll never understand the thank you note. I just can't see that it will ever make a difference. If you don't make the grade, you just don't make it, and sending a note isn't going to change that. Just like not sending a note... if you're perfect for the job, not sending a note isn't going to make a difference either.

Posted by Sean McCown on October 19, 2006 09:07 AM

October 18, 2006 | Comments: (0)

Encryption isn't the Source of Evil, but it Does Distribute it

OK, let's talk about encryption for a minute, and why you should and shouldn't do it.

Encryption is one of those buzz words that sounds really cool to implement, but so many people don't understand the effect it has on your environment. It's a lot like clustering. Too many people like the sound of that word and end up implementing a clustered solution when they didn't really define what their needs were to begin with.
Encryption suffers from this linguistic admiration as well.

Before you decide to encrypt data, you have to assess what you're going to encrypt and why. This sounds trivial, but you'd be surprised how many people miss this step, and how many just flat-out get it wrong.

For starters, if you're encrypting to fulfill an audit, then DON'T. There are none of the mainstream audits that require you to encrypt your data. They require you to protect your data, and a lot of IT guys mistake that for encryption, but the spirit of the control is to lock down access to your box. What they want to see is that people who can see the data are the ones who should be seeing it. That's about it. Don't read too much more into it. And by all means, don't encrypt your data just because you don't feel like locking down your server. Encryption is a big step to take and a project that limits user rights to the data will be much less invasive.

Basically, encryption hijacks your data and is pretty invasive. Usually what happens, is the encryption software steals your table and replaces it with a view that you use to access the data instead. That view points to the original (and renamed) table with encrypt/decrypt functions. In software solutions like DBEncrypt from AppSec Inc, the functions also check your permissions and will either present the data to you or not based on your rights. Other solutions like Ingrian (hardware-based) do basically the same thing, only they ship the data back to the appliance first usually. I think you can set it up to check it locally, but I may be confusing it with something else right now... anyway though... that part doesn't really matter. What does matter though is how invasive those solutions are. In fact, with the hardware solutions, you're completely screwed if your appliance goes down because it stores all of your encryption keys and without it, your data is lost. Just think about that before you implement something like that.

There's also what encryption does to your processes. You have to put a lot of thought into testing and do a fair amount of benchmarking before you get into a solution. You never know what's going to shake out. A good example would be Ingrian. You really wouldn't want to load a warehouse with it in place because it can't decrypt in batches. That means that every row gets shipped to the appliance. It's like a 200mill row cursor. So you can imagine how incredibly slow your load is going to be.

I see that a lot though; people making decisions without thinking through every aspect of their business. They have blinders on with only their immediate problem in sight. So for the sake of everyone in your company. When you decide on a plan of action, make sure it will suit every business unit first.

Here's a really good one... make sure you actually need to encrypt. Know what you're protecting your data from. I had a case once where a company spent something like 50K on an appliance to encrypt 3 columns in their DB. The server was locked down, so only those with access could see it anyway. So why encrypt? You're only protecting it from people who can already see it anyway? Is it to protect against the data being stolen say from the off-site storage where you send your backup tapes? That's a valid concern, but encrypting the backup file would be a much cheaper and much less invasive solution. And it would actually suit the purpose with more elegance.

And don't forget... if you implement something like that to keep your backups safe, you have to get all of your backups back from the off-site storage and encrypt them. Otherwise, you're not any more protected than you were before. Again, it's a simple thing to ask the question: What are we protecting ourselves from?

So when should you encrypt? That turns out to be a very interesting question. The simple answer is when you feel you may be at risk from internal or external forces beyond your control. So, this would be something like having your DB exposed to the DMZ and you have extra-sensitive information that could be compromised should something grave happen to the network security. You could also be in a situation where you just can't lock down the DB because of some legacy tie-in, and everyone who has unrestricted access to the data doesn't need it. This could fall under the heading of having NT admins in the SQL admin group and you can't remove them. Also, if you have to roll your production data to QA and test people, that's a good time to encrypt. However, I feel that there are steps you could take that would be much less invasive than encryption if this is the case.

The point is that encryption can be necessary, but really only under limited circumstances where all other tactics have failed. Basically, you should look at encrypting your data as surgery. Don't do it unless all of the other avenues have been exhausted, and there's just no other way to get the gerbil out. Maybe next time I'll talk about some ways to obscure the data in QA and testing without having to encrypt.

Oh yeah... there's one more thing. Every major DB vendor now has native encryption. This can be far less invasive than their 3rd party counterparts, but you should plan to dig through your code and add the function calls. As of right now, the only vendor I know when any stated plans to add real native encryption functionality is Sybase. Real native encryption being where you don't have to call a function yourself. You simply mark the column as encrypted and the RDBMS takes care of the rest. You then just assign encrypt/decrypt permissions to your users and there's nothing left to touch. I don't know if Sybase has implemented it yet, but they were talking to me about it a while back. Once this ease of use hits all of the DBs, I suspect the encryption companies will have a lot of very large doorstops on their hands.

Posted by Sean McCown on October 18, 2006 12:14 PM

October 17, 2006 | Comments: (0)

Microsoft will NEVER be a Leading Software Vendor!

So, will MS ever be a world-leading software vendor? The answer is absolutely NOT...never ever never will they ever be able to maintain anything other than a perfunctory standing in the software community.

Why? It's simple. Because they hold such a loose dress code. It sounds like the two things aren't related(success and dress), but they are. They must be, because that's what we're told constantly by almost every company out there.

"You can't wear jeans because it's unprofessional."
"If you dress like a professional, you'll act like a professional."

Almost every company out there has a business or business casual dress code, but come on now... every one of them allows for casual friday. So what you're telling me is that since the clothes make the man, then I'm allowed to screw up the DBs and just play around on fridays, because I'm not dressed like a professional. Of course I'm not allowed to do that. So what's with the dress code then? Well, we get customers at this site, and we want to make a good impression. We want our people to look like professionals. OK, so customers are banned from the building on friday? No, we just explain to them that it's casual friday and they're usually good with that. So, why can't you just explain to them that it's casual wednesday, or better yet, we have a casual office?

My big problem with these dress codes is that they're just so arbitrary. Who says that a tie is better than a t-shirt for working in all day? I've had managers call me down for wearing shirts without a collar. But, I explained to him, Tim over there is wearing a polo shirt with simple logo on it, and I'm wearing a very nice silk sweater, and you're telling me that he's dressed nicer than I am because he's got a collar? YES, that's exactly what I'm telling you. But what about Jane over there? Her dress doesn't have a collar. But women don't count. They don't have to wear collars. So women really are smarter than men because we need collars to be smart, and women can do it without them? Wow, I've got a lot to learn about the differences between men and women.

So apparently, if you can't be good enough at your job to wear a tie to prove it, then you can at least know enough about SQL to wear anything with a collar. So dressing well isn't good enough... it has to be a specific uniform. Hey, like in fast food! Why don't we get companies to issue us uniforms like at McDonald's or a private school? That way we can all look alike and it would take casual fridays and everything else right out of the equation. Because women aren't held to these dress code standards, just men.

Last week I was in the shower pondering a problem at work. I thought on it for a few minutes, and just couldn't think of a way to fix my problem. That's when it hit me. I called my wife to bring me a tie. I slipped it on the the answer came to me almost instantly. Sometimes I just don't know where my head is. How could I forget something so basic?

Now, back to MS. Haven't any of you ever wondered why MS is always delaying their releases? Why did it take so long to get Yukon out the door? Why are Vista and Longhorn suffering from delays? Why was WinFS taken out of the OS? Why doesn't Exchange use SQL on the backend? That's right people... dress code. If they would only require their developers to wear ties, they could start being a real heavy hitter as a software vendor. As it stands, they don't have one single product that anyone uses... Office, what a joke... SQL Server, don't make me laugh... Exchange, might as well be a paper airplane with a note written on it... Windows, what is it, like on one desktop anymore?

So you can see what having a loose dress code has done for MS. They could have been worth something, but they insist on letting those hippies run around on campus in their shorts, trying to code without the proper coding attire. It's a pathetic waste. And with policies like that it's no wonder Gates can barely afford to feed the country he bought. Those poor people only get to eat steak and lobster once a day. Now how sad is that?

OK, all of this sarcasm has been very fun, but I'll get serious for a minute. You know, dress codes are necessary to a degree but only in certain areas, and they have nothing to do with how professional you are or even act.

Dress codes should be used to keep women from putting too much on display. That much is certain. Don't get me wrong, I'm all for women dressing so show off their assets, but it just doesn't belong in the workplace.

Now, I'm not being sexist here. I've never seen an issue come up at work where a guy was talked about because he showed off too much of his body, or wore his shirt too low. However, for the sake of fairness, I'll go ahead and say that nobody should be dressing in a manner to attract a mate. How's that?

Other than that, I can't imagine that anything else would be taboo.

And like I said, it's completely arbitrary. If it weren't, then different companies wouldn't have different dress codes. If a company like MS can become one of the largest software vendors on the planet and still maintain a casual dress code, then there must be something to it. And MS doesn't have some special of screening exam to test for people who can do their jobs without ties. They're pulling from the same work force everyone else is. And I can't think of a single instance... anywhere... where someone has messed something up at work because he wasn't dressed in business attire.

It's just ridiculous.

Posted by Sean McCown on October 17, 2006 09:32 AM

October 12, 2006 | Comments: (0)

Unofficial Forced Retirement

I got an email from a reader that I thought all of you might find interesting. Unfortunately, his observations are all too real, and I've seen it myself. Personally I don't understand the mentality. I would much rather have someone experienced than a young punk who's fresh out of school. He still has all the mistakes to make, and just doesn't have enough experience to pull off a big project like someone who's been there/done that. I don't know... what do you guys think?

Anyway... here's the email.

Client companies have found an illegal way to screen candidates based on age through the use and abuse of 3rd party IT recruiters...

Age discrimination runs rampant through many IT recruiters and their client companies. Is this why there seem to be few older IT workers in IT tech Support? Here in Cincinnati, OH age discrimination occurs daily where younger IT consultants are often given preference for IT contracting jobs over older, more experienced IT workers based in part, on age of the applicant.

I am in excellent health at age 48, look much younger than my actual age, in good finanacial shape, and having problems for the past year in finding a decent IT tech support job due to lack of jobs availability because IT recruiters skip over my 2 page resume due to my age. I have great job refs, up to date on coursework, certs, college degrees and have work experience to satisfy almost any client, but I am told by IT recruiters that they are looking for "younger" candidates. I am often described as "over qualified" (double talk for age) for positions that I apply. Wages were never brought up as a concern by IT recruiters since I am willing to work at "market" rates.

The use of 3rd party IT recruiters is supposed to enable client companies to make better management decisions, however the reverse is true... IT recruiters sometimes screen candidates based on illegal age requirements that open the IT recruiter and client companies to civil lawsuits.

IT recruiters in this area pre-screen resumes based on applicant age and experience. I have talked to several IT recruiters who admit that they are looking for younger "fresh" talent that will get the job done because the client company has specified they only want younger contract workers. There seems to be a employer bias in this area that older workers do not work as quickly as younger workers, despite older workers possibly having more specific work experience.

This client company requirement for "younger workers" amounts to simple age discrimination that is hard to prove because it is the 3rd party IT recruiter illegally screening the candidates based on age, not the client company. Job applicants are not allowed to see job requisition orders from client companies where recruiter notes sometimes detail age requirements.

Most 3rd party IT recruiters are spineless and will not stand up to a client's illegal resume screening requirements. Recruiters are often more concerned with satisfying the client's needs and earn more bucks rather than take an ethical route to express concern about illegal hiring practices based on age.

There are federal laws supposed to protect against this illegal practice of hiring based on age, but client companies deny responsibility saying it is a recruiter problem and the labor hiring laws are seldom enforced by government officials.

Posted by Sean McCown on October 12, 2006 08:37 AM

October 10, 2006 | Comments: (0)

Stabbing Red-Gate in the Eye

Quest has released a freeware tool to compete with Red-Gate's change management suite. Quest's tool is actually 3 tools in 1. It has a schema compare tool, a data compare tool, and a server compare tool. Of course, it's just version 1 so it doesn't have the richness that the Red-Gate tools have. For example, Red-Gate has a scheduler and an API for their tools. That's a decent difference in functionality.

At this point though, I really don't think Quest is trying to take those more advanced clients away from Red-Gate. They're probably just trying to get them back for stealing a lot of their lower end LiteSpeed business. I'm not saying that's what they're doing, but that's what I would do if I had the money to blow on something like that. I also wouldn't be surprised if this were just the beginning. Now that Quest has a product in this space, all they have to do is keep developing it, and they could have a high-level product that will actually be able to take business away from Red-Gate.

Personally, I like the Red-Gate guys. I talk to them at all the conferences and they're always really cool. I also like their tools... including their backup tool. But I have to admit, if what I needed was a good compare tool, I would look to the freeware to take me as far as it could before having to pay for a license.

I've actually looked at the tool and it looks pretty good. It does a good job of doing the compares, and the interface is a lot like Red-Gate's so you won't be lost. It's fast enough too, so you shouldn't have any problems there. Anyway, just thought I'd let you guys know because I know how hard it can be for some companies to let go of even the smallest amount of money.
Here's the link:
http://www.quest.com/Comparison_Suite_for_SQL_Server/

Posted by Sean McCown on October 10, 2006 06:57 PM

October 10, 2006 | Comments: (0)

Cert Review Series

Someone was nice enough to point out to me from my post last night that it's weird that I would bother doing a review series on certs since I'm well on the record as saying that certs are completely worthless. And while he's right, I've got the bigger picture in mind.

See, while the cert process (speaking specifically of the MS certs) has typically been a joke, I know they've taken a lot of steps to improve that. The reason it's been completely worthless in the past is because it's just so easy to cheat. Anyone with absolutely no experience can go to one of the dump sites and get all the answers to any of the exams and just memorize the answers. So you end up with a ton of MCDBAs out there with no knowledge of SQL and they're competing for the same jobs I am.

However, with the new cert process I'm curious to see how well this problem has been solved. And while I haven't decided whether or not I'm going to actually try to re-certify, I am going to go through all the material because I know a lot of you are going to be interested in it, and don't need to waste your money on books that aren't going to do you any good for the exams.

The big question is... is MS going to send me some free exam vouchers so I can take the exams and report back to you guys if it's been improved enough to bother with? So MS, if you don't come through, that's as good as admitting they're not worth it.

Posted by Sean McCown on October 10, 2006 10:30 AM

October 09, 2006 | Comments: (0)

Now THAT'S Training... Or IS It?

As many of you know, I do book reviews on many IT topics. Well, a lot of you may not know that I've started reviewing video titles as well. I've got some video titles that I've posted very recently, and I'd like to talk about them for a min. I've also got some book reviews that I've posted recently, and I'll tell you about those briefly too.

I've got 2 examples here of video training; one excellent, and one horrible. I'll briefly discuss both of them and you can go read the full reviews if you like.

AppDev:
I've gotten a hold of the training from AppDev and have finished like 3 of their titles. Their training is simply top notch. The production quality is very high, and the instruction is fantastic. You can really tell that these guys know their stuff. I've got the SQL Server 2005 training, and I'm starting to go through it now. I'll let you guys know when I've got it posted. Seriously though, if you ever get a chance to take any of their training, don't pass it up.

SQLUSA:
I've also been through the SQLUSA training. I honestly can't imagine a bigger waste of money. You'd really be better off learning SQL from a house painter. This guy spends so much time just surfing the web and rehashing things he's already said. His code doesn't even work often times and he has to take drastic measures to fix it. For example... He couldn't get his data to load one time and after trying a few things, ended up taking the PKs and FKS off the tables. Just ridiculous. Also, another time he was trying to show us the SQL services, and got lost in the OS. He tried a couple things before he found the services window. Dude, edit that crap out. And yet another time, his phone rang and he didn't edit that out either. Anyway, you can read much more detail in the review.
Know though, the one I reviewed is for OLAP, but they also have one for managine SQL2K5, which I went through a little bit, but didn't actually do a write-up on it yet. Trust me though, it's equally pathetic.

I'm also doing a series on certifications for SQL2K5. I've got some of the official materials now, and I'm collecting more so as they come in, I'll be reviewing them and putting them in a big cert bundle. Is anyone interested in that?

You can see all the reviews at www.ITBookworm.com and click on Videos on the left.

Posted by Sean McCown on October 9, 2006 04:28 PM

October 09, 2006 | Comments: (0)

Are IT Recruiters Worthless? (Part 4)

I've gotten so much good email on this topic that's it's sparking another post. I thought some of you might like to see how the stats are adding up in my email. I've gotten 187 emails on this topic, and of them, the opinions stated are as follows:

I'm expressing what's on every DBA's mind -- 63%
I'm getting what I give and need to treat recruiters with more respect -- 7%
I'm not being hard enough on recruiters because they're all idiots -- 11%
I'm not taking into account that the good recruiters have the same fight we do -- 1%
My stories are nothing compared to what the readers have faced -- 19%
I'm a complete moron for thinking I can showing up to a recruiter dressed in anything other than interview attire -- 4%
I should never jump through a recruiter's hoops -- 2%

And my absolute favorite...

I had one reader speculate on how many johns my mother had to service before giving birth to a moron like me.

Now, one thing you'll notice is that all those add up to more than 100%, and that's just because some expressed more than one opinion. And I didn't put all the opinions in there either, just the more interesting ones.

Anyhow... I do think it's interesting that so many of you agree with me. I've always wondered what others really thought about the recruiting process or if it was just me who couldn't stand it. And for those of you who don't agree, especially those of you who think I'm getting what I give, I have only this to say.

I'm sure that most of us didn't go into this process hating it, and being tired of recruiters. We've had it beaten into us. It's hard to hide your contempt for a situation when you spend so much of your time meeting different recruiters to discuss a job that doesn't exist, or is out of your skill set. I'm also sure that most of us didn't go into this hating to have another FNG recruiter tell us how to run our business. Sure, we represent their company in the loosest way possible, but like I've said before; they just started recruiting, and we've been getting tech jobs for a long time before they came along and will continue to do so long after they go back to retail. So I don't think it's arrogance or complacency that drives a lot of us to be fed up. It's just being fed up. We're tired of getting the run around. We're tired of being dragged all over town for jobs that don't exist. We're tired of being sent on jobs that have nothing to do with us. We're tired of answering 50 questions that are clearly stated in our resumes. The list goes on and on.

What I'm trying to say is, instead of calling me arrogant, why don't you try to see that we've all just come to the end of our rope. We can't stand it anymore. IT recruiters have enjoyed the same freedom that the cert prep folks have. They've taken advantage of an unstable market, and pushed a bunch of untrained recruiters at us who know far less about IT than we do. One recruiter wrote me and said that he was an expert in finding a job and we needed to listen to him. Well, being given a lot of bogus info on HR type questions doesn't make you an expert in IT recruiting, or even in landing a job. And being fed up with it doesn't make us arrogant.

Unfortunately I don't see a way around the process. HR certainly isn't the answer. If you think recruiters are bad, don't even get me started on HR. And I believe I said that I have found a coupld really good ones in my time. There are 2 or 3 that I use again and again because they know IT inside and out, and they know the kinds of questions to ask when they're looking at new resumes. The whole field isn't a wash, it's just the majority. But isn't that the problem with even the DBA field? How many DBAs are actually worth their certs? Like I said before, I've interviewed more DBAs than I can count, and most of them, even with 10+ yrs in the field don't even know the basics. It's pathetic. So why should I expect more from recruiters? I guess I shouldn't. I should just take my lumps and get through the process as best I can.

Anyway guys, unless something comes up, this'll be my last post on this for a while. I am going to go back over the last posts and see if there's anything I said I'd come back to and didn't, but I think we can call this topic more or less wrapped up for now.

Any final comments?

Posted by Sean McCown on October 9, 2006 11:30 AM

October 05, 2006 | Comments: (0)

The IT Ego

From time to time you come across something in IT that just seems ridiculous. I just happen to come across them more than most because readers send me stories all the time. What I’m talking about specifically is the IT ego… and we’re all guilty of it at one time or another.

It starts innocently enough. You get assigned a project, and you may or may not know exactly how to do every part of it, but you finally get it worked out and it’s up and running. It doesn’t perform as well as some think it should, but not having anything to benchmark it against, everyone pretty much just accepts that some processes just slower than others. Then a couple months later some know-it-all comes in and sees the process you worked so hard to put into production, and craps all over it by telling you that it’s written poorly and he could improve the performance 10x over in just a couple hours. Quick, what do you do? Most people’s first instinct is to let that IT ego step in and insist that it be done your way. Nobody likes to be shown up in front of their peers, and after all, you did work hard on it. It’s not your fault you were assigned something you knew nothing about. Of course, we all know the problem with this. It gets in the way of real progress and of learning. True knowledge is knowing that you know nothing, and I firmly believe that. There isn’t anyone reading this, no matter how junior or senior who couldn’t teach Ken Henderson, or Kimberely Tripp something about SQL. We all have different experiences. And nobody knows everything, and the super-mega SQL gurus will be the first ones to tell you so. I’ve never met anyone who was considered a world leading expert in SQL who wasn’t relatively humble about their skills. And it’s almost certain that the guy who comes along and improves your process will probably need your help one day.

The problem comes when you get the ones who just refuse to let go of their pride and improve things. They coded it, so it must be perfect, and there’s no room for improvement. And there’s certainly no room for others in the company to find out they don’t know everything. It puts everyone in a bad situation because hundreds of people have to live with your lousy process. It may not have even been written badly. It may have been written fine for the technology or situation available at the time, but now things have changed that make other options viable. In fact, that’s really the best way to approach someone like that. Hey listen, I like the process, but SQL has this new feature that really improves this kind of thing and it would be great if we could take advantage of it. In fact, I was talking to a friend of mine a MS and he told me that they want people using this new process, so they’ve actually made the older one perform much worse. That’s why your process is so sluggish. MS has sabotaged you. And since we’re not going to change their minds, we’d might as well roll with the punches and implement their new method so they’ll at least support us if we need it.
I’ve found it’s best to stroke their egos for stuff like this, because it’s nothing to me, and it’s really the results that matter. The process needs to change, and it doesn’t matter how much you have to butter them up to do it. I actually used this a couple years ago, and the guy believed every word. Of course, the exact improvement I was talking about at the time had been around for years, but since I didn’t use it to begin with, I figured he hadn’t heard of it. I was right.
The point is, let’s get around those egos people. I’ve been guilty of it at times, and I actually had to take a step back, swallow my pride, and say, you’re right. Your process is better. Thanks. Then I limped away and felt small for a couple days while my ego healed. It actually takes a lot of experience to understand that you don’t know everything, and I do it most of the time. But I’m sure I’m still guilty of it sometimes. It’s called being part of a team.

OK, I’ve officially dismounted my high horse.

Posted by Sean McCown on October 5, 2006 07:26 PM

October 04, 2006 | Comments: (0)

The ROI of Benchmarking

I've gotten a lot of emails since Part 3 of the recruiter series, so while I’m sifting through them, I thought I’d change the topic real quick to something else that’s just as important as bashing recruiters.

I was just on the phone with a vendor and we were talking about what it takes to quantify benchmarks. Now, I’m not really talking about the results themselves, what I’m talking about is the process. How do you quantify the ROI you get from even going through the process? When you ask for a benchmarking utility that is typically going to cost into the 10s of thousands, the higher-ups will want to see some ROI for their expense. I’m going to get to how to get to the point of having a quantifiable ROI in a minute, but first I’d like to talk about how stupid it is to even expect it to begin with.

The problem comes from such a complete lack of respect companies have for their DBs. It’s not like every piece of data they own is tucked away inside a filing cabinet and the DBs are just there to create more jobs. In every company I’ve been in for the past 10yrs, the DB has been the central storage mechanism for practically every piece of data in the company. If the DB goes down, everyone notices, and if you actually lose data, the world comes to an end. Yet, companies still treat DBs and DBAs like red-headed step-children. We’re quite often not given the budget to do what we need to keep our systems up and running, or monitored, or backed up, etc. Then when something goes wrong, it’s always our fault. This problem with benchmarking really highlights the poor attitude so many companies have towards their DBs.
Let’s look at it like this. When we ask for a benchmarking utility and a spot in the change process to actually perform even the most perfunctory test, we’re quite often told it’s too expensive and there’s no direct ROI. But show me the direct ROI for implementing anti-virus, or OS updates, or firewall security, etc. All of these things have been accepted as standard costs of doing business in almost every company in the world, yet get someone to sign off on benchmarking their DBs. It’s almost impossible. I was finally (after 3yrs) able to get it going at my last company, but it was a constant fight and I was the only one who was really on board. I know for a fact that they’re not still doing it, so there’s definitely not going to be any ROI now. But it’s an insult. Why do we have to show definitive ROI for a soft process when other groups don’t? I really can’t count the number of times I’ve sat in front of an IT manager with him asking me what returns they would see back from running benchmarks. Do you think that the anti-virus guys have to justify their stuff like that? I’ve never seen it.

And if you take the argument out of IT for a minute, there are lots of things we do because we know they’re right that we can’t actually quantify. Give me the quantifiable ROI on society of not beating your kids, or watching your weight, etc. The point is there are hundreds of things we do that we can’t actually quantify, but we know they’re smart… or at least right. Besides, show me one IT manager who knows the exact ROI for his anti-virus and firewalls and OS patches. There isn’t one.

So how do you go about quantifying your benchmarking process? Well, you have to do something that even the anti-virus and OS guys don’t have to do. You have to actually build a cost analysis for how much time you spend tracking down production problems that are due to poor design, bad indexing, inefficient queries, and the like. This takes a lot of time so don’t expect to have an answer overnight, but eventually, you can go to your bosses with quantifiable ROI that they can’t deny. I was at an Embarcadero presentation a couple years ago, and they showed us a Gartner study that revealed that over $5billion/yr is spent on fixing production bugs in application code in the U.S. This is 100% support cost.

What you do is keep track of the time you spend on issues that are related to performance and data quality. Then when you get to a point where you’ve been doing it for a couple months or so, and you have them all categorized into little subgroups, you can do some projections and go to your boss and show him in hard numbers how much of your time is spent supporting these issues instead of being the creative, forward-thinking DBA everyone knows you can be. The problem is, he may still say no. Go figure.

Now, here’s something that a lot of people don’t think of and I want you to go into battle armed to the teeth, so here’s an argument you might hear. If you’re putting in all this time on support, how much time will you spend on the benchmarks themselves? Well, I’m not going to lie to you. Initially, it’s going to be a lot of work as you learn the tool, and get things setup. You have to get the tests worked out so that they’re accurate, and get your reports in place so you can interpret them. It’s a lot of work, and many DBAs might not even be good enough to do it right. All the same though, what do you tell the boss when he asks that question? It’s simple. Be honest with him. Set his expectations in such a way that’s realistic. It’s not going to be a bed of roses in the beginning because it’s a new process and it has to be learned and improved. But once it’s rolling, it’ll take a lot less time. As you benchmark throughout the coming weeks, start writing a best practices doc that steers the developers and systems people away from the problems that arise from the benchmarks. So if you find that you perform better with locking hints, or getting rid of cursors, or not setting your DBs to auto-shrink, then you can add those things to your doc and publish it periodically. Once these standards are followed, you’ll find fewer things to cause problems, and performing the benchmarks will become perfunctory.
Here’s a short bulleted list of things that kind of summarize this piece (there may be a couple things I didn’t actually mention above but came to me now).

• Keep a lot of performance-related issues you worked on.
• Add up the cost of those issues including other groups you had to pull in.
• Don’t forget to add in a magic number for not meeting your SLAs. This number is something like an extra 10% cost based off of the customers’ perception that you’re not doing a good job because you missed 3 SLAs this month and they may go with someone else because you’re unreliable. So the 10% could either be lost business or the cost of a team of sales guys to go out and spend hours making promises to keep their business. This is a magic number. I use 10%, but you can put anything you like.
• Use a simple graph in Excel to project future support expense for these issues.
• When going to your boss, be honest about the effort involved. This is not a short term solution, but will see direct results in weeks to come. It will also get much easier. This is setting yourself up for success. Don’t become one of those IT shops that only fights fires.
• Make benchmarking part of your change control and your new implementation process.
• Have a list of things to test for. This will also go a long way in selling your boss on it. If you have a list of specific types of issues, it’s much easier to develop a plan to catch them in testing. Now you’re actually quantifying the process because you can certify that you can eliminate certain types of problems.
• As you run your different benchmarks, keep a list of best practices to send to your application people so they can include the performance changes in their designs.

Benchmarking Helps:
• Capacity planning – you know the max load your system can handle and you know what it looks like when it’s put under stress. This is an excellent way to plan for the future because if your box starts showing these signs it’s much easier for you to make a plan of action.
• Baselining – this is almost never done anymore, but even a perfunctory benchmark will give you some good baseline stats. This way, even a new application can be troubleshot a lot easier because you have something to compare the current stats to. If you’ve never taken stats, then how do you know if what you’re seeing is out of whack?
• Reduced support cost – I really don’t have to go over this one anymore do I?
• Build reliable standards – As the process matures you begin to build standards that work for your company’s processes.
• Increases developer productivity – As you find issues in the code and make the developers aware of it, it increases their awareness of how things interact. Too many times devs write code without a single thought to how it’ll play in the production environment. So this will increase their awareness and prevent them from having to go back and release patches. And this frees them up to write more new code instead of supporting old code. See, it’s good all the way around.

Anyway, that’s all I’ve got for now. These are just some quick ideas and this isn’t meant to be a whitepaper on the benefits of benchmarking. Take this and do with it what you will, but at least now it’s being said.

Posted by Sean McCown on October 4, 2006 10:04 AM

October 02, 2006 | Comments: (0)

Are IT Recruiters Worthless? (Part 3)

You know, these hot topics are the ones I really love because they get everything all stirred up. And at the very least people get to talking.

I've had a lot of comments about something I said in the first installment, and I'd like to clarify something. As a side note real quick it's always amazing to me the hills people want to die on. Evidently, I can say anything I like about recruiters as long as I'm dressed properly when I say it. As with so many other hot topics I write on, I’ve had no shortage of readers willing to write and give me their opinions on the topic of wearing sweats to a recruiter interview. And as usual, those of you who agree with me (it’s about 50/50), none of you come out in public through the comments, but choose to pat me on the back privately through email. That’s fine as long as you agree, but it would be nice if I weren’t out here all alone.

All that being said, I am going to clarify something finally. It’s not that I have such little respect for recruiters as people, it’s just that I’m so so tired of the whole recruiting process and what they put us through. It’s a joke the hoops they make us jump through just to get to a real interview. They drag us in there and ask us stupid questions that are clearly outlined in our resumes, and make us sit through a presentation of how their company got started and how long they’ve been in business and why they’re so much better than anyone else out there. And so many times they’re just trying to stock their DBs and don’t even have a real job. For some reason the name of the game seems to be just get the client in the office no matter what. It’s like they’re actually trying to sell us something and it would be harder to say no in person. I mean, do they really think we give a flying…flip… about their company? We’ve got one thing and one thing only on our minds; getting a job. That’s it guys. Don’t try to sell us on your company, and don’t try to tell us all the things you’ll do for us. In fact, you know what? If you want to really do something for me then send me on the interview with a minimum of stupid questions, and run-around. I don’t need you inspecting me before the interview. I don’t need you asking me the same questions again and again that are clearly on my resume. I don’t need you calling me and asking me if I’m interested in a job that’s clearly out of my skill set. And I don’t need to drive 30 miles out of my way to get job specs that you could easily send through email or on the phone. So NO, I’m not always going to dress up and treat you like a real interview because so many times it turns out to go nowhere.
It doesn’t take long to get really jaded to the process, and I have a real hard time hiding my contempt for recruiters once they start in on that… stuff. Go ahead… call me up and tell me you were just going through my resume and you wanted to know if I have ever worked with SQL Server. Then ask me if I’m certified. Really, I don’t mind at all… especially since it’s in size 48 font at the very top of my resume right by my name.

I also don’t wear a suit and tie to interviews. I just don’t believe in it. We don’t wear ties to work, nor is anybody else there in a tie, and I just don’t think it’s something that should be necessary to get a job. Put a random piece of cloth around your neck and suddenly become more respectable.

But you wouldn’t see this kind of crap in any other industry. Could you imagine a hospital recruiter brokering jobs for doctors? The recruiters make them come in to talk about a job that may or may not be real. Then they give them interviewing tips and tell them how to talk and what to say. Then they want to know what they’re going to wear, and may even insist on meeting them in the lobby to make sure they look appropriate. It just wouldn’t fly. Many IT jobs require degrees (believe me, a topic for another time), so we’ve all spent years in college too. And I’ve known many medical students and doctors and there’s nothing in the courses that prepares you better for an interview than any other major, so what’s the deal? Why are we put in this position every time?
Fewer people die most of the time when we make a mistake in IT, but it’s every bit, if not more scientific as medicine. IT certainly changes a LOT more than medicine does, and I’ve always been upset that we’re not more highly regarded than we are. It’s not like we’re out here digging ditches. We’re in a highly technical field and doctors have a few years of med school to get their license, but we’ll be studying for the rest of our lives just to stay in the market. I’m constantly studying and I still feel like I’m just barely playing catch-up most of the time. And yeah, doctors have to keep up their skills too, but they don’t have a completely new procedure or product dropped in their laps every other week that they’re forced to learn because it’s what their customers have already bought. It just doesn’t happen. The same goes with lawyers. You would never see them subjected to the same crap we are. Hell, cafeteria workers aren’t even subjected to our degradations.

And the problem is with the companies. They’ve outsourced their HR functions to the recruiters. It’s getting so you can’t even find a direct posting from a company anymore. If you want the job, you’ll only hear about it from a recruiter. So it’s not like we even have a choice most of the time. So, I don’t even play their game a lot of times. If they want me to come to their office, and I’m going to be in the area anyway, I’ll drop by for a few minutes, but if I’m not, then we can conduct all of our business over the phone. And yes, I’ve turned down interviews before because the recruiter refused to set it up until I came into the office.

With that in mind, here are some of the worst ones I’ve seen.

1. I was stood up twice by the same girl who made me drive 30mls to meet her. Then, when I refused to come out the 3rd time, she refused to setup the interview. So I passed on the gig.
2. I’ve had a recruiter actually come into the interview with me to make sure I didn’t say anything I wasn’t supposed to.
3. I’ve had a recruiter insist on driving me himself.
4. I even had one try to insist that I not work with anyone else. That he couldn’t represent me if he wasn’t going to be my only recruiter. I told him that was perfectly reasonable if he would also agree that I was his only candidate. I want him 100% dedicated to finding ME a job. He dropped it, and I dropped him.
5. I’ve been asked to get the contact info of other hiring managers in the company so the recruiter could use them as leads for new positions. This wasn’t for my current company mind you. I was supposed to ask the interviewer this.
6. I’ve been sold as a Java developer before. The recruiter told me it was a SQL job, and told the hiring manager he had an excellent Java guy. Then when I got to the interview, it was just a mess. I was pissed off, the hiring manager was pissed off, and the recruiter tried to blame it on me. There isn’t Java anywhere on my resume. I guess he thought that once they met me they wouldn’t mind changing the position just to get me on board… I’m sure that’s what the hiring manager was thinking too.

That’s all I can think of now. And those are just the absolute worst. I’ve had dozens of horrible experiences of varying degrees with recruiters. In fact, why don’t some of you share your stories with me and I’ll post them. I won’t use any names, don’t worry.

So the moral of this story isn’t that I don’t respect them as people. It’s that I usually don’t respect them as professionals, and I’m not going to treat it as a real interview when it’s not. It’s just not.

Oh, Oh, Oh… I just thought of one more thing to add to the list above… you’re just gonna love this one. You know how they’ll quite often ask you what you liked about your last job, and what your ideal position would be, etc.? Well, I actually answer those questions honestly to the recruiter because they’re supposed to be getting an understanding of what you’re looking for. Well, one time earlier this year during my last round of job hunting, this girl I mentioned in Part 1, was taking notes during this portion of our talk, and when I finally got to the interview, I start getting questions like this:
Why do you think managers are stupid?
Do you really think you’re so much better than everyone else that you deserve flextime?
Why do you find it necessary to send emails to your colleagues cursing them out?
Etc…

She had written down parts of everything I said, word for word, and given it to the hiring manager. And of course, she took everything completely out of context so he thought I said all those things verbatim. If any of you want those things explained, write me and if there’s enough interest, I’ll give you the real questions and answers.

Read my book reviews at:
http://www.ITBookworm.com

Posted by Sean McCown on October 2, 2006 09:57 AM

Technology White Papers

InfoWorld Technology Marketplace

» Technology White Papers Library

Technology White Papers by Topic

Technology White Papers E-mail Alert