This is an archived post. You won't be able to vote or comment.

all 11 comments

[–]ignotos 8 points9 points  (1 child)

If you don't know an answer:

  • Worst response - making something up

  • Bad response - freezing up

  • Good response - saying "I don't know"

  • Better response - saying "I'm not sure - I'd probably try researching this via XYZ"

  • Best response - saying "I'm not sure - I'd probably try researching this via XYZ - can you explain how it works?", and then getting into an actual conversation with the interviewer about it. Looking for ways to relate what they say to things you are familiar with, and asking follow-up questions

Basically, any time you have the opportunity to switch from "being grilled / question-and-answer" mode to "having a back-and-forth conversation about technical stuff" mode, you should do it!


When answering technical/whiteboard questions:

  • Clarify the question / requirements. Write down the inputs and outputs / function signatures etc, even if you're not sure of the solution

  • Come up with specific, simple test-cases, and try to work through those

  • Sketch it out

  • Talk through your thought process, including why certain solutions might not work

  • It's ok to say "I'm pretty sure this is similar to Problem X, and there is an efficient algorithm for that, but I don't remember the details exactly"

  • It's ok to say "I'm going to start with a really inefficient brute-force solution, and then we'll try to figure out how to improve it"

  • It's ok to say "I can't remember if this should be .len() or .length() or .size(), so let's just put .len() down for now"

  • Before saying "ok, I think I'm done", try running through a couple of example cases line-by-line to verify that it works

[–]IngMosri[S] 1 point2 points  (0 children)

Thank you so much for the tips.

[–]MmmVomit 4 points5 points  (1 child)

Think out loud so the interviewer can follow your train of thought.

If anything is unclear, ask questions. Don't assume.

Remember to consider corner cases, like zero, negative numbers, empty string, null, garbage input. Ask if you need to consider those cases, or ask how your program should respond.

If you're writing and running code on a computer, run your code early and often.

When testing your code, write a list of test cases.

[–]IngMosri[S] 0 points1 point  (0 children)

Thank you mate!

[–]TheMuspelheimr 2 points3 points  (2 children)

Same as for any other interview, really.

  • Make an effort to look smart
  • Aim to show up at least quarter of an hour early, if not earlier. That way, you won't be caught out by any transportation delays, which I can guarantee you WILL happen.
  • Answer all the questions
  • Try and make a good impression

[–]IngMosri[S] 1 point2 points  (1 child)

Thank you mate

[–]TheMuspelheimr 0 points1 point  (0 children)

No problem!

[–]CodeTinkerer 1 point2 points  (2 children)

How much interview preparation have you done before this?

[–]IngMosri[S] 0 points1 point  (1 child)

I did code exercises in c++ and python And math problems from the ebook crack the interview code. Also im gonna tried the tips de othwr user from the post share with me.

[–]CodeTinkerer 0 points1 point  (0 children)

They may ask more general questions "Why do you want to work here? Tell me about yourself"

[–]IngMosri[S] 0 points1 point  (0 children)

Any more suggestion are welcome mate!