If you're looking for a job with specific qualities (uses X language, is in Y market, etc) then you need to expand your (people) network in those areas. Join as many groups related to those things as you can. Join meetups, mailing lists, G+ groups, find IRC channels, etc. The original poster was right to talk about networks, but it's not just about who you have worked with before, it's anyone you have interacted with on a sustained basis, and those groups are often just as good as working with people, sometimes better, because generally anyone can join those groups. Also, they're great learning resources.
It's in these groups that jobs are often posted before they're posted publicly. And if you've been an active and quality participant in the group, your response to the posting will be looked on favorably. You'll have a foot in the door without even trying. That being said, make sure you are always polite when talking on these groups, as it reflects badly on you if you are condescending, argumentative, or otherwise unpleasant.
When writing up your resume/CV, be 100% honest. Never fudge the truth. Most employers realize that not everyone can know everything. Briefly list the major technologies used at each job, and list a few prominent accomplishments (e.g. "rewrote client-server sync framework, decreasing server load by a factor of 10"). Keep your resume to one page if you have less than 5 years experience, 2 pages for anything over 5. Don't bother with anything other than company name & technologies used for jobs more than 10 years ago. Don't over clutter your resume with skills. Pick your top few. If you start having to write stuff like "XML" as a skill, you know you've gone too far. It's ok if you just have a couple... everyone has to start somewhere.
Never be afraid to say "I don't know" in an interview. If you don't know, say so. No one expects you to know everything, and it's far more valuable for an employer to know that you'll be up front about what you don't know, than to think you'll try to bullshit your way through any question. I guarantee you, they'll know when you're doing it.
Try to work through whatever problems you're given, whether they're brainteasers or coding problems or what "would you do if" questions. Always always talk out loud when doing these problems. It lets the interviewer understand your thinking behind what you're writing. That way, even if you're wrong, the interviewer may see your misunderstanding and help correct it. Most of the time, they're not looking for the right answer, they're looking to see how you work through a problem.
If you're doing coding problems on a whiteboard, always use the language you are most familiar with. It's hard enough coding on a white board without also trying to use some language you've only used in passing. Also, always walk through your code after it's been written to make sure it does what you expect. The interviewer will like that you're double checking your work, and it'll help catch and dumb errors. Think of it as running the code through a compiler and/or tests.
Ask intelligent questions about the problem before you address it... what assumptions are you making? Is it only ASCII or is Unicode accepted? Are we talking 32 bit ints or 64? Does this need to be thread safe? Questions like this, before even writing a single character on the board will show that you are a thoughtful coder that doesn't just blast out the first code that comes into your head.
Finally... dress nicely. You probably don't need a suit. If you're junior, I'd go with slacks, a button down shirt, and a tie. If you're mid level (7+ years), drop the tie. If you're senior (15+ years)... just make sure you dressed in clean clothing :)
Always offer to shake hands when you meet someone and when they leave. Look them in the eye and say "Thank you". Be nice. Smile freely.
> Never be afraid to say "I don't know" in an interview. If you don't know, say so. No one expects you to know everything, and it's far more valuable for an employer to know that you'll be up front about what you don't know, than to think you'll try to bullshit your way through any question. I guarantee you, they'll know when you're doing it.
One thing I'd expand on here.
Don't just say "I don't know" and then stand there staring at me. It's amazing how often this happens, and I don't know if it's because people read this advice or what.
The proper way to do this is "I'm not positive about this but here's how I'd approach it". Then start working through what you can and be very verbal about what you're doing. Tell me exactly what you're thinking and why you're doing things.
The goal of an interview, at least at a good company, should be focused on seeing how you think, not what you have memorized. If you just say "I don't know" and nothing else then all I can grade you on is that you didn't know anything. If you explain your thought process, not only does that give me more to grade you on, but it also allows me to guide you. There have been lots of times where a candidate has been stuck but as he walked me through what he was thinking I was able to give him a little nudge toward the right answer. I consider that to be a good sign in a candidate.
Sometimes if they're asking you specific definitions of things, it might be all you can say. "What is polymorphism?" If you don't know... you have to just say so. But if they ask something less cut and dry, then definitely follow the advice above.
Noticed my dress suggestions ignore half the population.... Sorry ladies, I have no idea what you should wear. Luckily, neither will your interviewer :) Whatever is analogous to the above is fine, I'm sure.
I agree with most of what you say, though I'd like to nitpick because... because I'm on the internet and that's what my internet manual says I should do.
I understand the concern over appearing "condescending, argumentative, or otherwise unpleasant" but sometimes you need to do that. In fact, if I were hiring I'd find such characteristics totally appropriate and valuable, to a certain degree.
I say, sure, be polite but when you are taken to that limit, feel free to condescend, get argumentative and express yourself.
Haha this reminds me of an old Microsoft interview technique I read about a while back (2 years ago?). I don't think they do it anymore because, well, it's a little odd.
Basically the candidate would state something that was pretty obvious at some point in the interview and then the interviewer would say that he was wrong. The idea here was obviously to see whether the candidate had "the balls" to confront someone who basically has more authority here and tell him that he, in fact, was the one who was incorrect. From what I remember the reasoning was that in real life, you're often in a position where you have to convince someone higher up than you that they're incorrect and here is why.
I just tried googling for the story for a few minutes but couldn't find it :(
Personally, I always aim to be polite and I don't understand the reason why people believe that "argumentative" is necessarily a bad trait. Sure, it's bad if you argue for everyone and everything but doesn't this mean that you need to do it in moderation?
I think part of the reason why being argumentative has a negative vibe in the general public is because people don't really argue - they just bring their point of view and try to shove it down your throat until you swallow it and agree or choke on it. The mere thought of considering new suggestions is for many people scary.
Argumentative generally means arguing without and real reason to do so. Obviously, yes, you should stand behind your position, preferably with facts to back you up. But that doesn't mean you have to go out of your way to start an argument, or be rude while doing so.
There's a big difference between a disagreement and an argument.
This is a crucial distinction. Disagreeing with someone is valuable. Being argumentative isn't about accuracy, it's about ego and self-assertion. If the person you're talking to can't be persuaded, the solution is to call on sources (or if they aren't available, as in an interview, table the topic until they are.)
It's in these groups that jobs are often posted before they're posted publicly. And if you've been an active and quality participant in the group, your response to the posting will be looked on favorably. You'll have a foot in the door without even trying. That being said, make sure you are always polite when talking on these groups, as it reflects badly on you if you are condescending, argumentative, or otherwise unpleasant.
When writing up your resume/CV, be 100% honest. Never fudge the truth. Most employers realize that not everyone can know everything. Briefly list the major technologies used at each job, and list a few prominent accomplishments (e.g. "rewrote client-server sync framework, decreasing server load by a factor of 10"). Keep your resume to one page if you have less than 5 years experience, 2 pages for anything over 5. Don't bother with anything other than company name & technologies used for jobs more than 10 years ago. Don't over clutter your resume with skills. Pick your top few. If you start having to write stuff like "XML" as a skill, you know you've gone too far. It's ok if you just have a couple... everyone has to start somewhere.
Never be afraid to say "I don't know" in an interview. If you don't know, say so. No one expects you to know everything, and it's far more valuable for an employer to know that you'll be up front about what you don't know, than to think you'll try to bullshit your way through any question. I guarantee you, they'll know when you're doing it.
Try to work through whatever problems you're given, whether they're brainteasers or coding problems or what "would you do if" questions. Always always talk out loud when doing these problems. It lets the interviewer understand your thinking behind what you're writing. That way, even if you're wrong, the interviewer may see your misunderstanding and help correct it. Most of the time, they're not looking for the right answer, they're looking to see how you work through a problem.
If you're doing coding problems on a whiteboard, always use the language you are most familiar with. It's hard enough coding on a white board without also trying to use some language you've only used in passing. Also, always walk through your code after it's been written to make sure it does what you expect. The interviewer will like that you're double checking your work, and it'll help catch and dumb errors. Think of it as running the code through a compiler and/or tests.
Ask intelligent questions about the problem before you address it... what assumptions are you making? Is it only ASCII or is Unicode accepted? Are we talking 32 bit ints or 64? Does this need to be thread safe? Questions like this, before even writing a single character on the board will show that you are a thoughtful coder that doesn't just blast out the first code that comes into your head.
Finally... dress nicely. You probably don't need a suit. If you're junior, I'd go with slacks, a button down shirt, and a tie. If you're mid level (7+ years), drop the tie. If you're senior (15+ years)... just make sure you dressed in clean clothing :)
Always offer to shake hands when you meet someone and when they leave. Look them in the eye and say "Thank you". Be nice. Smile freely.