What is the best advice for a cowboy coder interviewing for a senior position
i’ve code my whole lot, it’s one of my few talents where it comes a lot easier than most things i do. i’ve been told my whole life i was gifted, i shrugged it off thinking it was just flattery, later on in life decided to talk to other more experienced devs, i was shocked that i was not only able to keep up but confuse them with things that i thought was how every coder was able to do. i have somewhat low self worth because of being raised in extreme poverty and having little to no guidance when it came to career advice. i am able to understand code, even if i haven’t read a document on it after like a week of studying and tinkering around with things, i assume this is somewhat normal, my question is, how can i get past the whole intimidation during an interview, i know i can give them what they want but, i feel somewhat unorthodox, i don’t think it’s an issue all the time but i am def not 100% tech bro, any advice would be helpful. thanks!
3 comments
Not being "100% tech bro" is usually a positive. Assuming your technical skills are where you say they are, I would focus on your communication and making sure you are able to clearly verbalize your thought processes in an interview. Having just this post to go by, I notice you don't use proper grammar or punctuation when you write. You also use many run-on sentences, as if you're just spewing out what is in your head before formulating it clearly. But I know HN is not a formal place, so maybe this is not how you write in professional communication. Do you feel that you can confidently express what is in your head when faced with a question during an interview? Do you put effort into writing professionally when communicating with potential employers through email?
Another thing that stuck out at me in your post: being able to "confuse" experienced devs with things is not usually a good thing. As a senior, you need to be able to communicate and explain concepts clearly in a way that is _not_ confusing to people.
Finally, a question: since you are applying for a senior position, I am guessing you already have a few years of junior and mid-level jobs under your belt. Is that a correct assumption?
Another thing that stuck out at me in your post: being able to "confuse" experienced devs with things is not usually a good thing. As a senior, you need to be able to communicate and explain concepts clearly in a way that is _not_ confusing to people.
Finally, a question: since you are applying for a senior position, I am guessing you already have a few years of junior and mid-level jobs under your belt. Is that a correct assumption?
This is a great, but confusing, position to be in. You have a great start, but there is a huge different between being an amazing programmer and being a successful leader of programmers. In most companies, they don't really want that 10x programmer, and if that's what they are trying to hire, you don't really want the job. Technical leadership is about getting everyone on the team more productive and only jumping into the weeds, and being hands on, when you absolutely have to.
A great way to do this, as a senior technical person, is code review. Every note you leave has the potential to make someone a little better at their job. That means, over the course of the year, you can make 10-20 people 10-20% better - however, doing so, without pissing everyone off, is an art and takes practice.
Another place you can help is systems level thinking. Not necessarily telling people how to build something, more so about helping people understand the tradeoffs and making an informed decision.
Yet another way is to use your gift to make hard things easy, so others can learn too. Every company / team has a regression towards the mean effect. But, if you can make complex things digestible to everyone, that adds real value.
New engineers have to figure out how to write code and be productive. Mid-career engineers can make smart decisions, do things faster / more efficiently and every once and a while, pull a rabbit out of a hat. Great technical leaders turn more of the aforementioned into great technical leaders.
A great way to do this, as a senior technical person, is code review. Every note you leave has the potential to make someone a little better at their job. That means, over the course of the year, you can make 10-20 people 10-20% better - however, doing so, without pissing everyone off, is an art and takes practice.
Another place you can help is systems level thinking. Not necessarily telling people how to build something, more so about helping people understand the tradeoffs and making an informed decision.
Yet another way is to use your gift to make hard things easy, so others can learn too. Every company / team has a regression towards the mean effect. But, if you can make complex things digestible to everyone, that adds real value.
New engineers have to figure out how to write code and be productive. Mid-career engineers can make smart decisions, do things faster / more efficiently and every once and a while, pull a rabbit out of a hat. Great technical leaders turn more of the aforementioned into great technical leaders.
I think in your case there is an incredibly specific and practical way to solve this problem.
Books and online courses.
You already have great hands on skills. If you have the attention span for it you can improve your overall model of the system by reading books like Designing Data Intensive Applications. A good place to start for a reading list would be https://teachyourselfcs.com/.
When you have an aptitude for something there are sort of two natural directions you can go. It's possible to settle into a sort of "expert beginner" stage where you stop at a local maximum. The other option is to take the leverage that you already have and lever up again, hard. Those obscure and really useful programming tricks that you like, read some books on those too. See if you can find a conference talk where someone describes one. You probably know everything they're going to say anyway...except maybe one more trick that you can glean from that talk.
This is the path to Mastery.
You can also dig into some of the more academic content on youtube like MIT's algorithm courses stuff like that. But really I'd recommend just scratching your own itch.
In a lot of cases the answer to imposter's syndrome is "hey yeah, we all get it. Perfectly normal." In this instance though I suspect doing some reading will go a long way towards making you more comfortable.
Books and online courses.
You already have great hands on skills. If you have the attention span for it you can improve your overall model of the system by reading books like Designing Data Intensive Applications. A good place to start for a reading list would be https://teachyourselfcs.com/.
When you have an aptitude for something there are sort of two natural directions you can go. It's possible to settle into a sort of "expert beginner" stage where you stop at a local maximum. The other option is to take the leverage that you already have and lever up again, hard. Those obscure and really useful programming tricks that you like, read some books on those too. See if you can find a conference talk where someone describes one. You probably know everything they're going to say anyway...except maybe one more trick that you can glean from that talk.
This is the path to Mastery.
You can also dig into some of the more academic content on youtube like MIT's algorithm courses stuff like that. But really I'd recommend just scratching your own itch.
In a lot of cases the answer to imposter's syndrome is "hey yeah, we all get it. Perfectly normal." In this instance though I suspect doing some reading will go a long way towards making you more comfortable.