Previously seeking a new job was not a problem, but now I am afraid to pursue positions past initial contact because I feel like I will completely fail due to lack of skills. I see people less qualified than me switching positions but I can't get out of the starting gate. Even turned down an in person interview in Austin because of this fear.
It seems that many HN jobs and other developer jobs test on CS fundamentals. I don't remember a lot of algorithms/data structures/discrete math/etc and/or use them much day to day beyond basic needs (list/array/hashmap) - my current job simply doesn't require advanced knowledge.
I'm currently reviewing CS fundamentals and practicing code challenges on code eval - which I enjoy because I like solving problems and learning.
I would like to pursue a new/challenging opportunity - is my fear unfounded or should I study more before interviewing?
I've been rattled by every job interview I've had. That includes interviews for roles that I'd been courted for. It includes interviews for jobs I didn't even want, where I was interviewing mostly because a friend had asked me to. One of those interviews was for a company I actively disliked and would under no circumstance work for. I didn't sleep the night before! I did a multicast streaming media company in the late 90s and owned the router; later, I interviewed at a friend's company, got asked how to implement Towers of Hanoi without recursion, and for the rest of the day forgot everything I knew about routing protocols --- despite having spent the preceding two years doing nothing but implementing them.
Job interviews suck. They're hostile processes that involve complete strangers not just sitting in judgement of you, but also working under the delusion that their job is to break you so they can avoid hiring "B players".
I basically interview people for a living now and pay pretty close attention to this, and have come to the following conclusion: there is zero correlation between how people comport themselves in job interviews and their ability to do a job.
My best advice is, know the stuff you know. If you want to bone up on algorithms and data structures, don't cram. Implement them in your most comfortable language and watch them work, and go to the interview knowing not that you can recite them from memory, but that push-to-shove you can in fact throw down and get them working. Then just answer questions honestly.
The hardest interviews you take might be for the worst, most dysfunctional teams; a mean (or even just wicked) streak in interviewing candidates is a sign of broken teams, not weak candidates.
Good luck!
This is a generalization that doesn't always ring true.
As I've gained experience, I've come to enjoy interviewing at times. Especially when I'm going into an interview where I feel quite comfortable discussing that particular domain.
If you're someone who doesn't mind social interaction and who doesn't lack confidence (for better or for worse), interviewing can be an enjoyable experience.
I doubt that I'm the only one who feels this way.
It's something about the "set and setting" of a job interview.
I'm unsurprised if there's a lucky cohort of people who just don't have this problem. Enjoy! For my part, I'm looking forward to spending more and more of my career beating the tech job interview to death with my bare hands, because I loathe it --- from both sides, as a candidate and now a hiring manager.
Death to interviews!
I will continue to learn for the sake of learning which I've always done - not so much for interviews but to learn how to solve problems in different ways.
This will ease your rejection fear, and train you to handle it.
Some people think they're worth more than they deserve, most think they're worth less. Being able to navigate the negotiation of my value has always been the hardest part of interviewing for me.
There's a good talk on the subject from PyCon (https://www.youtube.com/watch?v=1i8ylq4j_EY).
It seems like you feel that you're afraid of getting rejected, but if you're turning down in person interviews, that seems like you're worried about the interview itself and not what happens after.
It's important to clarify because they're two very different problems. Turning down offers to interview is silly; if you get rejected from the job, you haven't lost anything (because you don't have the job now anyways) and you get the experience of interviewing. Based on how it went, you can then start pinpointing where your weak points are and start trying to shore them up.
Don't be so concerned about nailing the first interview out of the gate; interviewing is a skill like any other, and it's okay to need some practice.
Then I decided I wanted to shoot higher and had phone screens at Amazon (1) and Google (2) - 2nd video interview. These rejections have skewed my view.
You are doing absolutely the right things to succeed at it -- you just need practice at doing it live.
3 weeks ago, I had an interview at the big G. I wanted the job sooooo badly that I was insanely nervous during the interview. The interviewer asked me to write a piece of recursive code and I fell flat on my face. In my nervous state, I couldn't keep the problem and variables in my head. I had no concentration/focus whatsoever.
When the call was over, I did the task in about 20 minutes. No problem.
I DO NOT UNDERSTAND why coding under pressure, while someone is watching and judging, should be a part of coding interviews. Some people may be highly affected by the pressure. Others may have no problem with it at all. This means that people who are naturally more nervous are going to underperform lesser engineers who don't get nervous.
Now, if coding under pressure is part of the job, great. Then this method is appropriate. But it never is. Coding is a solitary, concentrated, focused effort. To test someone outside that natural environment is to not test them at all.
I honestly don't get it.
Look at it this way, if you've really been developing that long, you're a fricken veteran. Unless you've been writing up TPS reports in Excel for 13 years, you've seen and used a wide variety of tools to build projects, and get things done. New grads may know the difference between a tree and a trie and how to optimally traverse each, but you know how to define a project, what to expect as you scope it, what types of tools tend to work best for different approaches, how to develop with an eye to scaling and maintaining, how to test things, how to deliver them to end users, and so on.
There are probably dozens of types of projects that I could ask you about in a social setting, and you could immediately deliver a 5-minute sketch of how to design and build them from scratch, pros and cons of various approaches, likely problem areas, etc. That comes from the experience of having lived it for a decade, and the confidence to recognize that you can do these types of things, because you have done them, and because you're smart and resourceful.
This sort of confidence in one's abilities is such an asset when interviewing. Just assess your skills, know what you can do, and talk like you know what you can do. Sure you don't know everything about these skills, but who does?
The thing about CS fundamentals and interviews focusing on them is just a lame facet of the industry. It's hard to assess complicated skills in a standardized way, so instead people ask about data structures and language syntax. It's like interviewing an architect by asking him minutia about specialty hammers, but it's just the way it is. Look at it as a flavor of FizzBuzz, read through some books on the topic. If you're asked such a question, try to get behind the question, see what the interviewer is really assessing, and speak to that out of your skill toolbox.
If you want some CS theory book recommendations, here are my favorites:
- "Cracking the Coding Interview" by Gayle Laakmann
- "The Algorithm Design Manual" by Steven Skiena
If you get stumped by a question, look it up when you get home.
