Three years ago, when I was looking for a job after 10 years of working at one company, I really wished there were consultants to help software developers to improve their resumes and prepare for technical interviews. How enormously helpful it would be if someone who was a developer once to guide your preparation! Especially if such a person collected many years' and many companies' worth of technical interview questions.
Such a company now exists, and its founder, former Google engineer Gayle McDowell, visited Austin last year to promote her book "Cracking the Coding Interview". In her presentation, based on the book, she advised software developers what to expect at, and how to prepare for technical interviews. I found myself agreeing with Gayle half of the time, and scratching my head the other half. If my experience did not match her recommendations, the reason may have been that her advice was directed to (a) mostly beginner programmers, and (b) those who want to work at big companies. No wonder her presentation was paired with a hiring pitch by Amazon Web Services.
Let us see, then, how my experience of interviewing for software development jobs stacks up to Gayle McDowell's advice.
What happens when "they" pull your resume out of a giant pileGayle's version
My experience I haven't been on the recruiting side of things, but I was hoping that that's how it is -- that a real hiring manager (i.e. someone who knows what to look for in a developer), would look for that, as opposed to for buzzwords from an HR bingo. |
Resume lengthGayle's recommendation: Your resume should be 1 page only, unless you have more than 10 years of experience. In a 2-page resume, no one will read all the points; they might read 50% at most. The hiring manager will skim your resume and notice only some random job experience points. Some of them won't be your strongest. Wouldn't you want a hiring manager to notice only your strongest experience? If so, cull them and put them on a 1-page resume. My experience: I had many seasoned recruiters tell me that my resume needs to be 2 pages. But then, I have more than 10 years of work experience. |
Technical questionsGayle McDowell recomended her company's website, CareerCup.com, for a good list of real interview questions. I checked it and the questions are really good -- they don't test your knowledge of a programming language syntax, but rather test your ability to design, as well as deep understanding of object-orienting programming. |
"Don't memorize!"Gayle's recommendation: If an interviewer asked you a question you've already heard before in a different interview, don't just spit it out the answer -- tell them first that you've heard it. It's likely that the interviewer will still ask you to answer the question / solve the problem, but you won't come across as dishonest. Plus, they don't want just to hear you spit out the answer -- they want to know your thought process. Seeing that you've memorized some answer tells them nothing about you -- the question was wasted. It didn't give them any extra information about you. My experience: Perhaps this is reasonable for college students, but if I am an experienced programmer, I might have faced certain types of problems in my programming practice often enough that I know the answer off the top of my head. Such is the question mentioned later in this text, where the answer turns out to be binary search tree. What if at some of my previous jobs I searched for data in large lists? Then I could spit out the answer "BST" before I even heard the end of the question, and it's not because I heard it in another interview, or memorized the answer off of some online preparation site -- it's because I know it from practice. |
Push yourselfGayle's advice:
My experience:
|
Data structuresGayle's recommendation: You have to know how to implement, or when to use, the basic data structures: linked lists, stacks, queues, trees, tries, graphs, vectors, heaps, hashtables. Especially hashtables -- they come up often in interviews. My experience: I agree about the importance of hashtables. Many code problems I've been given in interviews required use of a hashtable for best solution. Linked lists were the second most popular data structure -- for example, I was asked to write code to reverse a linked list. There was a time when I was asked to write a program for searching a binary tree. But I was never asked about a stack, queue, trie (whatever that is?), graph, or heap. (As for vectors, they are essentially arrays, and they are used in every coding problem -- you can't write almost any code without it.) |
Algorithm QuestionsGayle's advice: Study the basics: complex algorithms usually unnecessary. My experience: I agree: I have never been given a problem that required more than a simple algorithm. Well, at one point I was shown the code for merge-sort, and asked what was the complexity of that code (it's |
Decomposing algorithm problemsGayle's advice: To make the problem easier to solve, decompose it in 4 steps: My experience: Overall I agree, however, I think we think about decomposition differently. |
Example of decomposition
Design an algorithm to print subsets of a set:
Gayle's decomposition:
My comment: This is an example of a problem that can be solved inductively, but there are many problems where induction wouldn't help. Such is, for example, a problem that I was asked at a past interview -- determine if two words are anagrams of one another. It's easy, yes, it's just not inductive. Probably because we are not required to find all anagrams of each word (in which case it would be closely related to the subset problem), only to determine whether one word can be an anagram of the other, i.e. if both words have the exact same set of letters. You don't gain knowledge on how to do it for a 3-letter word if you know how to do it for a 2-letter word, because it's an exact same problem. |
Pattern matching as a step decomposing algorithm questions
Gayle's way:
My comment:
|
Gayle's way:
My comment:
|
Unconventional, but intuitive advice
Some of Gayle's general interviewing advice was not what career advisors typically give, but consistent with my experience. Such as: there is no need to write thank-you cards, because no candidate for an engineering position was ever rejected for not writing a thank-you card. People make a decision whether to hire you pretty soon after the interview - perhaps within a day or so -- and that's much sooner than your thank-you card could reach them. From over a hundred of candidates that she had interviewed at Google, she got only 1 thank-you card, and it did not sway her decision towards that person in any way.
Finally, do not despair if you think you did poorly. Gayle says that you really, truly can't know how well or poorly you did. Seriously, you think you do, but you don't. Candidates are evaluated on the scale of comparison with other candidates, so sometimes you might think you did really poorly, but in the interviewer's eyes you were the best candidate interviewed for this position.
No comments:
Post a Comment