May
11, 2015
First
time I read the article, and then, strongly agree that the argument makes good
sense. Great developer is rarely on the market.
So,
I am so relax, and enjoy myself to stay as is.
May
12, 2015
great
website:
January
7, 2016
-- 45 minutes interview --
Engineering skills Assessment
1. write good code
2. Algorithm and data structure
3. Analysis skills
4. Sound design
We want to see you can write good code
How to apply to the problem?
How to approach the bits?
Sound design in your code?
limitation or corner case
More detail about “Analytical skills” - make note - do
this kind of checks
More detail about “Sound design”
Need to understand what exactly can go wrong.
How to prepare your interview?
Go through the questions, the interviewer will go
over
Advices from coaching:
1. Practice on white board or paper
2. Don't use pseudo code - we want actual code
3. Interviewer will ask which language you
prefer
And,
the best of advice Julia likes:
Write a lot of code -
no better way to write a lot of code
Practice to write on a white board
Like to see the code will be neat, and will work
We don't want the pseudo code - which ever main stream
language you will use
We really are interested in how you approach the
problem.
Think about loud, no idea if you understand the
problem, walk through the problem.
Easy on guiding you through,
Questions are in-depth
The questions might have simple solution. A lot of
them are set up, simple, but we expand to cover other situation.
Show them how to approach, and how to expand the
problem.
Nice answer is kind of relative. Will not criticize
you
Simple solution you can start, given the assumption,
we can change the assumption to simple, or complex, and then, the problem can
go on and on.
Sample interview question:
"Write a program that breaks up a string of words
with no spaces into a string with the appropriate ...
--------------------------- one slide
Clarify the problem
. Consider an example that's rich enough but not
tedious:
"fastman" -> "fast man"
Disambiguous expected result:
More than two words? Empty string?
. State and clarify key assumptions: expected result,
any memory or performance requirements, etc.
Where do the words come from? Use a dictionary
. Clarify the function signature
------------------------------ next slide
it is not best solution, but we can go from there - a
fair straightforward solution
brute force solution - nxn solution - not good
solution but solve the problem
---
Working through the problem - part 2
Advices:
Start with the first solution that comes to mind
. Feel free to say that first solution will be refined
later.
. This will usually be a brute force solution
. Run through at least one or two examples to check
for correctness
. Check again for edge cases
. Try to use reasonable variable names or clean up the
code after the first pass
. Ask if the interviewer has any question before
refinement
Advice:
Allow the interviewer to ask question.
Working through the problem - part 3
Refine the solution
. Clarify assumptions (e.g., improving
performance)
. Rinse, repeat
. Compare the solution
Working through the problem - part 3
Refine the solution
. Allow for an arbitrary number of words
"applesauceman" -> "apple sauce
man"
"iamdoingwell" -> "I am doing
well"
Multiple solutions of greatly different complexity!
What if the dictionary cannot fit in memory?
How would you print the most likely of multiple
choices?
What if the words are not spelled correctly?
Advice:
The interview should be fun. Two engineers are
discussing the problem. How to solve the problem? How to make it better?
Example solution
--------------
Tips
Semi brute force solution:
---
Tips
optimizing
. Talk through naive solution(s). see if you can come
up with a reasonably efficient one.
. Time/space tradeoffs
. Assumptions: what if the input is big? small?
API
. If you can't remember the name of a method, or how %
behaves with negative numbers, ask!
Testing
. Say what cases would you test
. Try to reserve time to work small case (iron out
boundary conditions, etc.)
More interesting
Q&A
Few questions to go over:
1. Do Google consider culture difference? Every
googler learns the culture.
Speaking English is a plus
2. Google learns how to train interviewer.
Strict rules - what to look for:
You observe them, and they observe you. Two people show
up, an interviewer is under training. One will be quiet in the corner.
3. Ask questions part
- initial part - break ice
- try to make them feel more relax
- become conversational
- try to help them out
- what angle you look at
- start to talk about the problem -
People communicate the ideas
- We do understand the …
- Julia's comment: write down more on this
4. C++, Java,
/ Certification - does not matter
Just good coding skills - show case in five
interviews
(not C# for Google, Julia, is time to learn advanced C++,
and read more C++ code/ Java code)
5. Tech interview
We want you how you solve the problem, how you
think;
First a few months, relearn everything at Google. So,
it is important to show you how to learn things, solve problems.
ramp up - weeks, we are talking about months.
6. Interviewer how to choose questions?
Mock interview
A set of questions I used, helps me to help you
I understand the question, some of them goes away the
rail; we are not talking about it today.
They already see all the solutions; do not want
you go down some way, waste all of us time.
Understand the problem, know math,
Advice:
We want you to
prepare. Preparation is a big deal. Multiple interviews a day.
Binary tree / Binary search tree / Just a conversation
/ a peer / Last but least / delay and reply
Interviewer - hard to say - recruiter will tell you
what's going on.
During the interviewer, the interviewer will take some
notes.
June 6, 2016
https://www.linkedin.com/pulse/5-simple-rules-success-new-job-hamid-al-azzawe?trk=hp-feed-article-title-likeMarch 4, 2017
Watch the video again.
Hangouton Air: Candidate Coaching Session: Tech Interviewing
No comments:
Post a Comment