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.