Make it feel like youre on a team. The interviewer wants to know what it feels like to work through a problem with you, so make the interview feel collaborative. Use we instead of I, as in, If we did a breadth-first search wed get an answer intime. If you get to choose between coding on paper and coding on a whiteboard, always choose the whiteboard. That way youll be situated next to the interviewer, facing the problem (rather than across from her at a table).
Think out loud more. Say what you know. Say what you thought might work and why it wont work. You might realize it actually does work, or a modified version does. Or you might get a hint.
Apply a commonalgorithmic pattern.There are a fewpatternsthat come up again and again in the answers to these questions. Once you know the patterns, designing an algorithm is just a matter of trying a few of them and seeing which one sticks.
Use descriptive variable names.This will take time, but it will prevent you from losing track of what your code is doing. Usenames_to_phone_numbersinstead ofnums. Imply the type in the name.Functions returning booleans should start withis_*. Vars that holda listshould end withs. Choose standards that make sense to you and stick with them.
Its easy to trip over yourself. Focus on getting your thoughts down first and worry about the details at the end.
. Do you see your work through to completion? Do you fix things that arent quite right, even if you dont have to?
Check outinterviewcake.comfor more advice, guides, and practice questions.
. The interviewer just wants you to talk about something. These questions are often either (1) high-level system design (How would you build a Twitter clone?) or (2) trivia (What is hoisting in Javascript?). Sometimes the trivia is a lead-in for a real question e.g., How quickly can we sort
piece of trivia about your favorite language, and something you do and dont like about said language
question about the companys engineering strategy (testing, Scrum, etc)
items, so I must at least spend that amount of time.
I have to at least look at all of the items, so I cant do better than
If you start writing code and the interviewer just wanted a quick chitchat answer before moving on to the real question, theyll get frustrated. Just ask, Should we write code for this?
Write a naive, inefficient solution and optimize it later.Use brute force. Do whatever it takes to getsome kindof answer.
Before diving into code, most interviewers like to chitchat about your background. Theyre looking for:
Programming interview practice and tips for software engineers looking for jobs.
Wait for a hint.Dont stare at your interviewer expectantly, but do take abriefsecond to thinkyour interviewer might have already decided to give you a hint and is just waiting to avoid interrupting.
Draw pictures.Dont waste time trying to think in your headthink on the board. Draw a couple different test inputs. Draw how you would get the desired output by hand. Then think about translating your approach into code.
For coding interview prep, theres really no substitute for practice.
. The interviewer wants to see you write clean, efficient code for a problem.
Programming interview questions by company:
Once you get into the coding questions, communication is key. A candidate who needed some help along the way but communicated clearly can be even better than a candidate who breezed through the question.
Sign up for updates. Free practice problems every week!
Digging deep into those patterns is outside the scope of this piece, but you can learn about them in my 7-day email course:
of integers? Good, now suppose instead of integers we had . . .
Subscribe to our weekly question email list
question about the companys product/business
Save off-by-one checking for the end.Dont worry about whether your for loop should haveor=. Write a checkmark to remind yourself to check it at the end. Just get the general algorithm down.
. Would chatting with you about a technical problem be useful or painful?
Look for off-by-one errors.Should your for loop use a=instead of a?
id:8427971,username:2018-06-01_06:20:l:null,date_joined:2018-06-01T06:20:56.178478+00:00,first_name:,last_name:,full_name:,short_name:friend,is_anonymous:true,is_on_last_question:false,percent_done:0,num_questions_done:0,num_questions_remaining:46,recruiting_is_interested_in_intros:null,is_full_access:false,first_payment_date:null,last_payment_date:null,num_free_questions_left:3,terms_has_agreed_to_latest:false,preferred_content_language:,preferred_editor_language:,is_staff:false,auth_providers_human_readable_list:,num_auth_providers:0,auth_email:,profile_public_id:null
Slow the eff down. Dont confidently blurt out an answer right away. If its right youll still have to explain it, and if its wrong youll seem reckless. You dont win anything for speed and youre more likely to annoy your interviewer by cutting her off or appearing to jump to conclusions.
Programming interview questions by language:
Dont be boring.Some interviewers wont care about these cleanup steps. If youre unsure, say something like, Then Id usually check the code against some edge casesshould we do that next?
Dont worry about syntax.Just breeze through it. Revert to English if you have to. Just say youll get back to it.
story about what you should have done differently in a past project
Nerd out about stuff. Show youre proud of what youve done, youre amped about what theyre doing, and you have opinions about languages and workflows.
. Do you think about how to code well?
Check outour mock coding interview questions. They mimic a real interview by offering hints when youre stuck or youre missing an optimization.
Leave yourself plenty of room.You may need to add code or notes in between lines later. Start at the top of the board and leave a blank line between each line.
Solve a simpler version of the problem.Not sure how to find the 4th largest item in the set? Think about how to find the 1st largest item and see if you can adapt that approach.
Well never post on your wall or message your friends.
Test edge cases.These might include empty sets, single-item sets, or negative numbers. Bonus: mention unit tests!
Sometimes youll get stuck. Relax. It doesnt mean youve failed. Keep in mind that the interviewer usually cares more about your ability to cleverly poke the problem from a few different angles than your ability to stumble into the correct answer. When hope seems lost, keep poking.
Think about the bounds on space and runtime.If youre not sure if you can optimize your solution, think about it out loud. For example:
Walk through your solution by hand, out loud, with an example input.Actuallywrite downwhat values the variables hold as the program is runningyou dont win any brownie points for doing it in your head. Thisll help you find bugs and clear up confusion your interviewer might have about what youre doing.
Think out loud.Seriously. Say, Lets try doing it this waynot sure yet if itll work. If youre stuck, just say what youre thinking. Say what might work. Say what you thought could work and why it doesnt work. This also goes for trivial chitchat questions. When asked to explain Javascript closures, Its something to do with scope and putting stuff in afunctionwill probably get you 90% credit.
example of an interpersonal conflict you overcame
Call a helperfunctionand keep moving.If you cant immediately think of how to implement some part of your algorithm, big or small, just skip over it. Write a call to a reasonably-named helperfunction, say this will do X and keep going. If the helperfunctionis trivial, you might even get away with never implementing it.
Understand what kind of problem it is. There are two types of problems:
Say you dont know.If youre touching on afact(e.g., language-specific trivia, a hairy bit of runtime analysis), dont try to appear to know something you dont. Instead, sayIm not sure, but Id guess $thing, because…. Thebecausecan involve ruling out other options by showing they have nonsensical implications, or pulling examples from other languages or other problems.
The brute force approach is to test all possibilities, which is
example of an interesting technical problem you solved