Ask HN: How do you apply for a tech job?
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.
90 comments
[ 4.6 ms ] story [ 154 ms ] thread- 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 was always told "dress one level above the job you're applying for". Is that different in the tech world or the startup world?
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.
- 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?
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.
If you get a job offer out of it, that will build confidence for when you apply for the job you want.
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.
- 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.
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).
- 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.
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!
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 a...
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.
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.
There's a big difference between a disagreement and an argument.
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 :(
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.
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/
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
PS the geekiest attendee was one of the young guys on the GCHQ stand :-)
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.
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.
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.
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).
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.
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).
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.
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.
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?"
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.
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.
Further good points: https://news.ycombinator.com/item?id=6063790
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.
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.
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.
http://steve-yegge.blogspot.com.au/2007/09/ten-tips-for-slig...
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-....
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!
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.
Two data points, I met my current startup at NY Tech Day. My previous startup was met via one of the NY Tech meetups.
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.