Introduction
It is 20 minutes talk by Gayle Laakmann McDowell on hackerrank, called "Deconstructs the engineering interview process". Here is the link.
Interesting talk
I like to write down a few arguments and then think about them more carefully.
Ensure that the person is smart. The person can learn the technology and also ... 15:00/ 26:20
The algorithm is challenging, multiple hurdles, ..., no cool math, ... 16:05/ 26:20
Talk about boot camp, transition to IT career, ... 18:00/ 26:20
He is very smart person, ..., 19:30/ 26:20
Bias, try hard? do it best? ..., 20:00/ 26:20
Bar raiser? ..., 23:00/ 26:20
Consensus? ..., 24:00/ 26:20
Are the person smart? attribute? 24:30/ 26:20
Julia's notes
I like to put down some notes here first, and then decide to highlight something interest.
Interview purpose?
to predict who you want to hire, who will make a good employee.
Argument: why the interview is not realistic?
interviews should be realistic
Argument 1:
a good interview is one that is predictive and good candidate experience too
Argument 2:
it’s also not predictive because all you’re really testing is someone’s knowledge
What is to simplify their intelligence? How to assess the candidate's problem-solving skills?
When you stick to basic computer science, when you stick to basic design and algorithm, they should be there if the interviewer is doing the right thing, to essentially assess the candidate’s problem-solving skills, to simplify their intelligence.
And problem-solving skills and intelligence that is actually a very, very important thing for a developer.
Challenging, hard problem, not see the problem before, to prepare a check list:
they need to ask questions that candidates haven’t solved before that are challenging, that are challenging because it’s actually a hard problem and not because it tests obscured knowledge and see how the candidate solves a hard problem.
How to move through the problem? can you make progress on it?
What is qualitative analysis?
Dynamic programming algorithm?
Weak problem solving skills, never do well in those questions.
candidates who are just ok, given them 10 of questions, and then he/ she will do very good since dynamic programming is incredibly formulaic. So ok candidate looks like a great candidate. So dynamic programming is not a very good interview question.
There are so many other problems out there that are going to not be as biased.
How to tell that the person is code money, not done anything challenge?
You want to find people who will be good, who will be able to do cool things, not actually people who have.
What kind of people do you need to be careful in the interview?
People who do a really good job of making what they say sound more complex than it really is.
What to focus on?
You should really focus on figuring out how this person deconstructs the problem and it’s okay to give hints and it’s okay if the person actually solves a problem with a hint. Don’t ding him or her for that.
What to avoid?
based on a trick or which is based on a math formula
How to define hard question? How to separate hard question because of obscure knowledge?
No tricks, not cool math, things whatever -> good hard question
Having questions that have multiple like hurdles, that can be multiple parts to the problem, so it can be a bunch of fault questions. It can also be just a problem that has multiple optimizations to get the most...
A good rule of thumb there is, you’re kind of struggling and you’re trying to give them a hint and you have a part-time figure out how to give them a hint without giving everything away, that’s probably not a good question.
Insecurity, how to deal with it?
given an example using binary search tree,
Please google into a self-fulfilling prophecy?
No comments:
Post a Comment