Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: How do you apply for a tech job?
118 points by quietthrow on July 18, 2013 | hide | past | favorite | 82 comments
I am interested in learning what are the best practices when it comes to applying for a job. The goal is for this post to serve as a collection of ideas that members of this community (including me) can use. If possible break down your answer into the high level steps that cover your entire process - from search to acceptance or rejecting of a offer. Thanks for participating.

EDIT: Also indicate how you find jobs/listing in the first place. Would like to hear form people who have a big network and people who don't. This will help people who don't have networks tremendously.




Other people are giving good comprehensive advice, so I'll just drop in 2 small points.

1. On any interview question, and especially on coding questions, don't be afraid to take some time to gather your thoughts. You will feel like you're under the microscope and you're obligated to say something. This is normal. Tamp down that feeling. A composed reply is better than a reply that came two seconds earlier. If necessary, practicing using canned phrases as a stalling technique--just saying "Excellent question! So, you see..." buys you like two not-awkward seconds.

2. In any coding exercise, spend more time talking than coding. You will have a large instinct school that your imperative is to find the correct answer. You must fight this. Your goal is to demonstrate that you can reason clearly, even if you arrive at a different answer than your interviewer. Before starting, explain your high-level approach. Be explicit about any assumptions you're making. Any time you make a decision, no matter how trivial, state that it is a decision and preferably why you did not choose alternatives.

3. There will always be a part of the interview where the interviewer asks if you have questions. Ask a question. It doesn't need to be anything special, just have a few on-hand. My favorite is to ask what the company culture is like, since that's something the interviewer usually doesn't cover.


Always ask intelligent questions! It is worth it to explore the company in the news/on LinkedIn/etc in advance, to be able to ask smart questions.

Here are some generic questions you can always ask:

- What technology stack/environments do you use?

- Do you use any methodologies, like Agile?

- Do you do any code reviews, mentoring, training, lunch & learns, etc?

- How flat or deep is the organization? What is the org chart/hierarchy like?

- Who would I report to? Would I be part of a team? How big?

- Would I be mostly working on internal projects, or customer-facing? New, or maintenance?

- Will I have lots of freedom to choose projects or do we mostly work from the backlog?

The general theme here is to act like you already have the job and are going through orientation so that you can be the best employee ever. This shows that you ar einvested, interested, and proactive.


Seconded on number 3. Interviewers feel that you are more engaged and interested in the opportunity at hand if you're asking questions.

Having a few 'set' ones, like ?culture, in your back pocket is good in case you get flummoxed on the spot, but you'll probably get a pretty generic answer from 'tell me about your company culture'.

Use your question time to really probe about something important to you. If culture is it, follow a general ask with something specific: "You mentioned that you're a team that likes to 'work smart'. I think that is awesome, as I feel like it's a mindset that tends to be undervalued. Can you tell me more about how you see this play out in practice?"


Forget the back pocket: get a notebook, write some questions down and have it open on the table in front of you. Keep a copy of your CV there too, for the inevitable occasion when your interviewer is looking at something that's been mangled by an agency and you want to show them what it's supposed to look like.


#3 usually comes up on most "how to interview" guides as something you need to do, and so I used to ask a question just for the sake of it. I figured out late into my career why this is so important and why I always liked candidates who had a ton of questions for me:

Top performers usually have many career options and are very picky about the company they're going to join. Asking questions about the company shows that (a) you have other options and are "interviewing" the company for fit and also that (b) you care where you work. These are both very good indicators of a great employee.


I'm stumped when 5 interviewers in a row ask that question, and at a company like Google. Given that I have enough friends there that I have some sense of what the culture is like a priori. Asking the same question or variant thereof is painful :(


Ask a question about the interviewer's workday! A few years back I asked a stakeholder in a one-on-one interview to describe some of the issues he was hoping I could help with. Soon enough we wound up in his office going over his existing systems while I extemporized some solutions. Got the job, too.


"Excellent question!" to any experienced interviewer means, "I have no clue, but I won't admit it!" I immediately dislike any candidate who does it, and vastly prefer the two seconds of silence. If silence is intolerable, "Hmm" is better and pretty natural for engineers.

Further good points: https://news.ycombinator.com/item?id=6063790


> "Excellent question!" to any experienced interviewer means...

That's an very broad statement.

This phrase can come across as gratuitous or stalling, but it really depends on how you phrase it, the enthusiasm you project, and whether you use it sparingly and appropriately.


Another note on #3 - if you want the interview to remain positive, asking the interviewer what they like about working there and why they joined the company will pretty much guarantee that things will take a positive turn (unless the person shows signs of regretting their decision). It should also provide some insight into environment, as most in tech have that as a high priority and will immediately talk about their environment if it is positive.


I've had good luck bonding with interviewers over this approach. Questions like "So what brought you to company X?" and "What do you do in a typical day, what do you like most about that?" create a personal connection to the interviewer, and offer a chance for them to share something more personal than empty generalities about the company.

As a bonus, if they can't tell you anything they enjoy about their job you get an early heads up that you might want to run screaming from the place.


I have heard that if you can get the interviewer to talk about themself for most of the interview, they will remember the interview going great, because everyone loves talking about themselves. I have not managed this myself though. ;)


That is pretty accurate. Most interviewers won't spend too much time talking about themselves, but asking a question that gives them the opportunity to do so gives you an advantage over interviewees that do not.


'spend more time talking than coding' - I always tell people who I interview to do that before starting to bang out code. I am testing for 'problem solving ability' not raw coding skills.


I typically am more direct re: 1) and it's worked well so far: "Let me give that a bit of thought."

Yes, it's followed by silence - but the only person who will be uncomfortable with that is you, if you let yourself be. Personally I'm using that silence to actually think about the question, so there's no discomfort or awkwardness.


For me finding interesting companies is the hardest part. IMO you can rank companies in two dimensions: 1) companies that I'm enthusiastic about and would love to work for 2) companies that will employ me.

The trick is to find companies that are in both categories.

But the groups are fluid. You can gain more experience and therefore extend 2), or you can learn more about a company and therefore add it to 1). Or you can reduce expectations and have every single workplace in group 1).

When I look for a job I usually focus on individuals. Read an interesting blog post? I research on the author. Nice node.js library? Learn who wrote it. Amazing project? Who pays for its development and why.

This is a lifetime project, but yes, do follow individuals you admire.

If possible don't apply to jobs@..., instead send an email to a real human being. If a company has a blog, find an interesting author and contact him directly. You'll usually be told to send CV to jobs@ anyway, but it's always better (IMO) to have a friendly human-being advocate in your case.

Research github projects done by the company or employees. Try to contribute, it will not only give you an experience and a good topic for a discussion, but also can also show reveal communication patterns in the company.

Before going for an interview, try learning as much as possible about the company. From all sides: how many data centres, what AS'es, who is listed in whois entries, who is the biggest competitor, who are the investors, who are the customers, and so on. For me there are four groups of things worth researching: individuals, communication patterns and politics, technology stack, business (ie: money).


This question can lead to quite a long list of answers. I've posted several of my blog posts about job search here on HN over the past couple years (http://jobtipsforgeeks.com), and I write extensively about job search and career tips specifically for programmers and tech pros. I've been recruiting engineers for mostly startup and small software firms for 15 years, and I've run a Java User Group since 2000. During my career I've worked with thousands of job seekers and hundreds of companies, so I've managed countless job searches for engineers.

I recently released an ebook 'Job Tips For GEEKS: The Job Search', which is a step-by-step guide to most of the things you are asking about. It starts with the decision to start a job search, what strategies to consider and pros/cons of each (recruiters, posting resumes, emailing to online posts, and more random approaches, etc.) , implementing those strategies, how to protect yourself from recruiters, resume structure section by section, interview tips for phone and face-to-face, keeping metrics during the search (to track success/failure), talking about money, negotiations, balancing multiple job offers, refusing offers, accepting offers, counteroffers (including what recruiters are trained to tell you), and how to keep bridges intact after the job search.

It covers everything during the process in about 150 pages. I made a quick one page with links to buy and a link to a free section - http://jobtipsforgeeksbook.com.


- Be honest about your experience, and tell them what you are really comfortable with. If you got 3 months experience in Objective-C, don't say 1 year, and tell them what parts/concepts of Objective-C you have used. Don't get too hung up if your skills aren't what they're looking for. Good employers know that someone with a strong technical background can learn anything given enough time.

- If they are giving you a puzzle, try your best to solve it. Do not be too worried if you can't solve it. Most of them will give you hints. I have been offered jobs when I couldn't solve their puzzles.

- If they're asking about opinionated questions (OSX/Linux/Windows, Git/Hg, Java/C, iOS/Android, etc), they are probably just testing your reasoning. It doesn't matter what you answer as long as you have your reasoning. Telling them you use Hg because your boss told you so is not good. It's always good to have a good lookout on new technologies.

- Go to meetups and talk to people. You will probably find a lot of jobs there. Be open, tell them you are looking for a job.

- Wear a t shirt and jeans. Drink lots of water and maybe a cup of coffee.


I do almost all of that stuff (except going to meetups because...) but location matters the most. I live in a small town in India, and I would like to work, but we don't have the kind of job I would like to do here. No one writes good software, there is no startup culture. People here need someone to maintain old java code or write some mundane portfolio website. I need a startup or a proper tech company with products, market, that has exciting cool stuff to work on, I would be more of an intern, but location is I believe the most important factor. I even got a couple of emails back but they declined because they were not supporting visas. But's that's alright, I am not too keen on leaving the country either.


Either it makes sense to have the kind of company you speak of in your area or it doesn't. If it does, start one and you have found yourself a nice niche.


Ashok, is that you?


I am not actually. I guess there are many people in situation like me. haha


join thoughtworks. you will find what you need!


"wear a t shirt and jeans"

I was always told "dress one level above the job you're applying for". Is that different in the tech world or the startup world?


I don't know, I think it's different if you are applying for a job in a big corporation or for a smaller firm/startup. Bigger firms will usually have a more strict dress code (the place where I currently work short pants are frowned upon, except in case of system integrators)

In both cases I usually go for jeans/shirt combo (but not a t-shirt, bigger firms/older people find it unprofessional in my experience), but that's just me.


When people say "dress one level above the job you're applying for", I can't help to imagine what the levels are. I came up with something like this, from high to low:

- 3 piece suit

- 2 piece suit with tie

- 2 piece suit, no tie

- suit pants and dress shirt

- khaki's and dress shirt

- jeans and dress shirt

- jeans and t-shirt

- shorts and t-shirt

- stained shorts and wife beater shirt

I always wonder where the bow tie fits in though, or are they just always inappropriate?


Bow ties are generally considered formal evening wear, not business attire, much like tuxedos.

I'd also actually put the 2 piece suit with tie over a 3 piece suit (with or without tie) in terms of formality/business-attire-ness: 3 piece suits are also not traditional business wear, while 2 piece suit+tie is the IBM/'50s iconic business look, and what you'd see most CEOs/etc. wearing.


http://homepages.inf.ed.ac.uk/wadler/Pics/philtiebig.jpg


I think they mean one level above you in the hierarchy. What are the managers in the company wearing?


I think he meant in general, not at the interview (though more senior people can get away with it in the interview too).


I've been in the work force 12 years and had 4 jobs. My first job was my University Co-op that turned into full time employment after I graduated. When I want to change jobs I put the word out to my friends and ex-coworkers that I'm looking. Usually somebody will come up with something fairly quickly. I may or may not have to send a resume. The interview will be a formality. I've never just applied for jobs that are posted, that's what some of my friends are doing now and it seems very difficult, especially if you don't interview well.

I didn't even do anything particular to build my network. I just worked at a company with fairly high turnover for 4 years, so now I have ex-coworkers at pretty much every company in town.

I live in a fairly small city, 350,000 people. So it's pretty easy to get known in the tech industry without knowing that many people.


- On your resume, don't list what you did, list what you accomplished. For example, wrong = "Wrote new SQL and bug-fixed existing SQL on web application". Right = "Reduced a long running SQL call from 8 hours to 20 minutes" - Also try to avoid "fuzzy" statements on your resume. Make your accomplishments quantifiable. Wrong = "Rewrote a VB program so that it was a lot faster". Right = "Rewrote a VB program, reducing average run time from 60 minutes to 15 minutes" - Be prepared to defend any statement on your resume. If you made that program faster, be prepared to explain how and why - Apply for some jobs you don't really want before you apply for the ones you DO want. This is because interviewing is an art, and it really helps to "get in the mode" first. If you going to bomb the first few interviews, make them ones you don't care about so much. - Turn off your cell phone. Better yet, leave it in the car. - Have a personality. Hiring is still mostly about who "fits" the job. If they like you, half the battle is over. At the same time, don't be "chummy" with the interviewer. If you act like you two are best friends and should go out for a beer together, it feels kiss-assy and rarely if ever bodes well for you. - Prepare to answer common questions. Why do want to work here? Why should we hire you? What are you most proud of? What is your weakness? What was a time you had a conflict at work? Almost everyone asks these, and and sucks to answer with some dumb example. - Always try to rephrase the question asked to you before answering it. e.g. "Tell us about your SQL experience" - you reply, "So you want to know what kind of SQL projects I've worked on?" This makes sure you understand what was asked, and it also gives you a moment to think. - If you don't know, say you don't know - Have examples of your work. Code snippets are great, screenshots of UI's you've worked on, etc. When I bomb their pop-quiz (and I always bomb their pop-quiz, I suck at testing) it really helps to tell them that you can show them code from your daily job that better represents you on a daily basis. - Never talk badly about other jobs, even if they were awful. Try to have a reason for switching jobs (e.g. They were a great place to work, but there was really no chance for job advancement) as opposed to "That was a soul sucking job and they can kiss my ass" - Understand that most people performing tech interviews have ZERO training in doing so. If they aren't asking you questions that put you in your best light, then help them out, and offer up that information.


I agree on the advice on applying for jobs you don't want first. If you're like a lot of people, you're nervous during interviews and practice makes perfect. Maybe you'll encounter questions you didn't expect or have a great answer for. Maybe you find out that people really do quiz you on all the textbook CS stuff you learned in college and subsequently forgot.

If you get a job offer out of it, that will build confidence for when you apply for the job you want.


Please only do this if you're fresh out of college (or otherwise new to interviewing for tech jobs). Interviewing candidates is hard enough on companies without spending time on people who don't even want the job.


I don't know. Often I'm not sure if I want the job or not whem I apply, so I see interviews as an opportunity to learn more about the company. Many companies are very different in what they ask for in a listing and what they're actually like. It goes both ways.


I understand your concern, but I agree with the advice whether just out of college or not. Interviewing is a skill just like any other, and if it has been more than a year since the last one, chances are you'll be rusty.

If a candidate is in the interview, there must be a modicum of interest, and is a great chance for the employer to sell it's position. And of course, as an interviewee, it is mutually beneficial to avoid wasting both parties time by expressing disinterest as soon as possible.


I'm organizing these because they're great but hard to read, and it's easier to do that than to complain and demand you edit them.

- On your resume, don't list what you did, list what you accomplished.

For example, wrong = "Wrote new SQL and bug-fixed existing SQL on web application". Right = "Reduced a long running SQL call from 8 hours to 20 minutes"

- Also try to avoid "fuzzy" statements on your resume. Make your accomplishments quantifiable.

Wrong = "Rewrote a VB program so that it was a lot faster". Right = "Rewrote a VB program, reducing average run time from 60 minutes to 15 minutes"

- Be prepared to defend any statement on your resume. If you made that program faster, be prepared to explain how and why

- Apply for some jobs you don't really want before you apply for the ones you DO want. This is because interviewing is an art, and it really helps to "get in the mode" first. If you going to bomb the first few interviews, make them ones you don't care about so much.

- Turn off your cell phone. Better yet, leave it in the car.

- Have a personality. Hiring is still mostly about who "fits" the job. If they like you, half the battle is over. At the same time, don't be "chummy" with the interviewer. If you act like you two are best friends and should go out for a beer together, it feels kiss-assy and rarely if ever bodes well for you.

- Prepare to answer common questions. Why do want to work here? Why should we hire you? What are you most proud of? What is your weakness? What was a time you had a conflict at work? Almost everyone asks these, and and sucks to answer with some dumb example.

- Always try to rephrase the question asked to you before answering it. e.g. "Tell us about your SQL experience" - you reply, "So you want to know what kind of SQL projects I've worked on?" This makes sure you understand what was asked, and it also gives you a moment to think.

- If you don't know, say you don't know

- Have examples of your work. Code snippets are great, screenshots of UI's you've worked on, etc. When I bomb their pop-quiz (and I always bomb their pop-quiz, I suck at testing) it really helps to tell them that you can show them code from your daily job that better represents you on a daily basis.

- Never talk badly about other jobs, even if they were awful. Try to have a reason for switching jobs (e.g. They were a great place to work, but there was really no chance for job advancement) as opposed to "That was a soul sucking job and they can kiss my ass"

- Understand that most people performing tech interviews have ZERO training in doing so. If they aren't asking you questions that put you in your best light, then help them out, and offer up that information.


Another good sign is to talk about how you took initiative to help solve problems at a company. Stepped up. Instead of complaining, like you did.


The classical browse job offers, send resume, get an invitation to an interview, get the job does not work anymore. Optimizing for the best cover letter, great resume, or tricky interview questions is a cargo cult. The only reason to optimize here, is if you want to become a priest of this cargo cult, e.g. a recruiter, vocational guidance or other professions who exploit the unemployed.

I assume that "tech job" means something in IT tech like coder, designer, admin, and not something like an engineer or chemist.

I got all my projects over the last 35 years by listening to others peoples problems. Real programmers are cursed by infinite ideas vs. limited time. So ideas get a negative value. Just pick those ideas where the company has a great culture, and that sound challenging to you. So the positive work environment must balance the negative value of the idea. Ask yourself: The is company work environment good for solving the problem, or a hindrance. Do !NOT! talk to HR, but to the people who have the problem. I always talked to HR last, at the moment after signing the contract when they want my tax numbers and the like.

One indicator, that might not work in other cultures (outside Germany), is: You got the job, if they take the time to show you the recreation facilities like coffee kitchen, smokers garden, after the interview.


I see really interesting and articulated responses here, so I'm wondering if anyone has tips on how to apply to jobs when you have 0 experience, like when you're straight out of college. I know most of you might be thinking "you have to build a portfolio/repository on github WHILE you're studying and then build from that" but often that's not an option. Maybe I'm particularly stupid but I don't have really time to do anything beyond studying for my courses. So I'm wondering, if you're just out of college and you don't have anything to show, plus you don't have much experience in terms of programming 'cause you just did 2-3 projects during your years as a student, what's the best course?


First option: Drive downtown and write down every business you see. I would imagine 99% of them need technology, 75% of them have some form of technology, and 50% of them are using legacy software. Call them. Something is running at O(n^5) and they need your help.

Second option: Connections. Find that person that knows someone. Use your alumni network.

Third option: If you're fresh out of college, expand out of city or state. Watching students stagnate in their hometowns is a shame.

Persistence pays off regardless of the field. 'Hi, I'm wondering if you have any computer related jobs available? No? Do you happen to know anyone applying?' Build a network out of people you're only talking to for 5 minutes!


Try working for your college. The IT department probably has work study jobs, which will give some "real world" experience but not intrude into your studies too much.


Internships are definitely your best bet. Once you get to a year of experience, the rest is gravy.


Hello guys! In brief: I am biologist on the paper, but I work basically 70% with computational biology and only 30% in the lab. Also I engineered certain php and c++ apps. Now I am looking for positions in that direction. I had some problems when they tested my skills. I often failed because I was nervous. Next week I am up to an interview again and this time they announced to test me on my php skills. I'm pretty sure that I'm not soo bad in that stuff, but last time I coded php 24/7 was almost three years ago. Since then I had to focus more on C++ and C#. I don't want to fail and just don't have enough time to repeat every single thing so have you any suggestions how to deal with that uncomfortable situation?


I have a somewhat related question: How do you best present yourself at a career fair?

I did pretty well last year by being friendly and trying to show my passion for programming. This year, I'll be attending the Reflections | Projections Conference [0], and the companies I'll hopefully be talking to are on a completely different tier. What's the best way to make a lasting, memorable impression, especially if my school isn't particularly impressive? Do I mention my prior internships or side projects? Something else?

Thanks for any advice!

[0] http://www.acm.uiuc.edu/conference/2013/


Luckily for you, the career fairs you go to in college should be your last. Once you have a job and some marketable skills, you don't want to be hanging around career fairs.

To differentiate yourself, definitely mention side projects and internships. Be sure those are on your resume - relevant links to websites, a GitHub account, or whatever else you can do to show your code. Feature them prominently on your resume, along with an internship. Keep it one page.

Also, make sure to be as personable as you can at a career fair. Chances are the people you will meet might not be engineers, but more HR and recruiting types that are basically salespeople (recruiter here) who tend to be smooth talkers. You'll want to make sure you provide firm handshakes and eye contact to avoid some of the engineering stereotypes.

Good luck


well the recent security themed fair that was held in Victoria was for those interested in security and not just recent grads.

PS the geekiest attendee was one of the young guys on the GCHQ stand :-)


There are exceptions. Here in the US, most career fairs consist primarily of larger and older companies with booths, and the attendees tend to be people who have been unemployed or unhappy for extended periods of time. If you find yourself going to career fairs a lot, it probably means you should start making better career decisions to stay marketable.


Whatever you do, do not under any circumstances go through the company’s HR department to get a job. I work in one of the best tech companies in the industry, and our HR people frequently reject highly qualified candidates we’d like to talk to before we even see their resumes. We know this because these same people often know people on our team, or on our friends teams, and we get their resumes through back channels. We almost always hire these people instead of whoever HR sends us.

As an example, about a decade ago, I saw an opening for someone with vector processing experience. I applied and highlighted my extensive experience with AltiVec processors in Macs. The recruiter actually sent me back an email asking why I had included all this irrelevant AltiVec stuff. It turned out he had no idea what vector processing was and didn’t realize I had exactly the experience he was looking for.

Later, when they had an even better opening, I just emailed a guy on the team that I had met once or twice and he was very happy to pass my resume on to the hiring manager because he knew I had the experience needed from being on some mailing lists with me. I got the job and have been at it for 8 years. My boss’s boss at the time said it was one of the best hires they’d ever made.


I'm in the "no experience" boat. I recently decided to switch jobs; jumping from sales to a aspiring programmer. I'm dedicating the next 6 months (full time) to learning Ruby/Rails and becoming comfortable with HTML/CSS/Javascript.

A few things I'm doing to get prepared: 1) I'm enrolled in a online Ruby/Rails bootcamp (https://www.gotealeaf.com) it lasts for a total of 16 weeks and we're building out several projects. 2) Taking lessons at Treehouse, I'm always up for some extra practice! 3) Just started a side project that I will have completed by the end of the 6 months. 4) Attending a weekly local Ruby meet up. Additionally, I'm getting involved in other local tech events, like Startup Weekend.

My plan of action is to make a trip to San Francisco (this is where I ideally want to relocate to) to speak to a few potential employers mid-way of my journey. Of course, it won't be a formal interview but I would like to let them know my plans and a get feel of their company, culture, etc. At the end of the 6 months, I will touch base with these companies and show them my progress. At that time, I will also reach out to additional companies.

What do you guys think of my overall strategy? Any suggestions?

In terms of my resume, what type of things should I list? Since, I won't have any "formal" experience, is completing the online Ruby/Rails bootcamp worth highlighting? How about my side project?

PS: I'm a female in my mid 20's coming from a luxury sales and customer service background.

Thanks in advance!


You should definitely focus on solid side projects. You don't have any prior experience as a developer so the only way to prove to someone that you can code is to show them.


Since she doesn't have a job in the industry, are they still called 'side projects'? I agree with the sentiment though, that she should focus on building a portfolio of code that she can use as evidence that she knows what she is doing.


Here are a few of the things I would recommend in no particular order. Most of them are pretty traditional.

1. Wear leather shoes. You could dress in rags, but if you are wearing leather shoes, it will make it look like you meant to. Scott Hanselman pointed this out on his This Developer's Life podcast a while back.

2. Show your github or linkedin profiles, but despite people saying "oh, this is my resume", no it is not. Quit being cute and spend 20 minutes typing up a real resume. Use one of the templates provided in most word processors. Your resume is not meant to stand out. It is meant to be used as a filter to see if there are any red flags. Think of it like just another piece of paperwork. Include your last 3 jobs (not 1 and definitely not 10), degrees, and a list of technologies you know. Do not include smarmy HR stuff like "Team Player! Great Work Ethic!" Make the resume custom taylored to fit the position you are applying for. Since you are not including everything you have ever done, just focus on the experience you have that is most relevant. Lastly, keep it to one page, with a normal font size.

3. Dress to the company +1. If they wear cargo shorts and t shirts, wear shorts with a polo. If they wear jeans and polos, wear jeans with a button down. If they wear kahkis and button downs, wear that plus a tie. If they wear suits... you probably do not want to work there so I would recommend wearing a tuxedo or nothing at all.

4. Always remember that you are interviewing them. Take charge of the interview. Ask about the culture and values. Ask the interviewer how they personally feel about X and Y aspects of the business. Ask about stability and/or revenue. If it seems appropriate (feel it out), ask where the person who's position you are filling is now and why they left. If there are red flags hiding, this is the question that will often reveal them.

6. As far as finding companies goes, pick a list of 10 you like, then email all of them. If they have a position listed, then mention the position, but if not, apply anyway and offer your services. Coders are in demand, and many companies will jump at the chance to interview an enthusiastic person who took some initiative. Pretty much ignore job requirements. They are so often unreliable, that you might as well find out in person. As long as you are fine with the stack, go for it.

7. Do not get tunnel vision. This is probably the most important thing. It is like buying a house. Do not fall in love with any one offer. You should never, under any circumstances, be applying for one job at a time. You always want multiple offers so that you can leverage them against each other. Also, if one falls through, it is no big deal. If you were going to apply for one job at a time, you are forced to go with jobs that are almost a sure thing. After all, if it does not work out, you could be out of work for another month or two. If you reach for something out of your comfort zone (something that is essential for growth), you might have a 20% shot of getting each individual job. You do not want this to be a 6 month process, so go for jobs in batches of 5. If you have a 20% chance at each, you will probably land one of them. I have seen many coders fall into the trap of feeling like they are being disloyal for following multiple leads at once. This is complete BS. Companies are interviewing as many people as they can, so do the same. You do not even work for them yet, so loyalty really should not factor in.


> If they wear suits... you probably do not want to work there so I would recommend wearing a tuxedo or nothing at all.

Don't know if that is just a joke, but one of the best places I ever worked people all wore suits, the systems were internal for a few high wealth people revolving around aviation.

Not pretentious, just looking as smart as you can. Same sort of logic as dressing up to go to the opera, I love to see gf in an evening dress, she likes me in black tie. I definitely look more dashing!

I should be wearing a suit now, but instead have my arm in a sling, so am in an injury friendly easy to dress casual t-shirt. No one objects (well aside my productivity drop due to one arm out of action).


There might be an interview trick in there...

Don't have a nice enough outfit? Grab a $5 cast or sling and use it to excuse your lack of suit, say it'll be off in a week.


Solid advice here. I'm going to address numbers 2, 6 and 7 with an alternative:

A really good recruiter can help with all of these things, except 'really good recruiter' seems like an oxymoron 99% of the time.

I'm a former recruiter turned tech entrepreneur, and my company, Mighty Spring (https://www.mightyspring.com) launched in private beta a few months ago to solve this problem.

We're a web app that let's you control the recruiting process. You spend <5 minutes setting up a profile, and then see a job board that is matched specifically to your background afterwards. With one click, you can indicate if you're interested in being contacted about a specific job. If you do, someone from Mighty Spring will reach out via email to schedule a call at your convenience.

We help coach you through the rest of the process with the company - including assistance with negotiation - without you ever having to formally 'apply'.

The other side of this is that we'll also create for you an anonymized pitch of your background that companies browse. Companies request to interview candidates based on these pitches. If they’re interested, they can request to interview you through the site. This means that if you're only passively looking - aka, ‘would consider the perfect opportunity if it happened to come along’ - you can field incoming requests without employers ever knowing your identity unless you choose to accept the interview request and speak with them.

All in all, it’s similar to what recruiters do today, except you manage the relationship, not the other way around.

As I mentioned, we’re in closed beta, but would be happy to expedite invites to the HN crowd. Feel free to email me with question as well (email in HN profile).


Also, even if you're not interested in our service, another tip:

Applying (in the traditional way) should be your last resort. A much better option is to try to establish an internal advocate at the company in question, and have them recommend you to the hiring manager.

This isn't has hard as it may sound. Find the profile of someone on LinkedIn (or the company website itself) who looks like they might be your peer if you got the job. Figure out their email, or simply ask them to connect on LinkedIn, and put a message in the 'include a personal note' field to the effect of:

"Hey, I saw a position at your company that I'm interested in, but I don't want to waste anyones time with an application unless I'm pretty sure it's a good fit. Do you have a minute to talk with me on the phone about your experience there?"

This works wonders, especially for those whose skill sets are in demand. Plus it works to the incentives the many employees are subject to: referral bonuses. If they recommend you (instead of you applying), they may get a nice little check.


The most critical thing to remember when it comes to applying for jobs is "either you have it or you don't". You can embellish your resume, contact 100 recruiters, and have the most well developed portfolio on the planet, but when it comes time to apply your knowledge, you have to deliver. I have seen plenty of IT professionals who look fantastic on paper, but cannot think creatively or deliver under pressure. Take time to understand the industry, constantly strive to learn new technologies, and be infinitely curious. I am nowhere near the skill level of anyone on HN, but people much wiser than I am have instilled a sense of curiosity in me, and that's the most valuable character trait anyone in this industry can have.


Steve Yegge made some excellent points about writing a resume:

http://steve-yegge.blogspot.com.au/2007/09/ten-tips-for-slig...


- Don't lie on any part of your resume. If you have any open source projects on e.g. github, put the link to your profile on your resume (that helped me a lot).

- Say don't know if you don't know something, that is a legitimate answer

- If you get a programming assignment in your interviewing process, don't overengineer. For example, if assignment asks of you to take some data out from a webpage, don't use regexes, use a html parsing library instead.

- Remember that interview is also a conversation.

- If you decide to reject an offer, don't reject it impolitely, who knows, maybe in few years they will call you again, with a better offer.


Maybe you accidently switched regexes and html parsing around. But using a regular expression to retrieve data from a webpage is not an example of over-engineering. It would be a good example of a quick-and-dirty solution. If someone used them it will probably result in a discussion about the limitations of the approach.


- if you have any closed source projects on e.g. BitBucket mention this on your resume;


Avi Flombaum gave an excellent talk on this a few months ago.

He dove into the six different types of technical interviews (cultural fit, brain teasers, whiteboard coding, cs trivia, code questions, and pairing) and how to prepare for each of them.

https://speakerdeck.com/aviflombaum/mastering-the-technical-....


If you wish to target post-round startups, it can be a little bit easier to contact a vc firm's talent team (such as: http://a16z.com/talent-services/) who, if you pass whatever conversation / interview they give you, can recommend you to good fits within their portfolio.


Preface: I have interviewed around 300-500 people in the last 10+ years, spread between Microsoft and Amazon. This applies for finding a job with one of the Industry titans (Amazon/FB/Google/MS/Twitter etc.)

1. Prepare well. The number of interview preparation sites are way too many to mention.

2. Get your basics straight. If you are applying to a programming job, assume you are going to be grilled on Data Structures/Algorithms/Coding/Design patterns/OS. 3. Practice coding without an IDE.

4. Tune your interview preparation to the industry you are trying to get hired into as well. For example, if you are an experienced guy and plan to interview with us (AWS DynamoDB), you would be hard pressed to get by without Database Architecture/Concurrency/Distributed programming related knowledge. This also levels up or down according to your experience. If you have 10 years in the database industry the expectations are going to be very different compared to a college hire.

4.1. An addendum: We do hire a lot of people from other disciplines provided they prove that they are smart / willing to learn / can code. I switched from the Windows C++/C# shop to a linux Java/Perl/C++ shop for example. Do make your competencies clear to the interviewer at the onset.

4.2 Remember that you could be a very successful person in a different field/company, but as an interviewer if I can't relate your skills for the role I am interviewing you for in some way – I can't hire you. This starts mattering more and more as roles become senior.

5. Know what you have been doing for the past few years. Prepare for questions probing your team skills/problem solving skills etc.

6. Know what you are talking about and what's on your resume very well - I can't stress this enough. I find so many folks who have a templated 'Skills' list like Java and are not able to answer basic fizz buzz questions.

7. Read up about the company culture and see what they actually value most. (again, way too many sites out there for this information). Amazon has a list of leadership skills that people look for. These might appear broad, but usually have direct effects on the interview process. 8. Find someone inside the company who will refer you instead of cold calling.

Shameless plug: If you think you are well prepared and want a referral to AWS, contact me! We are hiring!


If you are in a big city, I have found that in person events are the best option. Meetups are everywhere. In New York specifically there is the New York Startup Job Fair, NY Tech Day, New York Uncubed, and a couple others.

Two data points, I met my current startup at NY Tech Day. My previous startup was met via one of the NY Tech meetups.


How does an engineer/coder address skill gaps(before and during an interview)? e.g.- C programmer but very little C++ experience


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.


Yes, absolutely. Thanks for clarifying.

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.


Nate, there are female interviewers out there too.


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.)


[flagged]


This is interesting, we usually don't have such comments here. What happened?


I am unsure how to clarify, but I will try. I have been an embedded C developer for the past 7 years. And have gotten some interviews with Amazon, Qualcomm and other companies and the lack of C++ experience seems to be a big deal. I am full confident that I can learn it. It is just a matter of exposure.


Somebody got nothing better to do..?


seems like so.


Interesting. Is that why most engineers are guys?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: