Interview advice - Revision history

Anton at 18:28, 14 June 2021

2021-06-14T18:28:10Z

← Older revision		Revision as of 10:28, 14 June 2021
Line 4:		Line 4:
	# Talk about tradeoffs. Interviewers will probably ask about this explicitly (e.g. "what if writes are super expensive" or "what if your input is a petabyte"), but you get bonus points for explicitly pointing out the places where you're making some tradeoff, and where you might do it a different way if you had more knowledge about the specific application. Talking about tradeoffs is especially important for really broad design questions (e.g. "how would you design Google search?")		# Talk about tradeoffs. Interviewers will probably ask about this explicitly (e.g. "what if writes are super expensive" or "what if your input is a petabyte"), but you get bonus points for explicitly pointing out the places where you're making some tradeoff, and where you might do it a different way if you had more knowledge about the specific application. Talking about tradeoffs is especially important for really broad design questions (e.g. "how would you design Google search?")
	# Brush up on data structures and algorithms. I tell this to people because they tend to over-emphasize becoming super fluent in some language. You will write actual code at the interview, but errors in syntax aren't a big deal (unless you claimed to be a language expert on your resume). Being able to find a good algorithm is worth way more points. Thinking about this stuff also addresses (2) above, because you end up thinking things like "I could have constant time reads and log(n) writes, or log(n) reads and constant time writes ... which do I want?"		# Brush up on data structures and algorithms. I tell this to people because they tend to over-emphasize becoming super fluent in some language. You will write actual code at the interview, but errors in syntax aren't a big deal (unless you claimed to be a language expert on your resume). Being able to find a good algorithm is worth way more points. Thinking about this stuff also addresses (2) above, because you end up thinking things like "I could have constant time reads and log(n) writes, or log(n) reads and constant time writes ... which do I want?"
	# Make sure you can code up a recursion (e.g. any problem with backtracking, or depth-first search of a tree). I was surprised how often it happens that a candidate can describe a recursive algorithm extremely clearly, but then falls apart when asked to code it up. ~~Also make sure you use a~~ hash ~~table whenever possible~~ (e.g. if you just need to detect collisions, or if you don't need to keep stuff sorted).		# Make sure you can code up a recursion (e.g. any problem with backtracking, or depth-first search of a tree). I was surprised how often it happens that a candidate can describe a recursive algorithm extremely clearly, but then falls apart when asked to code it up.
	~~# Know that hash tables are in practice constant time insertion and lookup, and they're good for detecting duplicates of anything~~.		# Know that hash tables are in practice constant time insertion and lookup, and they're good for detecting duplicates of anything (e.g. if you just need to detect collisions, or if you don't need to keep stuff sorted).

Anton at 18:23, 14 June 2021

2021-06-14T18:23:27Z

← Older revision		Revision as of 10:23, 14 June 2021
Line 3:		Line 3:
	# Think out loud. The interviewers aren't looking for the right answer (and the questions often don't have one right answer; see (2) below), but for how you think and how you interact with others while solving problems. Thinking out loud also makes it easier for the interviewer to direct the discussion where they want, and to push you in the right direction if you're stuck.		# Think out loud. The interviewers aren't looking for the right answer (and the questions often don't have one right answer; see (2) below), but for how you think and how you interact with others while solving problems. Thinking out loud also makes it easier for the interviewer to direct the discussion where they want, and to push you in the right direction if you're stuck.
	# Talk about tradeoffs. Interviewers will probably ask about this explicitly (e.g. "what if writes are super expensive" or "what if your input is a petabyte"), but you get bonus points for explicitly pointing out the places where you're making some tradeoff, and where you might do it a different way if you had more knowledge about the specific application. Talking about tradeoffs is especially important for really broad design questions (e.g. "how would you design Google search?")		# Talk about tradeoffs. Interviewers will probably ask about this explicitly (e.g. "what if writes are super expensive" or "what if your input is a petabyte"), but you get bonus points for explicitly pointing out the places where you're making some tradeoff, and where you might do it a different way if you had more knowledge about the specific application. Talking about tradeoffs is especially important for really broad design questions (e.g. "how would you design Google search?")
	# Brush up on data structures and algorithms. I tell this to people because they tend to over-emphasize becoming super fluent in some language. You will write actual code at the interview, but errors in syntax aren't a big deal (unless you claimed to be a language expert on your resume). Being able to find a good algorithm is worth way more points. Thinking about this stuff also addresses (1), because you end up thinking things like "I could have constant time reads and log(n) writes, or log(n) reads and constant time writes ... which do I want?"		# Brush up on data structures and algorithms. I tell this to people because they tend to over-emphasize becoming super fluent in some language. You will write actual code at the interview, but errors in syntax aren't a big deal (unless you claimed to be a language expert on your resume). Being able to find a good algorithm is worth way more points. Thinking about this stuff also addresses (2) above, because you end up thinking things like "I could have constant time reads and log(n) writes, or log(n) reads and constant time writes ... which do I want?"
	# Make sure you can code up a recursion (e.g. any problem with backtracking, or depth-first search of a tree). I was surprised how often it happens that a candidate can describe a recursive algorithm extremely clearly, but then falls apart when asked to code it up. Also make sure you use a hash table whenever possible (e.g. if you just need to detect collisions, or if you don't need to keep stuff sorted).		# Make sure you can code up a recursion (e.g. any problem with backtracking, or depth-first search of a tree). I was surprised how often it happens that a candidate can describe a recursive algorithm extremely clearly, but then falls apart when asked to code it up. Also make sure you use a hash table whenever possible (e.g. if you just need to detect collisions, or if you don't need to keep stuff sorted).
	# Know that hash tables are in practice constant time insertion and lookup, and they're good for detecting duplicates of anything.		# Know that hash tables are in practice constant time insertion and lookup, and they're good for detecting duplicates of anything.

Anton at 18:22, 14 June 2021

2021-06-14T18:22:31Z

← Older revision		Revision as of 10:22, 14 June 2021
Line 1:		Line 1:
	~~(0) Think out loud. The interviewers aren~~'~~t looking for the right answer (and the questions often don~~'~~t have one right answer; see (1) below), but~~ for how you think and how you interact with others while solving problems. Thinking out loud also makes it easier for the interviewer to direct the discussion where they want, and to push you in the right direction if you're stuck.		Here's some advice I've given people about interviewing for software engineering jobs.

	(1) Talk about tradeoffs. Interviewers will probably ask about this explicitly (e.g. "what if writes are super expensive" or "what if your input is a petabyte"), but you get bonus points for explicitly pointing out the places where you're making some tradeoff, and where you might do it a different way if you had more knowledge about the specific application. Talking about tradeoffs is especially important for really broad design questions (e.g. "how would you design Google search?")		# Think out loud. The interviewers aren't looking for the right answer (and the questions often don't have one right answer; see (2) below), but for how you think and how you interact with others while solving problems. Thinking out loud also makes it easier for the interviewer to direct the discussion where they want, and to push you in the right direction if you're stuck.
			# Talk about tradeoffs. Interviewers will probably ask about this explicitly (e.g. "what if writes are super expensive" or "what if your input is a petabyte"), but you get bonus points for explicitly pointing out the places where you're making some tradeoff, and where you might do it a different way if you had more knowledge about the specific application. Talking about tradeoffs is especially important for really broad design questions (e.g. "how would you design Google search?")
	~~(2)~~ Brush up on data structures and algorithms. I tell this to people because they tend to over-emphasize becoming super fluent in some language. You will write actual code at the interview, but errors in syntax aren't a big deal (unless you claimed to be a language expert on your resume). Being able to find a good algorithm is worth way more points. Thinking about this stuff also addresses (1), because you end up thinking things like "I could have constant time reads and log(n) writes, or log(n) reads and constant time writes ... which do I want?"		# Brush up on data structures and algorithms. I tell this to people because they tend to over-emphasize becoming super fluent in some language. You will write actual code at the interview, but errors in syntax aren't a big deal (unless you claimed to be a language expert on your resume). Being able to find a good algorithm is worth way more points. Thinking about this stuff also addresses (1), because you end up thinking things like "I could have constant time reads and log(n) writes, or log(n) reads and constant time writes ... which do I want?"
			# Make sure you can code up a recursion (e.g. any problem with backtracking, or depth-first search of a tree). I was surprised how often it happens that a candidate can describe a recursive algorithm extremely clearly, but then falls apart when asked to code it up. Also make sure you use a hash table whenever possible (e.g. if you just need to detect collisions, or if you don't need to keep stuff sorted).
	~~(3)~~ Make sure you can code up a recursion (e.g. any problem with backtracking, or depth-first search of a tree). I was surprised how often it happens that a candidate can describe a recursive algorithm extremely clearly, but then falls apart when asked to code it up. Also make sure you use a hash table whenever possible (e.g. if you just need to detect collisions, or if you don't need to keep stuff sorted).		# Know that hash tables are in practice constant time insertion and lookup, and they're good for detecting duplicates of anything.

	~~(4)~~ Know that hash tables are in practice constant time insertion and lookup, and they're good for detecting duplicates of anything.

Anton at 15:18, 10 June 2021

2021-06-10T15:18:52Z

← Older revision		Revision as of 07:18, 10 June 2021
Line 5:		Line 5:
	(2) Brush up on data structures and algorithms. I tell this to people because they tend to over-emphasize becoming super fluent in some language. You will write actual code at the interview, but errors in syntax aren't a big deal (unless you claimed to be a language expert on your resume). Being able to find a good algorithm is worth way more points. Thinking about this stuff also addresses (1), because you end up thinking things like "I could have constant time reads and log(n) writes, or log(n) reads and constant time writes ... which do I want?"		(2) Brush up on data structures and algorithms. I tell this to people because they tend to over-emphasize becoming super fluent in some language. You will write actual code at the interview, but errors in syntax aren't a big deal (unless you claimed to be a language expert on your resume). Being able to find a good algorithm is worth way more points. Thinking about this stuff also addresses (1), because you end up thinking things like "I could have constant time reads and log(n) writes, or log(n) reads and constant time writes ... which do I want?"

	(3) Make sure you can code up a recursion (e.g. any problem with backtracking, or depth-first search of a tree). I was surprised how often it happens that a candidate can describe a recursive algorithm extremely clearly, but then falls apart when asked to code it up. Also make sure you use a hash table whenever possible (e.g. if you just need to detect collisions, or if you don't need to keep stuff ~~storted~~).		(3) Make sure you can code up a recursion (e.g. any problem with backtracking, or depth-first search of a tree). I was surprised how often it happens that a candidate can describe a recursive algorithm extremely clearly, but then falls apart when asked to code it up. Also make sure you use a hash table whenever possible (e.g. if you just need to detect collisions, or if you don't need to keep stuff sorted).

	(4) Know that hash tables are in practice constant time insertion and lookup, and they're good for detecting duplicates of anything.		(4) Know that hash tables are in practice constant time insertion and lookup, and they're good for detecting duplicates of anything.

Anton: Created page with "(0) Think out loud. The interviewers aren't looking for the right answer (and the questions often don't have one right answer; see (1) below), but for how you think and how yo..."

2021-06-10T15:17:18Z

Created page with "(0) Think out loud. The interviewers aren't looking for the right answer (and the questions often don't have one right answer; see (1) below), but for how you think and how yo..."

New page

(0) Think out loud. The interviewers aren't looking for the right answer (and the questions often don't have one right answer; see (1) below), but for how you think and how you interact with others while solving problems. Thinking out loud also makes it easier for the interviewer to direct the discussion where they want, and to push you in the right direction if you're stuck.

(1) Talk about tradeoffs. Interviewers will probably ask about this explicitly (e.g. "what if writes are super expensive" or "what if your input is a petabyte"), but you get bonus points for explicitly pointing out the places where you're making some tradeoff, and where you might do it a different way if you had more knowledge about the specific application. Talking about tradeoffs is especially important for really broad design questions (e.g. "how would you design Google search?")

(2) Brush up on data structures and algorithms. I tell this to people because they tend to over-emphasize becoming super fluent in some language. You will write actual code at the interview, but errors in syntax aren't a big deal (unless you claimed to be a language expert on your resume). Being able to find a good algorithm is worth way more points. Thinking about this stuff also addresses (1), because you end up thinking things like "I could have constant time reads and log(n) writes, or log(n) reads and constant time writes ... which do I want?"

(3) Make sure you can code up a recursion (e.g. any problem with backtracking, or depth-first search of a tree). I was surprised how often it happens that a candidate can describe a recursive algorithm extremely clearly, but then falls apart when asked to code it up. Also make sure you use a hash table whenever possible (e.g. if you just need to detect collisions, or if you don't need to keep stuff storted).

(4) Know that hash tables are in practice constant time insertion and lookup, and they're good for detecting duplicates of anything.