I wanted to follow up to this post DBA Job Hunting Tips. I received a resume from one candidate that I really liked how they organized the information about themselves. It went in line with many of the things from that first blog post. The candidate didn’t want to share the resume so I simply made a new header for my resume and will use that. Below is an example of a really simple clean header that gives me all the information I need to look this person up online and saves me a lot of time.
As you can see I listed out my blog, Twitter feed and LinkedIn profile. This gives the person looking at this resume easy access to all the work related information they need for me online. If you speak often a link to your SpeakerRate profile would be a good idea as well. You should always go out of your way to make it easy for a hiring manager to find information about you. That person may be going through hundreds of resume and saving the hiring manager time is a good idea.
Since I’ve been doing interviews all week here are a few tips as well.
- Be passionate! Make it sound like you really want to work here you are applying for the job so I’m assuming you really do want to work here. This is a very important point for me.
- You will not have all the answers, Let me make that 100% clear you will *NOT* have all the answers. Don’t be afraid to say I don’t know but I have these resources to use at my disposal (google,twitter,blogs,friends and etc…) and describe how you would find the answer.
- Don’t afraid to be technical. You may be doing an interview with a HR person that doesn’t know SQL from Perl. Don’t be afraid to ask how technical do you want me to go? List out direct statements if you can or if they want a technical answer.
- Be early. Notice I didn’t say on time. Again show me that you want to work here if you are excited and really want to work here then you need to show me that.
- Practice! Hold mock interviews with your friends. Go present at a user group to get used to talking in front of people. If you can get in on doing an interview I suggest it to get another perspective.
- Keep a clean appearance, If this is a phone interview you can ignore this but sooner or later you’ll need to do a in person face to face interview when that happens dress appropriately. I’m not a big fan of a suit and tie for interviews typically because I’m interviewing developers / DBA and we don’t normally wear that every day in our work environment. Wear something you will be comfortable in but still looks professional. Bonus points if you wear a really geeky shirt like from www.thinkgeek.com.
The key item on this list for me is #1. When someone does not a question I see that as a teaching opportunity for a candidate that really wants to learn. If the person is not passionate then I’m assuming they don’t want to learn and don’t want to move forward with the career they have chosen.
These tips are very subjective as everyone interviews and hires people differently this is what works for me and what I look for but no matter who you are talking to if you are passionate about the subject it will show.
Wow 4 months without a blog post. I’ve been a lazy blogger. 🙂
In reality this seems to happen to me when I start a new job. I get so focused on creating a new project I lose a lot of time to write blog posts or participate in social networks. I’ve taken on a few new contracts as well and volunteer items so it’s been a busy 4 months for me. I’m going to try and get into the habit of writing up a blog post a week. I have 2-3 already written/drafted so those should get scheduled in the next few weeks.
At my last job I was responsible for hiring a new DBA for the team. I’m in the same position at my current company and am looking for a DBA. I’ve gotten a few resumes already and just wanted to share what I typically go through to review candidates. Now keep in mind this is before I have talked to them, emailed them or scheduled some sort of interview.
- Google the candidates email address. I look at the results returned but also look at the discussions list to find what Google groups they might have been asking questions in and what kind of questions.
- I search on Linked in by the name of the person. Google can find this as well I like to put a location behind the name like SLC so it finds the local person. That is of course if the person is local.
- I review what I find from Google and LinkedIn. If they are on LinkedIn I find out who else is in my network I can possibly ask for a review. I review the information listed on LinkedIn and the reviews they have gotten from other members of LinkedIn.
- If they have blogs/twitter and I can find that from the email or name that was given then I review that information as well.
These are the typical steps I do before even calling/speaking with a candidate. This doesn’t mean that I’m not going to interview someone just because of what I find. It just provides me with more information about the candidate.
So if you are out there looking in the market for a DBA position (like this one! (http://www.allegiance.com/company/career-opportunities#da) I would suggest placing this information clearly on your resume so that it’s easy to find. It will at least make my life easier and I’m sure others will appreciate it as well.
I wanted to get a follow up post to my recommendations for DBA’s for the first day on the job post. After a very busy week last week here is where I stand on my list and what I should add for the next week.
- Get a list of Servers I’ll be managing/owning: I’ve got the list, can’t say I have access to all of them but working through that.
- Run the SP_Blitz: I’ve got this done on several servers and honestly haven’t done a ton of analysis on it yet. Still high on the list.
- Get a DBA database created on each server: Done for known servers.
- Create the server side trace: Done for the primary prod servers.
- Create perfmon counters: Done for the primary prod servers.
- Install SSMS tools pack: Done (and it’s already saved me),
- Check the backups/backup schedule: Taken care of by a managed host provider, many changes in store for this one.
- Check the security model and who has access to the DB: Figured out most of this and some changes are in plan for the future as well.
Things to Add after your first week.
- Developer communication/training. We have a developer training planned this week and I’m prepping a presentation based on performance tuning and some of the procedures I’ve worked on over the last week. It’s a great time to start building relationships with the DEV team and working with them to improve the app and server even more.
- Slow procedures/query tuning. Now that you’ve had your trace and performance counters in place start researching what you can do to improve the performance of the server. Perhaps hardware is needed or memory settings need to be changed. We saw a big increase because of a server mis-configuration in the memory settings.
- DMV’s, I want to get these into the first week list but didn’t have a chance and don’t have an automated procedure but am researching some right now and plan to have them running in the next week. Capturing query info and index info in DMV’s are key.
- Optimizations, unfortunately there is still a lot of mis-informaiton out there about what needs to be re-indexed/rebuilt and checked. I’ve found a very heavy optimization job running on the servers and need to re-factor this to really help the performance of the server. This is top on my list as it’s running into prod time and needs to get fixed. I’ve also found Shrink jobs running (never a good thing).
- Last major suggestion for this week is be cautious. You’ll find lots of things that you want to change and you may be tempted to start making wide sweeping changes but be careful. If your systems haven’t been looked at by DBA eyes for a while then making large sweeping changes could have a huge impact on the system. Make sure to document and test anything you put into place. One method I use for this is getting a mailbox setup that I can email my changes to and store them that way I have a history. If you have a Team of DBA’s with you this works well to inform all of them at once.
Hopefully I’ll get a chance to blog out mid next week with some of the scripts I’ve been talking about. Let’s see how this week 2 goes for me. 🙂
Posted in DBA
Tagged DBA, sql, week2