How Long Do You Have to Solve Technical Questions?

Before telling you how long you have to solve technical questions, let me ask you a question. Your math teacher assigns you a problem. It takes you 5 minutes to solve it. Is that quick or slow?

Hopefully, you're looking at this question confused. 5 minutes might be unacceptably long to compute, say, the square root of 16, but extremely quick to solve a more complex proof. I didn't tell you what the question is, so how can you tell me if 5 minutes is quick or slow?

So how long do you have to solve technical questions?

As in the above situation, it totally depends on the complexity of the question. A simple factual question might take seconds. A reasonably straightforward algorithm question might take a couple minutes. But a complex algorithm could take 30 minutes or more to solve.

That said, in a technical typical interview, a candidate typically solves one or two coding / algorithm questions. That's an average though, over typical questions; be very careful about thinking, "gee, I solved three questions, I must have done great!" Solving ten questions does not mean that you've done well, if they were easy questions. Likewise, you might have done extremely well without even finishing one question.

So how do you know how well you've done?

You don't (really, really, I promise you, you don't!). Your interview performance is impossible to judge.

Okay, folks, here’s how the Google interview process really works

Somehow, many candidates have gotten the impression that the interview process is some elaborate system, and if their process is different from their friend’s, it must be a reason for it. The truth is so much more straightforward than that, and once you get, everything will make sense. Or that’s my hope, anyway.

Here’s how the process works at Google for software engineers. We’ll look at this from the interviewer’s side and from the recruiter’s side. Although this is technically just about Google and Software Engineering, the advice / structure is largely universal across tech companies.

Read the rest at technologywoman.com.

 

Officially on sale! Cracking the Coding Interview, 5th Edition

The 5th edition of the best-selling programming interview prep book, Cracking the Coding Interview: 150 Programming Interview Questions and Solutions, is officially on sale. And even better - Amazon is currently running a 20% sale on the book!

Now, I know you're used to new editions being a couple little fixes here, packaged in a shiny new edition probably for no other reason than to get you to buy your own copy rather than borrow your friend's. That is not what this is.

The fifth edition of Cracking the Coding Interview is a massive expansion of the fourth edition. It added 200 pages of content, growing the length of the book from 308 pages to 508. A more complete description of the many, many changes are below.

As before, Cracking the Coding Interview focuses on software engineering interviews. If you're looking for a start-to-end guide on how to get a job a tech company, pick up my second book, The Google Resume: How to Prepare for a Career and Land a Job at Apple, Microsoft, Google, or any Top Tech Company. The book is rated 4.5 stars after 22 reviews and can be purchased from Amazon or any Barnes and Noble store.

Massive Expansion of Introductory Chapters
The book opens with about 70 pages of content you need to know before diving into an interview question. This includes:
  • How do companies evaluate you?
  • How do you prepare for behavioral questions?
  • What happens behind the scenes at Microsoft, Amazon, Google, Yahoo, Apple and Facebook? How does the process work? Who is evaluating you?
  • How do you write a great resume?
  • How do you tackle tricky technical questions?
  • What happens when you get a question wrong?
  • What should you evaluate in an offer?
  • How do you negotiate an offer?
Expanded Chapter Intros

Each chapter opens with a discussion of core skills and technique for solving each type of question. This ranges from 3 to 10 pages, depending on the complexity of the topic. As always, we assume that you know the really basic stuff, so you don't need to wade through stuff like what a tree is.

Rewritten Solutions (+ 24 new questions) Every questions has been carefully reviewed and the vast majority have been partially or fully re-written. New solutions were added to existing problems, and 24 new questions were also added.

As before, fully compilable Java solutions (ready for import into Eclipse) can be downloaded. The download is hosted on CrackingTheCodingInterview.com.

Website / Forum (CrackingTheCodingInterview.com)
Interview problems are best with some discussion, so we've created a website / forum built around the book. If you have questions or additional solutions you'd like to consider, post them there to discuss them with other readers. The java solutions can also be downloaded from there.

Interested in Amazon Montreal? Special offer for CareerCup users

Hey Montreal folk - Interested in Amazon and looking for a way in? We've got a great offer just for CareerCup users.

Amazon is conducting a Hiring Event (mostly last Week of April, Thu Apr 28, Fri Apr 29 ) for software design engineers. The best part? No phone interviews. Interviews will be conducted in person in Montreal, with a decision typically in 2-3 days (often same day).

Take advantage of this by emailing your resume's to rh2010 <at> amazon.com. The subject line of your email should CareerCup.com Montreal.

Why You Got Rejected -- Even Though You Thought You Did Well

Ever walk out an interview thinking "I nailed that!", only to discover that you got rejected? Or, conversely, think you bombed, but then you proceed to the next round anyway? The truth is that it's incredibly hard to gauge your own performance in an interview. Usually, when you attempt this, you're looking at one of two factors: the interviewer's attitude, or how many mistakes you made.

Read on for why this doesn't work: Why Your Interview Performance is Impossible to Judge

Less Is More: How I Cut My Resume To One Page

I (very) recently wrote about Eight Reasons Why You Need a One Page Resume.  As an example of how you can cut down your resume, I wanted to provide an illustration of how you can, in fact, fit a lot of content on one page - without making your margins tiny. Here’s what I manage to fit on one page of my resume (view here):

  1. Three internships at Microsoft
  2. One internship at Apple
  3. Three years at Google
  4. One year at a start-up
  5. Founder / CEO of CareerCup
  6. Founder / Co-CEO of Seattle Anti-Freeze
  7. Author of Cracking the Coding Interview
  8. Author of The Google Resume
  9. Masters in CS from UPenn
  10. BSE in CS from UPenn
  11. Minor in Mathematics
  12. MBA from Wharton
  13. Former instructor for 1 CS course as an undergrad at UPenn
  14. Former instructor for 2 CS courses at the University of Washington
  15. Various activities: Principal at Wharton Ventures (VC Group), Yearbook Chair, Social chair of cohort, Finalist in venture capital competition

How did I fit all this on my resume?  By being very, very selective:

  • CUT: College projects.  They’re coding projects.  I’ve demonstrated that I’m highly technical by having other software engineering positions.  It just doesn’t matter any more – particularly as I’m not applying for coding jobs.
  • CUT: TA / Head TA at Penn for 4 years.  While being a TA / Head TA does show some valuable communication and other skills, I have already demonstrated that through other activities (such as being an instructor at UPenn / UW).
  • CUT: Hobbies.  It’s not that no one would care that, say, I enjoy playing squash, but a lot more people will care about almost anything else still on my resume.  Any that goes for most people - don’t waste time with your hobbies.
  • CUT: Advisor to various start-ups.  Again, it’s not that it doesn’t matter at all, but it doesn’t matter as much as other stuff.
  • REDUCED: Microsoft and Apple jobs.  Although I’ve already demonstrated technical skills through my position with Google, there is something compelling about the fact that I’ve worked at Microsoft, Apple and Google.  I don’t need to spend a ton of time discussing these jobs.  Just listing them is enough.  I put one bullet under each company, covering four internships total, and that’s enough.

See my “one pager” resume: Technical College Resume (2005); Non-Technical Professional Resume (2011)

Sure, it hurt a bit to cut that stuff.  But by removing or reducing those less impressive accomplishments / roles, I ensure that everyone who glances at my resume will see the most impressive things.

Again, if you need more convincing if you aren't convinced of why you can and should have a one page resume, read this post Eight Reasons Why You Need a One Page Resume.

Less Is More: Eight Reasons Why You Need a One Page Resume

(Don't forget to check out Part 2 - Less Is More: How I Cut My Resume to One Page.) Having reviewed resumes for five years, first for Google and now for CareerCup's resume review service, I've frequently gotten resumes from software engineers as long as eight pages.  In fact, the average resume length that I get through CareerCup is probably 2.5 pages.   Yikes!

Now, I know that they think that they've probably really impressed their resume screener.  After all, if they can fill up three (or eight) pages, they must have a ton of experience, right?

Not quite.  In fact, almost anyone can blabber on for multiple pages - and, frankly, it tends to be the people with less experience who feel the need to have such lengthy resumes.

Please, don't do it.  Stick to just one page if you have less than 10 years of experience.  If you have more than 10 years of experience, a 1.5 - 2 pages is allowable (although even there it may not be ideal).

Here are eight reasons why a short and sweet resume is best.

1. Many resume screeners will automatically toss multi-page resumes. I may not agree with that absolutism.  After all, I want to find the best people, not the best resume writers.  But,  given how many people are absolutist about one page resumes (though most make greater allowances for people with more experience), do you really want to get ruled out for such a simple thing?

2. Even if people "accept" a multi-page resume, they may groan when they get one. First impressions matter.  Do you really want someone's first impression of your resume to be "ugh?"  I'll be honest - that's my first thought when I see a three pager.

And, consciously or subconsciously, the "ugh" reaction may make someone itch for an excuse to toss out your resume just so that they'll stop having to read your resume.

3. Longer resumes do not make people assume that you have more experience. I've seen no correlation between the length of resumes and the amount of experience people have. Just because you have a lot more content on your resume does not mean that you have more experience.  Hey, when I was a freshman in college, I had a three page resume. (Yes, it was pretty awful.)

4. Just because your resume is longer does not mean people read more. Recruiters generally spend a fixed amount of time on your resume - and it's only around 15 or 30 seconds.  They do not spend longer on your resume simply because you decided to waste their time by writing a lot more.  What matters is how much - and what - they read, not how much happens to be on a page (see #3).

5. Long blocks of text scares people. My first reaction when I see five jobs with twenty bullets each is to just skip that section entirely. After all, I have a huge pile of resumes to read, I just need to make yes/no decisions on interviewing, and it's so much easier to just toss your resume than wade through massive amounts of text.

6. Longer resumes -> more dilution -> worse impression Think of it this way. Who is a better student?

  • Alex: A-, A+, A-, A
  • Pat: C, B+, C+, A-, B-, A+, B, B, A-, C, B-, A

It turns out that, although Alex seems like  a stronger student, he and Pat have actually gotten the exact same grades.   However, Alex has listed his best five, while Pat wanted to "show off his experience" by listing all his classes.

Your multi-page resume is like that. You've taken your 'A' content and diluted with B and C content. I walk away thinking you're a B candidate, rather than an A.

7. Longer resumes cause people to miss the most important stuff When you have lots of mediocre content on your resume, not only will this detract from my impression of you - but I may never even get to the best stuff.  When you have a few lines about founding a company or starting some major project, but it's buried in three pages of text, I may never see it.  Again, I don't read your resume.  I simply glance at it for 15 - 30 seconds.

8. You are not THAT awesome. Ironically, when I tell people they need to cut down their resume, I get the most push back from people who aren't all that impressive, claiming that they just have  so much experience that they can't cut it down to one page.  Sorry, but you're not that awesome.

Anywhere that you're applying will have a lot of people - perhaps even most - with a lot more experience, or more impressive experience, than you.  And they all manage to fit it on one page.

And, really, you can fit a lot on one page if you understand what you really need to say.  Want an example?  Read Less Is More: How I Cut My Resume To One Page.

The idea of the short and concise resume is to give people the best possible impression given that they're only briefly glance at your resume for 15 - 30 seconds. You'll do that best by limiting it to just your A+ content - through a one page resume.

Why Hobbies are Not Resume Material

Let's end this right here and now: most recruiters / hiring managers don't really care what your hobbies are - or at least not most hobbies. When I'm trying to hire someone, I'm looking for three things: (1) intelligence (2) coding skills (3) good personality (4) work ethic.  #3 is really only prioritized in a small company situation and #4 is really hard to determine.

On your resume, I want you to prove to me that you are smart and that you can code.  And maybe that you have a personality that I'd want to work with.  The fact that you play tennis rarely relates to any of these.

There are a few exceptions to the "No Hobbies" rule:

  • Your hobby is a major accomplishment. For example, you completed a marathon.  That might just barely show a relevant work ethic, and might just barely be worth it to add.
  • Your hobby is tech related. For example, if you write a blog about technology - yeah, I might care about that.  It improves your coding skills since you'll have a better knowledge of what's going on with technology.
  • Your hobby shows a good personality. For example, you are part of a stand-up comedy troupe.  You probably have strong communication skills and a good personality.  It won't matter at all for getting hired (I'll evaluate you based on my own interaction with you), but it might help tip you over the edge as far as selecting your resume.
  • Your hobby shows leadership. If you're the president of a club - or, better yet, founded a club - that might get at work ethic.

The vast majority of the time, your hobbies are none of these things.  They're merely some vague item like "traveling" or "tennis."  I've played tennis and thought it was fun - can I list that on a resume?  I recently saw a resume (from an Indian guy) that listed "Traveling: extensive traveling over North and South India."  This is sort of like saying that I love traveling and I've traveling all over the US.  That's not really what we call "traveling."

The problem with hobbies, other than them just being totally irrelevant, is that anybody can list the same hobbies.  They're rarely ever backed up with evidence, making them even more useless than they were to begin with.

Many students, when I tell them to cut the hobbies from their resume, tell me about how in one interview they / their friend was asked about one of their hobbies.  That's probably true - I'm sure there are lots of interviewers who periodically ask about hobbies.  But, I have a whole lot more stories about being asked about your projects, work experience, etc.

Remember: every line on your resume is replacing something else that could have gone on your resume.  You should add the line that contributes the most value.  Your hobbies rarely do.

Quitting your job? Here's what you should do next.

If you're like many people out there, you're unhappy at your job and just want out. You know you'll be able to focus more on your job search if you weren't constantly distracted with work - and you wouldn't have to make up so many fake doctor's appointments that your boss thinks you're deathly ill. But should you do it? Should you leave your job before you find a new one?

If you can afford it - that is, if you can afford being unemployed for several months - then it might be work it to just take the leap.

But here's the trick: find something "real" to do with your time. Start a business. Chip in at a friend's startup. Re-code your college senior design project in more modern technologies. Just do something!

You'll have a much better answer what you are doing with your time, you'll keep your busy, you'll make your resume a bit more interesting, and, hey, maybe you'll learn something.

Cracking the Coding Interview - Now on Amazon!

Cracking the Coding Interview is now on Amazon!  This book is packed with lots of great content, including:

  • 150 Programming Interview Questions and Solutions
  • Five Proven Approaches to Solving Tough Algorithm Questions
  • Ten Mistakes Candidates Make -- And How to Avoid Them
  • Steps to Prepare for Behavioral and Technical Questions
  • Interview War Stories: A View from the Interviewer's Side

If you're prepping for a software engineering interview at any company, this is the book to get.

One developer's experience (successfully) interviewing with Google India

This is a very nice write-up of a Google interview. For the most part, his analysis of the interview is totally accurate. Read it here. There are a few things incorrect, though, that I should clear up:

  • "No positions for Java programmers". There are lots of positions for java programmers. But, if you see yourself as that, you may not be a good fit for Google. Google wants scientists, not trade programmers.
  • "Same kind of numbness". I don't think is a "strategy" of the interviewers - more likely it's just their personality. What would expect - jumping for joy if you get a great answer? There's really little excitement with a great candidate because they've asked these questions dozens of times. Nor are they going to show frustration.

That said, there's nothing special or magic about a Google interview. Google asks the same kinds of questions as all the other top firms. Programming interview prep is universal (easier for you!).

Picking the Right Companies

I've been working (working: v. to write one or two sentences with the intention of finishing it up later that day, or the next day, or...) for a while on a post about how to pick which companies to apply to. Jon Pincus, my former manager from Microsoft, has done a better job that I would have, so I'll just let him take it from here... Jon Pincus: "You probably won’t be able to get your dream job in your next job; what you want is something that’s noticeably closer than where you are now, and makes it a lot more likely that the following job has even more of the dream job characteristics."

Or, if you're one of those people who want to go to a big company and are just trying to come up with names, Google Sets can actually be useful here. If you put in Google, Microsoft and Apple, it'll return related terms such as Intel, Sun, Yahoo and Blackberry. It's not a perfect list, but it's a start!

Great Resumes for Software Engineers

When I was in high school, a teacher returned an essay of mine with the following written on the top of the paper: "Know your audience." The task was to write a persuasive essay on any topic of our choosing. I just so happened to pick a topic on which the teacher had extensive knowledge and strong feelings. I hadn't been thinking about this at the time I chose the topic, but he was right - I should have known this wasn't a good topic. Lesson learned. Writing a resume is no different. Tailor what you're writing to the specific company and position.

Resume Cosmetics

  • Avoid the Text Blob: Employers don't read your resume - they glance at it for, oh, 10 - 15 seconds. You can't absorb key points from a large blob of text, so bullet your accomplishments instead. Write short, concise sentences. Craft your resume such that a quick glance is enough to say "wow".
  • Use a Template: Do *not* just type everything into Microsoft Word - format your resume nicely by using a template. Microsoft Word has lots of built in resume tables - use one, or make your resume.
  • Pages: if you're a recent college graduate (last few years), your resume should probably be one page. Can't get it all in one page? Trim it down to the most important stuff. This is actually a *good* thing to do, because the best stuff will stand out more.
  • Formatting Tip: Electronic copies: if you create a good format in Micosoft Word, your resume probably uses tables. You may have noticed that table borders show up when you view them in Word but not when you print them out. And guess how many people will view your resume? That's right - on Word. So, you'll want to *really* hide your table borders. Here's how: instead of setting the borders to invisible (invisible on paper, but visible electronic), set them to visible but white. They'll be truly invisible then.
  • Filename: A lot of people send me resumes named liked "Resume.doc", and they get lost. If you don't want your resume to be lost, put your name in the filename (eg, "John Smith Resume - April 2006.doc"). I *highly* recommend that you save it on your computer with such a filename this way you won't forget to send it with the proper name.

Resume Content:

  • Accomplishments, not Responsibilities: Employers want to know not just what you were assigned to do, but what you actually accomplished. For example, saying something like "Reduced time to perform X by 75% by optimizing Y" looks much more impressive than "Responsible for optimizing X." List your accomplishments over your responsibilities, and be specific.
  • Projects: Employers want to see practical experience - that means internships and projects (this is especially true for Software Engineering positions). Yes, have a specific section on your resume for projects - 3 to 4 projects is ideal, whether they're class project or personal projects. If they're personal projects, say so! It shows passion and motivation.
  • Kill the Fluff: I have never once said "oooh... this person claims to have great team working skills. Let's hire them!" Maybe I'm wrong here, but I don't think employers believe fluff stuff just because it's on a resume.
  • For US Positions: Please don't list your age, marital status, gender, etc. I see this a lot with international applicants. In the US, it is illegal to use those as factors in a hiring decision. We don't want those on your resume.

Resume Wording & Proofing

  • Bullets: Bullet each item for a job - you don't need to write complete sentences. Use action words.
  • Spelling & Grammar: Once you've done all this, make sure to check for spelling mistakes, grammatical mistakes and typos. Get as many people as possible to read over your resume and tell them to be picky. This is especially important for non-Native English speakers. Many companies will, unfortunately, toss your resume for a simple spelling mistake.
  • Personal Information: This should be obvious, but double check that your phone number, address and email address are correct. Don't list your cell phone unless you are ok with receiving calls on it.

Resume Customization: I've said that you need to customize your resume based on the position, so I'll explain a little bit about what I'd do for each company. But first, a short summary of the various things I could include:

  • Microsoft Software Engineering Internships: 2001, 2002, 2003
  • Apple Software Engineering Internship: 2004
  • Google Software Engineering: 2005 - Present
  • TAing in College, including being Head TA
  • Webdesign / webprogramming for a small company in Philadelphia before going to Google
  • Creating a course in college and teaching it
  • Teaching at University of Washington while working at Google
  • Planning a lot of large social events with 200+ people (see http://www.theseattleantifreeze.com)
  • 3 or 4 "meaty" projects in college
  • CareerCup (a website for technical job applications)

Software Engineer (anywhere): I'd want to show off the technical problems I've done, as well as show myself to have good initiative. So, I would emphasize the technical work I've done at Google, Microsoft and Apple (big names = prestige). I'd drop the webdesign work - doesn't add much given the other jobs. I'd talk a bit about CareerCup, since that shows independent work. I wouldn't talk much about teaching or event planning, but I'd given them a brief mention.

Program Manager: I'd want to show off some technical stuff, but I also need to show good planning skills, design work, initiative. Google/Microsoft/Apple would have some stuff, but I wouldn't go into as much technical detail. I'd talk more about CareerCup (initiative, ability to drive a project). Planning large social events would be somewhat important too (shows leadership). Teaching at UW and Penn would be good to talk about as well because it shows communication skills and leadership.

Board Position for Theater: I recently applied for a board position for the young professionals group of a Seattle theater. I talked a bit about Google, Microsoft and Apple, but dropped a lot of the technical details. I talked a bunch about event planning, because they would want me to help plan events. I talked more about the various websites I maintain, because, who knows, maybe they would want me to help out with their website. I talked about creating a course at Penn and UW (initiative, communication skills, etc).

I never once exaggerated what I did - I simply cut details or elaborate depending on how important something is.

Resumes for Software Engineers: I'll talk specifically about this since I see tons of Software Engineering resumes.

  • A company like Google or Amazon, which does a lot of server / web work, will be most interested in projects you've done relating to the web or to scalable systems. Microsoft, however, might be more interested in client-side work. Again - customize!
  • Languages (Foreign & Programming): Many employers will expect you to actually be able to *use* the languages you list on your resume - that means if you list French, you should be able to speak french. If you list C++, you should be able to write in C++ - and they might just test you on it. A good thing to do is to list your languages like this:Proficient with: Java, C++ Previously worked with: C, C#, Javascript, HTML Oh, and this is just a pet peeve of mine that has to be said: if you've worked with C++ and C#, don't list them as "C++/C#". Yes, their names sound similar but the languages aren't. The same goes for Java/JavaScript
  • GPA: If your GPA isn't on your resume, the assumption is that it's below a 3.0. So, if you have a 3.2, list it! You can list either your in-major GPA or your total GPA, or both. Feel free to list which ever one's higher. Also, many universities have a policy that you can round your GPA to the nearest tenth. Check with your school, but if so, you should round that 3.67 to a 3.7. Every little bit helps, right?

The most important thing to remember is that all you get to show off your years and years of experience is about 15 seconds. Can you tell the employer enough in 15 seconds to make them pick up the phone and call?

How do you get the right skills?

Technology is a somewhat unique field - in my completely biased opinion - in that your raw skills are tangible and testable. That is to say, in an interview, there's typically less emphasis on "fluff" and more emphasis on what you can actually do. So, how do you build these raw skills?

Regardless of what position you're looking for, if you want to know how to get there, you should ask someone in the field. Think about where you want to be in the next few years. Find a person who is right now where you want to be and ask them (ask them what?) If you don't know anyone offhand, well, that's what Google is for. Find someone and email them. People are pretty willing to help - if you only ask!

That brings me to the specifics. I've been a software engineer at Google for the last two years, so people ask me pretty frequently how they can get a job at Google. The number one thing that I think is missing from applicants is real project experience.

If you're in school, you should study hard and all that good stuff. But, that's not enough. You need project experience - companies want to see what you can actually code. By the time you've graduated, aim to get at least three major software development projects under your belt. Here are a few ideas as to how to get those projects:

  • Many schools offer the ability to do an independent study. Think of an application that you want to build, pitch it to a professor, and maybe you can get credit for it by doing as an independent study.
  • Talk to professors that you know - or even ones that you don't - and ask them if you can help them out with research. If you want to be a software engineer, focus specifically on the projects where you'll be writing code in a language like C++ or Java (as opposed to, say, MatLab).
  • Check out the code to an open source project and build it. Take some time to learn the project architecture, then start coding. Start with fixing a few bugs, and then move into real feature work.
  • Enroll in courses which have large projects. Yeah, they're hard, but no pain no gain, right?

If you're not in school right now, you might be able to enroll in courses at a local university. But if not, you can still do projects on your own. Start with something small - like a Google Maps mashup listing your favorite restaurants - and go from there.

You'll learn a lot from coding on your own, but the benefits go beyond that - simply the fact that you did coding on your own rather than for work / school shows the passion and dedication that every company wants to see.

How to Get Your Dream Job

Every few weeks, I get an email from someone asking if I can get them a job at their favorite tech company. Sometimes I can get this process started for them, sometimes I can’t, but either way, the process of getting a job is about far more than just submitting your resume. So, here it is: getting a job in ten not-always-easy steps.  I’m going to write about each one of these in more detail.

  1. Build Raw Skills Think a few years out about what position you’d like. What do you need to do to get there?
  2. Prepare a *good* resume Great experience isn’t enough. You need to show this in your resume. Remember – a resume is not a timeline of everything you’ve done; it’s a proof of your skills.
  3. Picking the right companies To list just a few things to think about: company size, company culture, the role of someone in your position, how long the company has been around, what the company actually does, growth of the company, location, etc.
  4. Prepare a cover letter This is a company’s first introduction to you, so make it perfect.
  5. Apply! Getting your foot in the door at a company isn’t always easy, but there are a few tricks I’ve learned...
  6. Preparing for the interview Know what to expect and prepare accordingly. If you’re reading CareerCup, you’re probably off to a great start.
  7. Interview This is what it all comes down, and there’s a lot you can do to shape the outcome.
  8. Negotiate You can negotiate (almost) any offer – even if they say it’s "non-negotiable"
  9. Make a decision If you have several offers, you’re in a great spot. How do you pick the one that’s right for you?
  10. Accepting & Denying Accepting an offer is easy, but don’t forget – it’s important that you decline the offer the right way too.

Stay tuned – I’ll elaborate on each one of these in the upcoming weeks.