If You Get Onsite Interview At Facebook Google How Likely Are You To Get Job
In this free email course, I’ll show you how to think correctly while answering difficult algorithmic coding interview questions.
There is no need for a CS degree.
Cool, keep an eye on your email!
The standard procedure is as follows:
- You’ll start with a non-technical phone screen.
- Then you’ll do one or more technical phone interviews.
- The last stage is an on-site interview.
Some businesses additionally include a take-home coding test—sometimes before, sometimes after the technical phone interviews.
Let’s go through each of these stages.
The phone’s non-technical screen
The initial stage is a brief phone conversation with a recruiter, which typically lasts 10–20 minutes. It’s extremely informal.
Expect no technical inquiries. The recruiter is unlikely to be a coder.
The primary aim is to collect information regarding your employment hunt. Things like:
Your timetable. Do you need to sign a contract within the next week? Or are you attempting to begin a new career in three months?
What is the most essential thing to you in your future job?
A fantastic team? Hours that are flexible? Technical difficulties that are interesting? Is there room for advancement to a more senior position?
What projects do you want to work on the most? What about the front end? In the back end? What is machine learning?
Being truthful about all of this will make it simpler for the recruiter to get you what you desire.
One caveat to this rule: If the recruiter asks you about your pay expectations during this conversation, it is better not to respond. Simply state that you’d like to discuss remuneration after determining if you and the business are a good match. You’ll be in a stronger bargaining position later on as a result of this.
The telephone technical interview (s)
Typically, the following stage is one or more hour-long technical phone interviews.
Your interviewer will either call you or invite you to join them on Skype or Google Hangouts. Make sure you can do the interview in a peaceful location with a strong internet connection. Consider investing in a decent pair of headphones with a microphone or a bluetooth earpiece. Always test your hardware first!
The interviewer will want to see you code live. Typically, this entails utilizing a web-based code editor such as Coderpad or collabedit. Run several practice problems with these tools ahead of time to familiarize yourself with them. Some businesses may simply request that you share your screen through Google Hangouts or Skype.
Turn off your computer’s alerts before you begin, particularly if you’ll be sharing your screen!
Technical phone interviews often consist of three parts:
Chit-chat in the start (5–10 minutes)
Technical difficulties (30–50 minutes)
It is now your time to ask questions (5–10 minutes).
The first chitchat is partly to make you relax and half to really be a part of the interview. The interviewer may ask open-ended questions such as:
Tell me a little bit about yourself.
Tell me about anything you’ve created that you’re really proud of.
I saw this project on your CV; tell me more about it.
You should be able to discuss the main projects mentioned on your CV in detail. What worked well? What didn’t work? What would you do differently now?
Then there are the technical difficulties, which are the meat of the interview. You’ll spend the most of the interview discussing this. You may be asked one lengthy question or many shorter ones.
What kinds of inquiries can you anticipate? It is conditional.
Startups often ask queries targeted at developing or debugging code. (“Write a function that accepts two rectangles and determines whether or not they overlap.”) They will be more concerned with development than with perfection.
Larger businesses will want to put your broad knowledge of data structures and algorithms to the test (“Write a function that tests whether a binary tree is time-balanced.”). They’ll be more interested in how you solve and optimize an issue.
The most essential thing to remember while answering these kinds of questions is to keep in constant communication with your interviewer. As you work through the issue, you should “think out loud.” Check out our more comprehensive step-by-step coding interview advice for additional information.
If the position demands knowledge of particular languages or frameworks, some employers may ask trivial questions (“In Python, what is the ‘global interpreter lock’?”).
Following the technical questions, your interviewer will give you the opportunity to ask them questions. Spend some time before the interview going through the company’s website. Consider a few specific questions about the business or the position. This may help you to stand out.
When you’re finished, they should offer you an estimate of when you’ll hear about the following stages. If everything went well, you’ll be asked to conduct another phone interview, or you’ll be invited to their offices for an in-person interview.
The in-person interview
An onsite interview takes place in person at the company’s headquarters. It is typical for businesses to pay for your airfare and hotel accommodation if you are not a local.
The onsite typically comprises of 2–6 one-on-one technical interviews (usually in a small conference room). Each interview will last approximately an hour and will follow the same general format as a phone screen, with technical questions sandwiched between some chitchat at the start and a chance for you to ask questions at the conclusion.
The main distinction between onsite and phone technical interviews is that you will be coding on a whiteboard.
At first, this is uncomfortable. There is no autocomplete, no debugging tools, and no delete button…ugh. The good news is that it becomes second nature after some practice. Practice writing code on a whiteboard before your onsite (in a pinch, a pencil and paper are fine). Some pointers:
Begin from the top-left corner of the whiteboard. This provides the most space. You’ll need more room than you think.
As you type your code, leave a blank line between each line. It makes it a lot simpler to add stuff afterwards.
Spend an additional second deciding on variable names. Don’t hurry through this step. Although it may seem to be a waste of effort, having more descriptive variable names eventually saves you time since you are less likely to get confused when you write the remainder of your code.
A technical phone interview is a sprint, while an onsite interview is a marathon. The day may be very lengthy. It’s best to keep it open—don’t schedule anything else for the afternoon or evening.
If all goes well, you’ll finish by speaking with the CEO or another director. This is just half an interview, and the other half is the business attempting to impress you. They may ask you to a post-work drink with the crew.
A lengthy day of on-site interviews could look something like this:
10 a.m. to 12 p.m.: two back-to-back technical interviews, each lasting approximately an hour.12 p.m.-1 p.m.: one or more engineers will accompany you to lunch, perhaps at the company’s posh office cafeteria.1pm-4pm: three technical interviews, each lasting approximately one hour.
4 p.m.-5 p.m.: interview with the CEO or a director.
5 p.m. to 8 p.m.: drinks and supper with the company
If they let you leave after just a few of interviews, it’s generally an indication that they’re not interested in you. That’s OK; it happens!
There are a number of simple things you may do the day before and the morning of your interview to get yourself in the best possible frame of mind. Check out our article on what to do in the 24 hours leading up to your onsite coding interview.
The take-home code examination
Code tests aren’t widely used, although they seem to be gaining traction. They are much more prevalent at startups or places where your ability to produce immediately is more essential than your capacity to develop.
You will be given a description of an app or service, an approximate time limit for creating your code, and a deadline for submitting it. Usually, the deadline is flexible.
Here is an example of a problem:
Create a simple “To-Do” app. The main functionality should be unit tested. As an added benefit, provide a “reminders” function. Try not to spend more than 8 hours on it, and submit your work by Friday with a brief write-up.
Examine the “bonus” features, if any are included. At the very least, write out how you intend to put it into action.
If they’re looking for individuals who know a certain framework, they may tell you what technology to utilize. Otherwise, everything will be entirely up to you. Use whatever you feel most at ease with. You want this code to display your finest self.
One Last Thought
Some establishments will offer to compensate you for your time. It’s uncommon, but some companies may even ask you to work with them at their office for a few days as a “trial period.”
