Resume
1. Don't have a resume longer than two pages
Even if you have done something as cool as writing the software that makes the Kinect work, moved Facebook operate on OpenStack, wrote part of EC2, or improved search times on Google by 1000%, I don't need to know every step that you took along the way. Give a brief two or three line synopsis of the project with some of the main technologies you used and let me ask questions about it.
How to lose double points: Explaining that you used the basics of an API or Framework. For example: I used List<> in C# to create a collection, or used GET statuses/show/:id in the twitter API to get the single status by Id.
2. Don't have anything on you resume you aren't willing to talk about
Anything on your resume is fair game. When you say I don't want to talk about that, or I don't remember much about that project, and it happened within the last couple of years I am going to immediately come to two conclusions:
- You are probably lying about working with the technology on that project and just put it on there to try and impress me.
- You are desperate for work and put just about any buzzword on your resume that you could come up with to try and get your foot in the door
3. Don't Copy and Paste
Resumes are fairly tedious to read as it is. When you copy and paste the same line into multiple jobs it screams "I'm trying to fluff up my resume and make myself look way more awesome than I probably am"
In the Technical Screen
1. Don't try and make up an answer
If I ask you a question, chances are I know the answer, and I probably know it very well. That means if it sounds like you are starting to make something up I will ask a follow up. If I'm feeling generous I will let you go just far enough to know that you have no clue what you are talking about before moving to a different subject.
No one knows everything. Some questions that I ask are asked simply to see if a person will willingly say "I don't know the answer to that question", and will either:
- Ask more about it.
- Write down the question with the intent of looking it up later.
2. Answer the question that I am asking
If you are unclear what I am asking, ask for clarification. Don't try and and change the answer towards something you know. I asked the question about a specific technology for a reason. \
3. "Like", "so" and "um" should be avoided at all costs
If you use these words so often that an interviewer can't concentrate on what the rest of your answer is, chances are you are not going to get called back.
4. Don't argue with me.
You will disagree with an interviewer from time to time, and if you decide that you won't be able to work with that person because of a philosophical difference, then by all means don't take the job. I may love Python you may love Ruby. If you want the job don't tell my Python sucks.
Questions to ask Interviewer
1. Don't ask me when you can start
You come off as arrogant, not self assured.
2. Don't ask if there is any reason you wont get this job
That question alone in an interview is the reason why you won't get the job. It makes me uncomfortable and quite frankly there is always a reason to not give a person that job.
3. Don't have no questions
It shows me you've done no research, and that you haven't gleaned any information about the way the company works from our conversation. It shows a lack of interest in the position.
Things you should know
- Know what Object Oriented Programming
is.
- Learn Design Patterns
. Be able to explain at least one in detail and it better not be a damn singleton.
- Make sure you know at least one scripting language/Dynamic Language (Perl
, Python
, Lisp
, Ruby
, JavaScript
, PowerShell
)
- Make sure you know at least one statically typed language (C++
, C#
, Java
, Objective-C
)
- Be able to speak about an interesting problem you solved in detail
No comments:
Post a Comment