21–30 of 30 posts
There's a good talk on the subject from PyCon (https://www.youtube.com/watch?v=1i8ylq4j_EY).
My suggestion to you: get interviews in places where you don't want to work, or for jobs that you don't want to do. (of course you must keep at last in the field of interest) This will ease your rejection fear, and train you to handle it.
That is a great idea, it will also help me learn you to say 'no' if an offer is extended.
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.
One thing to be aware of is imposter syndrome ( http://en.wikipedia.org/wiki/Impostor_syndrome ). From your description, it sounds like you may be selling yourself short. I don't know about the prevalence in CS, but this seems to actually be pretty common in academia. There's a good talk on the subject from PyCon ( https://www.youtube.com/watch?v=1i8ylq4j_EY ).
Definitely going to check out that PyCon talk.
Earlier quoted context omitted.
Everybody is afraid of interviewing. 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 ex…
Maybe not. It hasn't worked that way for me. Also: no correlation between how strong I feel in the problem domain and how well I'll interview for it. And I'm just fine getting up in front of a room full of clients and selling consulting services, or getting in the face of a lead developer and telling them what they're doing wrong. It's something about the "set and setting" of a job interview. I'm unsurprised if there…
Agreed. What is your approach to finding good people given this phenomenon?
One thing to be aware of is imposter syndrome ( http://en.wikipedia.org/wiki/Impostor_syndrome ). From your description, it sounds like you may be selling yourself short. I don't know about the prevalence in CS, but this seems to actually be pretty common in academia. There's a good talk on the subject from PyCon ( https://www.youtube.com/watch?v=1i8ylq4j_EY ).
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
Earlier quoted context omitted.
Maybe not. It hasn't worked that way for me. Also: no correlation between how strong I feel in the problem domain and how well I'll interview for it. And I'm just fine getting up in front of a room full of clients and selling consulting services, or getting in the face of a lead developer and telling them what they're doing wrong. It's something about the "set and setting" of a job interview. I'm unsurprised if there…
there is zero correlation between how people comport themselves in job interviews and their ability to do a job. Agreed. What is your approach to finding good people given this phenomenon?
[1]: I'm phrasing it in this way not because I don't agree with him, but because it's new enough that I don't think it's been established as objective truth. I'm of the opinion that the pipelines are very cool and fairly effective as recruiting tools.
Earlier quoted context omitted.
there is zero correlation between how people comport themselves in job interviews and their ability to do a job. Agreed. What is your approach to finding good people given this phenomenon?
tptacek's approach to finding good people is fairly well documented, as it happens. I'm sure he can jump in and summarize it better than I can, but in brief: his company has several pipelines which generate quality candidates for the type of work his company performs (he is a co-founder of an application security consulting firm; the pipelines are a series of crypto challenges that are designed to teach you how to im…
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.