How to explain that you know how to do something but can't explain it?

April 16, 2021 11:53 AM

This could be any skill and not just my immediate example. I had a job interview and the data analysis person asked me about my data cleaning and merging several sources together for analysis techniques. I had no clear answer. Literally, my technique is to look at the data and their sources and go to work based on what needs to be done. I like to think that I'm good at it.

I really, really like to think that I'm really, really good at merging, cleaning, and making large data sources useable. Hold the Dunning Kruger Effect comments, but expertise theory holds that experts often cannot explain how they do things. I used to do market research across countries and pulled data from various sources that never matched or made sense on their own. Then I put it all together to tell a great story, but I can't really tell you how I did/do it.

Of course, after the fact, of course, I have been able to think about a really impressive and regularly occurring task that I had to perform monthly on a large data set, but too late.

I hope I said it better than this, but how do you explain that "I just do it. I don't really know how".
This question could theoretically be applied to any skill or topic. It's not necessarily about job interviews, but job interviews might be a special high-stakes example.

posted by Che boludo! to Computers & Internet (22 answers total)

One approach to this type of question could be to describe a specific time when you had to do that process, and the factors you considered in that particular case.

IMO “how do you do x process in general” isn’t a very good interview question — sometimes interviewers don’t always ask the best questions, but you can run with the general topic of the question and give specific examples. Details stick in people’s minds.
posted by mekily at 11:59 AM on April 16, 2021 [9 favorites]

I think there's different types of expertise. Some experts are the best at execution - they can do things incredibly well. Think Olympic Marksman. Others, are experts because of their knowledge about a topic. Think a Professor of Law. Others, might be experts because they are so effective about communicating about a topic. Think Richard Dawkins.

Unfortunately, in an interview or high stakes conversation, it may be tricky to signify the first type of expertise, without having the expertise in communicating about the topic as well. Hopefully, you come prepared with enough examples of work that you can use that to communcate!
posted by bbqturtle at 12:02 PM on April 16, 2021

I really have trouble explaining how to do things in the moment, in part because the kind of task you're talking about here is somewhat repetitive but also somewhat figure it out as you go. Literally last night I put together some documentation for a data analysis project because creating a five page description of my workflow was, for me, so much easier, faster, and more intelligible than my boss' suggestion of "just hop on Zoom and explain it to the student you're mentoring as you're doing it."

However, I find that after I've created a good written explanation of the component parts of a task and why I chose the workflow and tools that I did, it's much easier for me to then explain it to someone in a conversation. I suspect this is due in part to having structured my thoughts about the tasks a bit more, but also because in the process of putting together documentation, I usually look up a bit more info about not just the how but the why part of my workflows, and end up teaching myself a bit more along the way.
posted by deludingmyself at 12:07 PM on April 16, 2021 [17 favorites]

You give examples showing that you are familiar with common problems and issues and with the structure and nomenclature in the field in general. You can start with "the data and their sources and go to work based on what needs to be done" - but you might be clear about what in the data or sources you are evaluating.

Generally in any job interview, it's great to prepare to talk about a few big meaty projects you led or played a significant part in. You can keep going back to those projects to walk through decision making, inflection points, challenges, successes, setbacks, etc. "I mentioned before the project where we had to integrate the data from ABC with our existing data set. We had problems around X and here are some ways I evaluated and addressed those problems."
posted by vunder at 12:11 PM on April 16, 2021 [1 favorite]

So to more directly address your question: if I were prepping for a job interview, I'd probably spend most of my prep time trying to work out (in writing) more cogent answers to likely questions. But if I specifically needed to communicate "I'm better at doing this than I am at explaining it," I suppose I'd talk about how I write documentation to explain this type of task to other people, and why writing that documentation first works better when I'm mentoring someone about how to do a complex task I'm good at.
posted by deludingmyself at 12:14 PM on April 16, 2021 [2 favorites]

"I really, really like to think that I'm really, really good at merging, cleaning, and making large data sources useable. Hold the Dunning Kruger Effect comments, but expertise theory holds that experts often cannot explain how they do things. I used to do market research across countries and pulled data from various sources that never matched or made sense on their own. Then I put it all together to tell a great story, but I can't really tell you how I did/do it."

I think it sort of involves diffuse and focused thinking- a lot of focused thinking often omits speaking. Often the best way is just to do, not articulate, which isn't always possible in interviews- this sounds like a question that can be segued into technique, where you can perhaps turn the conversation.

Of course, leave out anything super valuable or that which you wouldn't want someone else to know 🙂
posted by firstdaffodils at 12:17 PM on April 16, 2021

One way of thinking about it is, if you were interviewing someone to work along side you, what would you want to hear from them to assess if they could take a messy data set & fix it on day 1 or if you'd be stuck teaching them basics? Think of what you would want to hear & try to give them that.

I think it's also great to think of a specific project, go back & try to reconstruct what you did step by step so you can rattle it off. If you can't go back to a real project, maybe google around for some data sets, find a real bad one, & then step through your process.
posted by bleep at 12:36 PM on April 16, 2021 [3 favorites]

Explaining complex or technical tasks is its own skill. The first IT Manager I ever had knew a lot of technical things, but his main goal in self-improvement was to acquire the skill to explain things to people (and in general, find the right level of explanation).

You perhaps have heard of rubber duck programming, where before you ask a technical question fo someone else (programming being the original topic from which this concept is drawn), you first ask the question of a rubber duck. Often, in formulating the question, the answer becomes apparent, because asking the question well requires organizing your thoughts into a narrative you can verbalize.

Explaining stuff is also about creating a narrative, where you tell the story of both actions and motivations, as well as conflicts and their resolutions. If the question is as open as this one, you populate the narratives with examples without necessarily going for completeness. Let's say you said, "I look at the data and sources and decide what to work on. Often a source needs a small reformat, so I use X tool for that. Other times a source needs to be sanitized because of sloppy entry, so I use techniques such as Y and Z. Once in a while a source is defectively exported, so I work with a person in Role A to work out the problem there." You just described 3 challenges you regularly experience and how you deal with them. You included some simple stuff that you automate, some complex stuff that you do the work, and some people skills. Now wrap it up. "I keep my sources organized so I can respond appropriately to data conflicts, and also help people give me better data."

Practice makes perfect; if you can come up with answers (or get help with that), you an hone your skill at answering them in the shower.

Good luck on the job search.
posted by Sunburnt at 12:40 PM on April 16, 2021 [6 favorites]

This is what is called implicit knowledge (vs explicit). We gain a lot of skills through trial and error, language acquisition being a great example. We don't necessarily know the rules for grammar in our native languages, but we usually have a good sense of what "sounds right."

So you've done this a lot and you've learned techniques for doing it that work well, but you don't know formally why they work, and you haven't boiled it down to a workflow that anyone could follow.
posted by adamrice at 12:43 PM on April 16, 2021 [1 favorite]

Yeah, as said above, I think the magic word is 'workflow.' There are plenty of people who can do a thing, but it takes some next level thinking to capture the distinct processes and descriptions that go into a workflow.
posted by Dmenet at 1:06 PM on April 16, 2021 [3 favorites]

You can also start off your answer with
“After 10 years of blah blah blah it’s become pretty intuitive, but this is how I start out the workflow. I check that this, that, and the other are present- and that these conditions are present. This helps me gauge whether I will need Jjjj type of assistance....”
And then maybe explain resources that you usually need and how quickly you can accomplish the process.
Also maybe some typical problems and how you solve them...
posted by calgirl at 1:21 PM on April 16, 2021 [1 favorite]

Addendum: May be helpful to frame it as writing a tutorial, which is of course, a sign of deep learning.
posted by firstdaffodils at 1:54 PM on April 16, 2021 [1 favorite]

Begin along the lines of, "there are a number of factors." Then illustrate with a few specific examples until they're happy.

Generally, introducing complexity is respected even if the complexity isn't delineated. There are a number of factors why.
posted by michaelh at 2:15 PM on April 16, 2021

how are you going to train team members, if you're as good as you say?

that's going to be part of the job if you are actually 'expert'.

i say, figure out how you do it. you need the self knowledge. when i do tech interviews, i weight ability to explain problem solving process about 5x more important than 'having the right answer and no idea how to articulate the approach'.

career wise. maybe time to do how-to vids, blog/medium articles, conf presentations, and stack overflow answers.

i see this a lot in really good but self-taught guys. the problem many times is not having the shared precision vocabulary available from rigorous training. tha answer to this is read. a lot. "ahhh..so that's what this is called. I've been doing that for years."

one example in software is design patterns. a major point of the primary texts is "shared working vocabulary and understanding of concepts."

i super encourage you not to simply accept: i can't explain it. this is a career and personal challenge with compounding benefits.

best, j_
posted by j_curiouser at 2:16 PM on April 16, 2021 [7 favorites]

One of the things this interviewer might be looking for is reproducibility/consistency.

“I just do it on autopilot” is why arrestees are mandated by law to have their Miranda Rights read to them.

If your analysis process cannot be reproduced by the person who comes in after you - even if they person is you two weeks or months later, then it is not great.

The magic words might be

“Because the process depends so much on what’s going on in each data source, the questions being asked, and the tools available, I document as I go for each data source/set. If something goes sideways I can start over/trouble shoot.”
posted by bilabial at 2:18 PM on April 16, 2021 [1 favorite]

I was impressed recently by an interview candidate who took every "how would you --" and gave an example. So that's ideal.

In the case where he couldn't - because he hadn't done it before - he gave a good philosophy answer like so: "I would find out who the key stakeholders are, ask what their needs are, and review the different processes they use to understand how it fits together"

What we were looking for was basically, I understand there are many people involved, I'm interested in listening and learning, I don't have one "hammer looking for a nail" answer I apply to everything.

So for you you would say, I look at the data tables, I would see how often the various parameters or tables are being used, I would look for common fields between the tables that could be used to match up data, I would look for obvious errors, I would talk to the end users to make sure they agreed with my changes (I would definitely NOT delete YOUR important troubleshooting information like the LAST guy did --)
posted by Lady Li at 2:52 PM on April 16, 2021 [1 favorite]

Like j_curiouser said, don't settle for learning how to explain that you can't explain how you work. Learn how to explain your process.

Imagine you're looking for contractors to work on your house (or whatever). Contractor A can't explain how they are going to get the job done, but assures you they are really good at it. Contractor B is able to explain how the work will proceed in reasonable detail and tells you about similar projects they've worked on and how/why they were successful.

There really isn't any competition between the two contractors — maybe Contractor A really is quite good, but are you going to take that risk? You have to rely on their promise, while Contractor B demonstrated expertise. It's an easy choice.

You do not want to be Contractor A. Learn how to be Contractor B.
posted by TurnKey at 3:37 PM on April 16, 2021

This is procedural knowledge, or “knowing-how,” as opposed to declarative knowledge, or “knowing-of.” For example, I might be able to recite the Gettysburg Address (declarative knowledge)’ but I can explain how I move my vocal cords to say the words. (Procedural knowledge)

From the Wikipedia article, ” A person doesn't need to be able to verbally articulate their procedural knowledge in order for it to count as knowledge, since procedural knowledge requires only knowing how to correctly perform an action or exercise a skill.”
posted by chrisulonic at 3:45 PM on April 16, 2021 [1 favorite]

Once upon a time, there was a field in artificial intelligence called expert systems. The notion was to follow experts around, have them explain what they're doing, then capture it it code. It failed at the explanation step.

Expertise is making calls based on experience in the face of uncertainty. In real life, experts get a lot wrong. IIRC, autopsies show that the cause of death is initially wrong 10% of the time.
posted by SemiSalt at 5:49 PM on April 16, 2021

If I wanted to say what you’re saying succinctly in an interview, I would say “My process is to look at data holistically. One set of data may not make sense on its own, but when I look at multiple sets of data, I can see a story emerge. My [skill/talent/process] is to find the hidden relationships between disparate data sets, and cleaning and merging them accordingly.”
posted by ejs at 11:15 PM on April 16, 2021

In addition to the points made above, for the specific example of data management, if I were hiring for this I’d want to hear you talk about the tools you use for this work. I have my own preferences, but mostly I want to hear that you have fluency in some language (SQL, SAS, R, whatever) and that you’re not just managing this with a lot of manual copy-paste into Excel. I’d also want to see that you knew about common things to check for, like unwanted duplicates and whether you’re doing what you intended to with unmatched rows. I’d want a sense of whether your workflow was reproducible and whether you understood that it was your responsibility to make it so.

I wouldn’t accept “I just do it, I don’t really know how” as an answer in this field — it is detail work and you must be able to explain what you did. Otherwise why should the people who have come to you with data and a question trust that you have gotten them a correct answer?
posted by eirias at 4:18 AM on April 17, 2021 [1 favorite]

>I think the magic word is 'workflow.' There are plenty of people who can do a thing, but it takes some next level thinking to capture the distinct processes and descriptions that go into a workflow.
I think it's a good discipline to try, partially because that gives you (here and forward is plural you) places to try improving the workflows and partially because of this problem now selling your skills. Notably, it's not big jump to write down a sequence of boxes for a flowchart and then look for improvements.

We have this view that data carries incomprehensible detail that needs savant-like skills to work on. That's cute but unhelpful because colleagues need us to be someone they work with. Either technology is magical and the province of few or technology is everywhere and many people have the techniques to gain from it -- so being able to improve your techniques and share your knowledge with peers is an essential skill. Moreover, if you're the knowledge worker with the rare skill, you don't scale. That means when the business grows to deal with more data, you will need to model some of the steps of the workflow with a view to expressing then in programming languages to make the data machinery do this work for you.
posted by k3ninho at 7:36 AM on April 17, 2021