Several years back, I had the pleasure of working with Paul Randal (blog – @PaulRandal) – first in the Microsoft Certified Master program, and then later at SQLskills with Paul & Kim. I had a phenomenal time – they’re truly wonderful people – and I want to share two of my favorite lessons that still come in handy every week.
1. When answering, be comfortable saying “I don’t know.”
When someone asks you a question that stumps you, be honest immediately and say:
“I don’t know, but here’s where I would go look: ____.”
If you try to fake it, and the other person knows the real answer, then they’re going to know immediately that you’re faking. Even if you stumble into the right answer, your answer delivery is going to give you away.
If the other person doesn’t know the right answer – like if it’s a client asking you a technical question to solve a problem – you might be able to bamboozle them. However, when they go to put your answer into practice, they’ll hit roadblocks, and you won’t look good.
By explaining where you would go look, you’re showing that you’re the kind of person who won’t just ¯(ツ)/¯ and call it a day. Interviewers aren’t just checking what you already know – they’re also checking how you learn, and how you test solutions.
2. Before you ask, build a test.
When you ask someone a question, you’re making a demand on their time. Before you take their time from them, do them a favor – spend a few moments building a test.
Don’t try to figure out the answer, necessarily – that might be hard – just figure out how you’d test the answer.
For example, in SQL Server, trace flag 1117 grows all data files at the same time so they remain the same size. SQL Server 2016 has that behavior by default for TempDB – but what about user databases? Does it handle that for me too? Say the manual isn’t clear enough for me.
Before asking someone, I could just build a test:
- Create a database
- Put four data files in it, all 1mb in size
- Set up a loop script of inserting data into a table
- Watch the files grow as the script runs
If you can describe the test in thirty seconds, then you need to build that test rather than asking the question. It’s not just about respecting the time of others – it’s also about teaching you how to find things out for yourself. The act of building tests like this will teach you all kinds of things about the tools you use.
4 Comments. Leave new
Thank you!
Wow, one of the best blog post. The rookie like me can indeed be proud of the #1 – I do not know. However, I accept that quite often I have asked question without building test case, this is something critical for everyone to remember.
There are moments, I do not know how to recreate scenarios. Those are the moment, I try to remember to learn more about everything which is related to the subject so I can build a reproduction scenario of the issue. Once I build the same, I know I can easily ask my mentor for solution.
Once again – thank you for sharing. Though this may look like a blog post with few words, I think the rules can create a big impact in people’s life.
Thank you!
Great post, Brent. My first DBA mentor gave me the best professional advice I’ve gotten:
1) Don’t ask me if you haven’t tried to answer it yourself.
2) If you can’t find an answer after making an honest effort, tell me what you tried.
I will add “build you own test” to the list.
Thanks again
I know this was from six years ago, but it is still just as if not more valid now as it was then.
I’ve never really had a DBA mentor. I’ve depended on all of the wonderful folks who post their discoveries, knowledge and understanding online to point me in the right direction for pretty much anything I’ve learned to do.
Thank you, Brent. Thank you Sql Family.
Richard
[…] Read this and do a test. […]