Recently I've been lucky enough to score some interviews for coding jobs (specifically front-end web development) but I've hit the same roadblock every time.
I'm a Doer. This means that I can have an idea for a website, app, etc. and just do it- I can work out how to build a blog with Netlify CMS or make a WordPress Plugin or a fancy CSS animation. Typically this involves google and a lot of trial and error.
The problem is that I'm not a Knower. I don't typically know how things work. I know how to make them work, or at least I can tinker until they do, but ask me or god forbid, whiteboard me and my knowledge always comes up short. Way short. My first technical coding interview was a disaster where the solution ended up being a single line of code and a basic math problem. I've been asked "explain what a [struct/interface/doohicky] is and I don't know the answer.
How does one bridge the gap between "I can do this" to "I know how to do this"? What's the best path forward for the Doers among us who need to build our Knower knowledge?
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (9)
Hmmmm... doing vs. knowing. Well there's a fun one. It's obviously a false dichotomy; to do you need to know, and to know you need to do. I'll have a crack at understanding your particular problem.
and
This sounds a bit like you're at a level of development experience which I've seen before. Talented people who 'can make it work'... eventually. If they have enough time they'll keep changing the code until it does what they want. Then, when it's working they'll push on to the next thing they want to build.
I like to call the first bit flailing - keep typing away until it works. It's definitely doing - but do you know what you're doing? Don't worry too much: most people who write CSS are doing this, so you're in good company.
But you need to get out of this stage, not just because you need to get past an interview, but also because it's better to know what you're doing. You'll get more done, and be able to do harder things.
So... advice.
before fixing something to make it work, have a conversation with someone. Don't have someone? Google 'rubber duck debugging'. Explain what you're going to do and why you think it'll fix things. If it doesn't work, explain why it doesn't work. Get into the habit of explaining.
Say to yourself, out loud if possible, what each line of code in your solution is doing. Is there a bit you don't understand? Google it, read about it.
When you've solved something, explain why it works. Blog about it. If you can explain something in writing it will force you to understand it. Write short posts about what you've learned.
Play with code. Stop trying to get things 'done', instead pull them around a bit to see how they work. Can I do this with a
forloop, with reduce, with a class, with a function, as a single expression, with recursion... how many different ways are there? Which do you prefer? Why?Stop tinkering to make things work. Start tinkering to find out how they work.
Do more katas - coding exercises. Exercism or Code Wars are good. Read other people's solutions.
Go slow. Much slower. Stop trying to be effective and productive, start trying to understand. Slow is smooth, smooth is fast.
Good luck!
Thank you for the insights!!! Those bullets are super helpful. I'm definitely guilty of "done, next" type development! I will try and take your advice. I've enjoyed blogging so far and just began to understand something important on my new project so will write about that soon!
The relationship between Doing and Knowing is an incredibly important one than that absolutely transcends programming.
I disagree with the others who say it is a false dichotomy, it may be the defining argument in western philosophy since Plato and Aristotle.
Given the primacy of the topic, there's some really well nurtured thinking about it:
Dodging contemparay philosophy, there is good thinking on this topic in Anglo-saxon and Icelandic poetry. The Havamal from the Poetic Eddas often repeats the refrain:
The vocabulary of the directive blurs the line between appropriation and learning. The advice is something to be "taken" and "had" and "used". These words of appropriation do the powerful work of turning knowledge into an axial force of advantage in the territory of that which is or will be "done". Though it appears simple, the Havamal is very good at finding the subtle balance between knowledge had and actions done. It shows how the two co-create each other, but are in fact different and distinct capacities.
Wow, I didn't expect a philosophical angle. This is incredibly interesting! Thank you for your input, I will check out some of the sources you mentioned. Perhaps by better understanding each concept (doing and knowing) I can bridge them more effectively. Thank you again!
How did you write all this and not say 'praxis' even once I'll never know... 😂
Me too man, me too.
In my experience, most knowing actually comes from doing. That's how things stick. You'll already have learnt a lot from your projects, even if it doesn't feel like it.
With that in mind, if you want to learn algorithms (etc.), here are a couple of ideas:
Improve an existing project -- Look at an area of one of your projects and ask yourself "Is this the best way to do things?" Could, say, that array be a map? By Googling the question, you'll learn a lot.
Read actively -- Find a book on the subject that you're trying to learn. As you do so, think how it applies to your projects. This will help with the first point.
Being a Doer, you're already in a good place!
Thanks for the suggestions! I definitely want to invest in a good book, even if it starts from the beginning!
I think I made that transition by taking lots of online courses about the stack I was working with at the time. Back then I would constantly get that feeling "Oh, so that's why we do it like this"...
I would also always ask more experienced developers to explain what they knew about that particular subject, and see if what I had learned was correct.
When you study about the stack you use everyday you get into a positive feedback loop where you get to see tons of real life examples about what you have learned, and have the opportunity to practice using them.
Once you have an understanding about what problems the language and the frameworks you are using are trying to solve, and how they do it, it's really only a matter of transposing and filling the blanks when dealing with something new, so it gets easier down the road :)
Hope it helps!