Programming Interviews Exposed 189
| Programming Interview Exposed | |
| author | John Mongan and Noah Suojanen |
| pages | 272 |
| publisher | John Wiley & Sons |
| rating | 8/10 |
| reviewer | Gavin Bong |
| ISBN | 0471383562 |
| summary | A book to help developers achieve success in their technical interviews. |
Introduction
Many people consider an interview a Kafkaesque experience, where all your skills (technical and social) come under the microscope. My toughest interview was one where I sat in a conference room faced with five hungry interviewers and "How many lines of code have you written in your career?" was considered small talk.
The promise
This book will not teach you how to handle small talk, but still may do wonders for you in your next interview. The author's promise, that reads: "If you work on learning to solve not just the specific problem we present, but the types of problems, you'll be able to handle anything they throw at you," is certainly ambitious, but they've succeeded admirably in my opinion.
General overview of book
Chapters 1 and 11 are short and sweet, but impart important lessons on how to negotiate offers, preparing for open-ended questions like "What are your career goals?" and generally convincing the employer that you can fit into their culture. Appendix A's coverage of writing technical resumes is brief but sufficient. Their bottom-line message is: craft a resume to sell your skills; don't write an autobiography.
The rest of the book comprises a review of common programming questions you may face, as well as a selection of puzzles that appear regularly in technical interviews.
The secrets summarized
The authors' secrets to technical interview success can be summarized as follows:
- Make sure you master the programming language that the job asks for.
- Practice solving problems and study heuristic methods.
- Master common data structures like linked lists, strings, trees & graphs.
- Be conversant in programming paradigms like recursion and Big O notation. And depending on the area of expertise that the interviewer is looking for, brush up on topics like concurrency, networking and database concepts.
Let's dissect these bullet points one by one
(1) The authors expect the interviewee to master every feature of the language that the job calls for, including the quirky and obscure ones. Personally, I think that knowing the core elements plus the specific features that the employer is looking for is more than enough. For example, in the Java paradigm; multithreading would be considered core, while knowing JNDI would be a speciality. But take note that an interview is not something you study for. It's not like a certification exam. You certainly need a couple of projects using that language under your belt to be absolutely prepared.
In interviews where you can choose the programming language, the authors caution against using lesser languages like Javascript or Visual Basic. But my opinion is that -- if it's used appropriately, and within the bounds of the job description -- any of these should be fine.
(2) G. Polya once said "Experience in solving problems and experience in watching other people solving problems must be the basis on which heuristic is built." The authors have kept to this spirit and included a generous number of challenging puzzles to exercise your brain. This is no coincidence, as both authors graduated from Stanford, where Polya once taught. Solutions are provided, but more importantly they've also included descriptions of the thought processes that underlies them. And by the way, the types of puzzles listed here probably wouldn't be out of place in a MENSA exam or the U.S. Computing Olympiad.
The authors also offer practical suggestions on how to solve problems, such as "Think out loud by explaining what you're doing," and "If you're stuck, consider looking at a specific/general example of the problem."
(3) The book offers one full chapter on linked lists. The author is justified in this, as linked lists can be operated upon by a multitude of operations. And each operation can usually be coded with a minimal number of lines of code. Ignore this advice at your peril.
(4) From experience, the authors have found that if you don't put down a particular skill in your resume; questions on those topics will not generally arise. So by setting the right expectations; you'll be able to get through the interview with fewer tangled nerves. But general programming knowledge questions like "What does it mean to be a 32 bit OS?" or "What is the difference between C++ and Java?" should be expected. Chapter 10 offers a healthy sample of them.
Weakness
One of the strengths of this book is that it focuses fully on the topic at hand which is "programming interviews" and never gets sidetracked. However it does have its weaknesses, in that there's very little mention of the high possibility of questions on component programming models (EJB,COM/COM+,CORBA). I think component-based software development (using off-the-shelf components) is the future of our industry (whether open or closed source) and companies are not interested in creating software from scratch. Also missing from the book is any mention of localization or internationalization of software.
Is it worth buying?
At 272 pages, this book can easily be skimmed in one sitting. But its value will not be apparent until you start solving the included problems/puzzles yourself and understanding the pattern of interview questions. This book is not a magic bullet that will guarantee you success in every technical interview, but having a rough estimate of what you will face is certainly better than being surprised.
Who is the target audience?
This book is especially relevant to recent computer science graduates who are just entering the industry. It may also be useful to technical recruiters and software managers (who assume the role of interviewers) who want to get some insights into the interview processes used by other companies. It might not be appropriate for people from other technical disciplines like system administrators or DBAs. Seasoned programmers may still get some benefit from the book although you've probably had first-hand experience with most of the questions/problems posed in the book.
Table of contents
- Chapter 1: The Job Application Process
- Chapter 2: Approaches to Programming Problems
- Chapter 3: Linked Lists
- Chapter 4: Trees and Graphs
- Chapter 5: Arrays and Strings
- Chapter 6: Recursion
- Chapter 7: Other Programming Topics
- Chapter 8: Counting, Measuring and Ordering Puzzles
- Chapter 9: Graphical and Spatial Puzzles
- Chapter 10: Knowledge Based Questions
- Chapter 11: Non-Technical Questions
- Appendix A: Resumes
All you need is one phrase... (Score:5)
Secret to Coding Revealed! (Score:1)
Shortage (Score:2)
Broken link (Score:1)
Link for 'publisher John Wiley & Sons' is broken. Please fix.
Some handy interview tips. (Score:5)
No biting
When asked about prior work experience, you don't need to mention the summer at the badger insemination factory.
No hairpulling
Never Look the interviewer directly in the eye, this can appear confrontational
Leave before the interview is over, so you don't seem overly desperate
Linked lists? (Score:5)
The place I want to work (in fact, the place I AM working) is where they know you are a good problem-solver and that you can pick up any tools you need. Specifics like linked-lists tell nothing about the quality of the employee.
And this isn't just me talking as an employee. I hired a guy once who had a civil engineering degree. He didn't know things like linked lists, depth-first vs breadth first, turing machines, yada yada yada. And his programming wasn't even all that top-notch (good, but not what I'd call outstanding). But could that boy solve a problem and FAST. Give him a task, however complex, and you'd know it was SOLVED--ASAP.
--
Soda in the fridge? Screw that! (Score:2)
Sometimes you by Force overwhelmed are.
Not how I handle it (Score:2)
Remember, YOU are interviewing THEM too. There are companies out there that will suck the very life-force from your body. You must make sure that the company is a good fit before bending over to sign the offer letter. Don't be afraid to get the upper hand. If you're good, you can afford to take the initiative and put them on the spot. Your career will thank you.
Something can be said... (Score:1)
What I mean is this:
Within reason, make yourself appear to be very needed. Obviously you must use caution because if you go too far outside the "BS Boundaries" you will be spotted. While being casual and amiable, play down any little problems they may ask you about during the interview. Only do this if you are confident you are correct, of course. If you create an air of genius about yourself, those interviewing will probably think it too.
Or I could be entirely wrong...hehe...follow this advice at your own risk.
Key interview question (Score:2)
Re:Around here... (Score:2)
Re:Beer ...? (Score:1)
Ask the Headhunter (Score:1)
Re:Shortage (Score:1)
Re:Some handy interview tips. (Score:2)
- urinate
- defecate
- flatulate
Any I missed?-- Sig (120 chars) --
Your friendly neighborhood mIRC scripter.
Re:Around here... (Score:1)
Re:Around here... (Score:1)
How to get a 3L337 j0b (Score:4)
w0rk3d 4 m3
->mafiaboy
Luck (Score:2)
Luckily for me, the interview for my current job (a rather good one, IMHO) went like this:
I was with a guy I knew, who was talking to a co-worker on his cell phone. He turned to me and said: "How would you like to spend the summer in New York City, getting paid $20/hour while [the company] covers your hotel, travel, and food expenses?"
Me: Sounds great.
Him (to cell phone) : Okay, he says yes.
Re:Key interview question (Score:2)
not a 100% troll... (Score:5)
The company I recently took a job at was more impressed with the fact that I can pick up new languages and learn new technologies quickly, rather than my extreme expertise in one area. I am not looking to get hired because I know the birthdate of the mother of Linus' dog. Get it?
Its a shame when I see so many schools teaching "hands on/technical programming" in their Computer Science courses... IMHO and experience, teaching CS with an "algorithmic" approach is much more effective.
Technology comes and goes, we're in a time of innovation, do you really want to spend so much time and energy into knowing every bit of detail, when you could be building other, more useful skills?
Having a lot of "linux geek" friends, I used to get yelled at a lot to "RTFM" (read the effin manual). Well, I'd say keep this in mind when applying for a job. You can always RTFM. You don't need to know every specific of everything. You need to be able to, and be comfortable with learning new things.
Cheesy quote, but true: "Its not the quickest, or smartest animals that succeed.. but the ones who adapt the quickest." - I think it was Darwin.
Over and out.
Another resource (Score:2)
Link for you disillusioned people (Score:1)
Re:Not how I handle it (Score:1)
Indeed, I forgot this one rule and wondered why the director wanted to chat about Monty Python and some old defunct hardware achitectures, rather than the work to be done. Little did I know he was just shoveling "savings" to the pres. to look like he was doing his job. It sucked to work for him, because he never had a clear picture of what was really needed.
[companies need good programmers]
Worth noting, there are people who can program and there are progammers. People who can program can live, breath, eat and sleep. Programmers live, breath, eat and sleep code. There are too many of the former thinking they are the latter.
Re:Key interview question (Score:1)
And, yes, I'd want to hire people who can take a joke, which obviously puts you off the list.
Re:Some handy interview tips. (Score:1)
there are probably more
I've got it (Score:1)
any given time there is at least 2 cases in the
fridge. Nice selection too.
Re:Not how I handle it (Score:2)
One crucial thing to ask about is the company's size and their rate of expansion. If a company is increasing size from 10-15 to 25-30 in a matter of months, beware. Such companies are just about to go through adolescence, and it can be a painful process. Especially avoid such companies if they say things like "we've never needed documentation in the past [when we had 5 programmers] so we don't need it now [when we have 20]".
Interviewers for what companies? (Score:1)
Most interviewers I've talked to seem a lot more interested in the candidate's age, gender, ethnicity, sexuality, and politics than they are in what the candidate can do. Of course who you know and how you dress is even more important, but if you don't have those down, you even get to the interview.
Re:Linked lists? (Score:2)
Gavin Bong. (Score:1)
This author doesn't know how to land the cool jobs (Score:5)
A couple points I've learned in my interviewing experience (and I've never been turned down for a position I've interviewed for. Ever.)
If you're interviewing at a place that is going to quiz you on the spot, you're not going to be happy. I can see maybe showing you some code and asking you to explain what it does - but your educational qualifications and prior experience should be enough to demonstrate you are capable. I don't remember 1001 buzzwords well. This is usually a mistake that first-time or inexperienced interviewers will make.
What you do to land a cool job is you get a chord struck with the interviewer on a personal level. You take the opportunity to talk about the cool mp3 system you programmed for your car. You talk about the challenges you had going through school. Talk about the moment when object oriented programming became clear to you. You want to avoid the horrible standard questions like what do you want to do with your career - if you're reading a cookie cutter answer, you're going to be like everyone else.
When I get asked questions like that, I talk about experiences I've had in the field, positive and negative, and how I'd make sure that they happen/don't happen again. Demonstrate to the interviewer you're personable and they can work with you - you don't need to prove yourself at this stage, a mistake many people make. If you're being interviewed, you're good on paper. They want to see if they can trust and deal with you on a daily basis. Let your personality come through.
This is something you'll never see taught in a resume course. BE YOURSELF. If you're not, you won't be happy in the job - because they didn't hire you, they hired that person in the book.
Re:Shortage (Score:2)
But then, don't rely on just that. If all you've got are friends, they'll see through you within weeks, or days.
Re:All you need is one phrase... (Score:1)
however, that's the *last* thing you should say.
even if you are, in fact, kidding.
:\
Re:not a 100% troll... (Score:1)
Yes, it's frustrating now - the environment is changing and the situation has not yet evolved to meet the new environment. This is an annoyance, yes, but a temporary one - the history of the world is driven by the resolution of such evolutionary tension.
But I think the point is... (Score:1)
its all about skill, skill, skill.
Knowing syntax doesn't count!!! You gotta understand WTF yer doing. Just coz you have a CS degree doesn't mean jack, IMHO.
You missed these (Score:1)
Debate
Delegate
Desecrate
Designate
Instigate
Investigate
Masticate
Probagate
Postulate
Relate
Dilate
Grate
Mate
However, it is OK for prospective porno actors to masturbate
before the interview (Score:3)
Re:But I think the point is... (Score:1)
Re:Key interview question (Score:1)
Would you try the same approach with a client? If he doesn't 'get the joke', he's too ignorant to bother with?
Employer-employee relations are built on respect first, ability second and personality third; much like client-contractor relationships. Except when long-term is not a priority.
Getting a job is a serious matter, and many people CARE about the interview process. Many are uptight about it, and while the ability to take the stress in stride is a bonus, it shouldn't be a requirement. Unless the shop image is such that taking the job seriously is not important.
Re:Beer ...? (Score:1)
Certianly don't order a beer if they take you out for lunch you really don't want them to think that you're that much of a raging alcoholic. ;o)
________________
Re:But I think the point is... (Score:1)
Re:Around here... (Score:2)
agreed (Score:1)
Her being a cute, young female, this throws MANY of my male friends off track. They get all airheaded and start drooling. But hello... she couldn't understand an application walkthrough or debug logic if her job depended on it (I've saved her ass many times). Sure she knows syntax, but theres not heart behind it.
I'm still a firm believer that I dont have much to learn from a CS major.
Re:Beer ...? (Score:2)
I'm assuming this is a straight question, I'll give a straight answer.
The "dinner" part is important - if this were during business hours then alcohol is out of the question entirely. With dinner, then, maybe.
Even then, you're best bet is to pass on the beer. Consider the worst-case scenarios... if you order beer and they're stuck up hyper business types you've just lost points (and possibly the job). If you don't order beer and they do, they'll probably just put it down to your trying to make the best impression, and not hold it against you.
Now I'm assuming you're going for some sort of technical job - if, on the other hand, you're pitching for a position that would have you out and schmoozing, wining and dining the customers, that's a different kettle of fish. They might be very interested in how well you can hold your liquor
This advice is localized to the Midwest US, your milage may vary according to location. Good luck on the interview.
Re:Around here... (Score:1)
i think i read as much as i needed to.. (Score:1)
My way is easier... (Score:2)
Re:You missed these (Score:1)
Instigate - depends on how, though.
also:
Investigate - that's why you are there (for the most part). Is this job for you?
Masticate - only if they offer you toffe...
Postulate - could be helpful, in some interview situations.
Relate - empathy is helpful, if your interviewer has a nervous breakdown.
aside from those... if you decided to mate right there... that would be a bad idea...
--
Re:Not how I handle it (Score:1)
Re:You missed these (Score:1)
Though you definitely have a point on that last line
-- Sig (120 chars) --
Your friendly neighborhood mIRC scripter.
maybe *you* are.. (Score:1)
like, you can memorize almost anything, but it doesn't mean you understand it. man, i should take some more english classes. i seem to have a hard time communicating my point within one post.
Huh?? Technical Questions vs. Behavior Based (Score:1)
Instead, most companies these days ask behavior based questions - describe a time when you've worked above and beyond, describe a time when you felt constrained by rules, those sorts of things. You may need to be a technical guru to advance, or to keep your job, but you rarely need to be one to get it.
Re:i think i read as much as i needed to.. (Score:1)
And check out Table 2.
There's more important stuff in there too...
Re:Beer ...? (Score:1)
[] golf
[] ass-kissing
[] swilling cheap american "beer' (read: Miller)
heck, it's Milwaukee, after all...
--
Re:maybe *you* are.. (Score:1)
Re:Luck (Score:1)
It's not luck, it's called Networking. (No, not the TCP/IP kind.) In this business it's all about who you know. The director of staffing at my current company is a guy a used to work for about 5 years ago. He called me up and told me that this was one I really needed to be involved with. He mentioned at the last company meeting that 71% of our hires are from internal referrals. This is after a regional add campaign that brought in a flood of resumes (several thousand).
This book is 90% crap. (Score:5)
List everything on your resume. Even if you've only experimented with it. If the job requires it, bone up on it before the interview if you need to. Recruiters are nothing more than buzzword parsers. If your resume says you're strong with korn shell programming, we can assume you know grep and regular expressions. But recruiters won't know this. If your resume doesn't say the actual word "grep" they'll pass you by. The first page of my resume is nothing more than a list of words (organized neatly).
I get a hard technical interview maybe 10% of the time. Don't worry about all the minor details of the tool they're using.
No one cares what you claim to know. They only care about what you have actual experience with. Most people count years, even though it's the worst way to measure skill. Therefore...
Intentionally take contracts that have tools you don't know or are weak in. Ideally, if they're asking for six different things, know five of them really well and be weak in the sixth. This is the only way to grow. Six months later, you'll have something else to add to your resume.
Don't fill out skills inventories. Just get up and leave.
Don't go on an interview with a consulting firm until they already have a specific contract lined up for you... unless you're just in it for the free lunch. :-)
Don't take salaried positions with consulting firms. If you want to be salaried, work direct. But then again, why take a 50% pay cut? Just be a consultant.
Don't get starry-eyed about the consulting firm being the biggest, best, or fastest something in some area. They all are. My favorite one is, "Let me tell you what makes us different from all the other consulting firms." :-P Talk about irony.
Don't work for (insert your Borg-like monster consulting firm here, i.e. Andersen, E&Y). And don't take contracts relating to them either... unless you want to achieve synergy with your incompetence intollerance matrix.
Sorry for the rant.
brian
Re:Some handy interview tips. (Score:1)
Yeah, but I can't think of the Latin word for "suck up".
--
Interview and hangover (Score:1)
Ah, this brings back memories of my second ever job interview.
I gave my best ever job interview performance once when I was still hungover from previous night's beer binge (yeah, I was young and stupid then). My hangover wasn't of the head-splitting/vomiting type but more like a comfortably numb-feeling. I was probably still slightly drunk.
I just had no fear or anxiety during the entire interview. I had no problems with problem solving and apparently my psychological test went all right as well, because I got the job.
Later on my boss told me that he had been especially impressed by my relaxed but yet professional performance during the stressful interview.
I won't recommend this to anyone, though.
Exactly (Score:2)
My interviews were at least half behavioral interviews to see how compatible I would be. The other half was technical but almost never at the syntax of a language level. Since I was rarely interviewing for a specific position I wasn't expected to know (nor did I consider trying to learn) every little detail of a language. I would be utterly shocked if companies expected new graduates to be experts in any language.
Anyways, maybe 1 in 10 technical questions was about C or Java or bash, etc. Mostly there were logic puzzles, design steps, and general system problems. What's the key here? They want problem solving skills. You can teach a history major to program (some companies do) but problem solving is a gift that not too many people have. The better and more quickly that you can break a problem apart and come up with a logical, clean, modular solution the more you will impress the interviewers. (Notable exceptions are places like Microsoft and many startups: expect to be *grilled* in the chosen language(s) at those comapnies).
I can't say enough that you should be yourself. In many cases you are interviewing with people who will be your manager or co-workers. To impress them is nice but to be "real" is much more important for your quality of life. If you don't like the people that interview you go elsewhere. You won't like the place.
Always ask what the interviews *dislike* about their company. If they can't say anything reasonable that they don't like they aren't being honest with you. It's not a mark against them unless they give a really whacked response, and it certainly shouldn't be a mark against you.
And I did find myself in the fortunate position of being able to literally take the pick of the litter among the places I applied to.
Re:Linked lists? (Score:1)
This seems like a pretty harsh statement. It has been my experience that the questions the interviewers ask is often more reflective of the interviewer than the company. I would say that, more importantly, you should find out which of these is true.
Of course, this changes from company to company. M$ is notorious for rough interviews.
point taken but... (Score:1)
however, i can't say i didn't get my _new_ job without a very nice recommendation from a current employee. but then again i've gotten several other job offers asking my to relocated, which i was willing to do... from companies who didn't know what i looked like, or who i knew. er..something.
You also missed... (Score:1)
Masturbate
Yes, but what if... (Score:2)
----
Re:point taken but... (Score:1)
Re:Around here... (Score:2)
Right now, H1's are tied to the current employer. This means that H1 employees can't switch jobs without getting a new H1. Also, if you're applying for a greencard, and you switch jobs, you need to restart the application process.
This results in foreign workers ("aliens" in INS terminology) having to undergo significnt hardship if they switch jobs. American high-tech companies end up having a preference for foreign workers because they know they can treat them like crap and pay them less, but they won't dare to quit. If foreign workers could easily change jobs, then the high-tech companies would be forced to pay them the same as Americans. This would be good for all workers ("aliens" and Americans).
The INS has actually created this problem. They try to put quotas and restrictions on alien workers, thinking that that will reduce the number of them. The restrictions on switching companies are exactly what the high-tech companies like about foreign workers over Americans though. I bet if those restrictions were removed, the H1 quota wouldn't even be reached (as it has been every year for the past few years).
Author's response (Score:5)
As one of the authors of Programming Interviews Exposed, there are a few things I thought I might respond to in the review and some of the early posts.
Dissection of point 1
I agree with Gavin's assessment of what knowledge is important. What we really meant is you need to know every quirky feature (even obscure ones) of the core language. For instance, you should be familiar with bitwise operators, even if you rarely use them in your programs. If you say you know C, you should know what a union is. It's certainly not necessary to be familiar with every library and technology that's ever been tacked onto the language.
Weaknesses
Component programming and I18N are both important topics. I do feel that in most cases, they fall into the "they won't ask you unless it's on your resume" category, but perhaps we'll be able to include some material on them in the next edition ;-)
Posts expressing discontent with the whole idea of being quizzed
I have to admit, I was more than a little put off the first time I was quizzed in an interview. However, I've come to understand that some amount of this is a necessary evil. Unfortunately, there are a large number of applicants who claim they can program, but, to be blunt, can't. I'm talking about people who claim to be "Senior Java Developers" and don't know how to declare a variable. Some of these folks can actually talk a reasonably good game, so it's very hard to screen them out without asking applicants some sort of programming questions.
A couple of people have mentioned that factual recall Trivial Pursuits-type questions doesn't really prove anything. I definitely agree with this, and I think most companies do, too: most of the questions I've faced have required intelligent application of a little knowledge everyone should have, rather than encyclopedic recall. I wouldn't want to work for a company that emphasized the latter kind of question.
All that said, I do think that there is too much emphasis on time-pressured puzzle-solving in most interviews. As I mentioned, some of this is useful to screen out fakers, but the real measure of a programmer is what he/she can do in a few weeks or months, not in 25 minutes. I think interviewers ought to spend more time asking about the applicant's experience and past projects. Nevertheless, right now most interviewers do focus on puzzle questions; we thought it would be most helpful to write a book to prepare people for interviews as they are rather than interviews as we wish they were.
Finally, a big thanks to Gavin Bong for taking the time to read and review our book.
John Mongan
ability to learn (Score:2)
Jobs -- getting experience & money (Score:2)
Internships are relatively easy to find via the university's career-center-like-dealie. (I don't know if they make those services available to students on leave, but it couldn't hurt to ask.) Make sure, if you decide to do an internship, that you have a mentor who will look out for you, who will direct interesting and challenging-yet-doable projects (from which you will learn) towards you, and with whom you get along. Without a mentor, you're just a cheap temp.
WUSTL? If you know Josh Brockman, say hello to him for me.
Re:Author's response (Score:3)
Re:Yes, but what if... (Score:2)
1: you have entirely the wrong idea about what constitutes expertise.
2: you have a promising career as a short order cook to look forward to.
If it's 1, then go forth and lie your ass off through a few interviews. The job you get will probably suck, but it's resume fodder.
If it's 2, go get sized for your apron and stop wasting money paying for college.
You are 90% crap (Score:2)
Yes, I work at one of that 10% of companies that actually asks techie questions in the interview. If you claim to know it, we will ask you about it. Whether or not we are interested in that skill. We don't care whether you know our skillset, we care that you can learn it. The simplest way to do that is to see how well you hve learned what else you said you knew.
If you listed stuff that you didn't learn, you might as well not show up.
And you know what? It is a lot more fun dealing with people with a clue than bullshit artists.
Regards,
Ben
Extremely good point (Score:2)
A person who can recognize and be up front on their ignorance is much more valuable than someone who tries to BS their way through.
Cheers,
Ben
Re:This author doesn't know how to land the cool j (Score:2)
Unless you're interviewing with the RIAA. :)
As an interviewer and an interviewee (Score:5)
IMO this is the ideal way to do an interview, and it's certainly the kind of interview I would want to be given. The only problem is, a lot of times the person giving the interview is not themselves a programmer, so the ability to establish a rapport with the interviewee is limited and they're forced to resort to standardized measures like quizzes or puzzles.
As an aside, my current new job - where I start next month - was landed the best way of all. I went to a training course given at the company's headquarters and immediately liked what I saw. It gave me three days to talk to everyone, go out to lunch with them, see how they worked and talked to each other, see their projects, etc. and of course they got to know me reasonably well also. I went away from the course feeling happy but not really expecting anything more to come from it; I was very pleased when a while later they expressed an interest in hiring me on. Needless to say, there was no real need for a technical interview at that point.
If only all "interviews" could be like that...
from the other side -- how to interview (Score:2)
--
Re:Luck (Score:2)
No, it's all about who knows you.
Re:not a 100% troll... (Score:3)
You're elluding to an important point - Computer Science is not programming.
Programming is a tool computer scientists use to prove theorems and demonstrate important principles, but to do computer science, one does not need to be able to program. In fact, many computer scientists don't know how to program at all (or very well).
The problem is that because the device you usually program on is a computer, people lump programming in with computer science. If you are taking a computer science program and you come out and can't program, you didn't take a bad program - you just took more pure computer science than others. No big deal.
CS is a subset of Programming, but the opposite inclusion is not true.
Woz
Re:Linked lists? (Score:2)
Networking for job satisfaction (Score:2)
This is the core of successful networking, in the older sense of personal networks. If you are comfortable with who you are. If you spend time with people who share your interests and can help you to expand them. If you convey a sense of what is important to you. Those things will give you an edge. The reason that networking works is that people are more comfortable with someone they know than someone they don't.
I've been on the other side of the interviewing desk. I've found myself saying things like, "They all three sounded good and looked good on paper, but who will I be able to work with." I'm glad that I was brought in to ask the technical questions in the inteviews and that I didn't have to make the hiring decisions.
Ask yourself a valuable question. Do you know people, outside your current company, who you would want to work with? Would they want to work with you? Those people are the start of your network.
Re:Around here... (Score:2)
You mean: Salaries in the DC area are unrealistically low for 19,000 unfilled positions.
What about non-technical questions? (Score:2)
Tree question:
answer 1. The kind that falls in the forest, so you don't know if it makes a sound or not.
answer 2. The one growing in Brooklyn.
answer 3. An aspen, 'cause the cologne smells good.
answer 4. One next to a house with a fast internet connection.
Weakness question:
This one gets fun, because half of the interviewers are looking for you to find a strength and spin it into a weakness. "I'm too dedicated to my job." Uh, right. Usually here, I just tell the truth:
1. I'm out of shape and I'm easily distracted. (absolutely true).
I had one guy interviewing me that this completely floored, because he was used to the
spun-strength answers. Of the 200+ people he had interviewed that year, I was the first one who had given an honest answer! I got the job, and a paycheck much larger that I asked for.
my $0.02
Matt
We are talking about different things (Score:2)
The fact that the average interviewer doesn't know what to look for isn't very interesting to me...
Cheers,
Ben
Reading your description... (Score:2)
BTW I would be seriously impressed if I gave an interview to you on my particular area of expertise (Perl) and you knew more than I did.
Once again, sitting on the other side of the table as someone who asks technical questions, I don't care one fig whether you know the toolset. If you can learn, then I can quickly teach you that. But I do not know how to teach people good judgement and a sense for fundamentals.
Cheers,
Ben
A few quick points (Score:2)
Let me pass on some things I've learned as a contractor.
Most initial screeners aren't very technical themselves so all they're doing is looking for certain words to appear on the resume. Don't make shit up, but don't hesitate to list a skill even if your knowledge in it isn't that impressive. Most programmers underestimate the number of skills/software they know.
If you can't immediately code through the problem given, there's two other things you can do that will greatly impress the interviewer.
The first is to demonstrate that you do indeed understand the complexity of the problem. Think aloud, showing that you see the roadblocks in front of you, even if you don't see exactly how to get around them. That's good enough in most circumstances. They just want to know that you know how to attack a problem.
The second thing you should do, when you're truely stumped, is simply say "I don't know." Don't gild yourself, don't make up excuses, don't show off...just say "I don't know how to do this." You'll be suprised at how much this can impress an interviewer.
Absolutely the worst thing you can do is stand in front of the whiteboard like an idiot, humming and hawing and trying to bullshit your way around a problem. This just wastes the interviewer's time which will almost always result you in not getting the job. Better to just admit immediately that you don't know how to do something.
The interviewer's next question will probably be "well, what would you do next?" What he wants to hear is that you know of several resources for the language in question so you can look up the right answer. What he doesn't want to hear is "Well, I guess I'd go ask you how to do it."
There is a huge demand for good programmers right now and obscene amounts of money floating around. Take advantage of it while it lasts.
The strangest thing about increasing your salary demands is that it makes it much easier to get a job. If you ask for $30 K, you're going to get grilled at the interview and you'll be suspicious to the interviewer, who is problably thinking, "If this guy is asking for 30K in this market, he must be useless". Ask for $80 K, and your technical skills will be more or less assumed and the interviewer will become more like a salesman, trying to convince you of the merits of working for his company. I know this sounds like total horseshit but I've experienced it personally.
Obviously you won't get away with this unless you really do know your shit. It's been my experience, though, that many hackers seriously underestimate their own market value. If you're the type of person that is compelled to learn new tech for its own sake, then the odds are you've learned far more than the guy that just got his CS degree because someone told him he could make a lot of money as a programmer. Don't sell yourself short.
Re:Author's response (Score:2)
When I left my former position, the requirements list that they published, in the advertising to fill my position, was ridiculous. I didn't meet half of their requirements. I couldn't have got my old job back even if I wanted to.
Do you know why they did this? Because policy dictated that they had to give opportunity to the general public regardless of whether they just wanted to promote someone from inside. They simply put someone they already had into the position I vacated, cicumventing due process.
Neat tactic :-\
-- kwashiorkor --
Leaps in Logic
should not be confused with
Re:What about non-technical questions? (Score:2)
How to get a cool job (part xxx) (Score:2)
Re:What about non-technical questions? (Score:2)
Actually, lots of procrastinators get hired. What usually happens though is they also get fired very quickly, (Unless their boss'-boss hired a procrastinator) so making it through the interview doesn't mean success, it just postpones the inevitable failure. The fact that someone tells me they are a procrastinator doesn't automatically mean that they won't get hired. I just know what to watch for. When someone answers with any of the cheesy responses I've seen and seems to be serious, I wouldn't hire them. They either think I'm a schmuck, or they don't have any weaknesses. I know the second part isn't true; the schmuck part's still up for debate.
Also, I strongly advocate working on your weaknesses so they are less of a weakness. Example: I am working out at least 4x a week which is helping with both of my 'greatest' weaknesses.
Another point. If the interviewer is expecting an honest answer, the follow-up is usually "What are you doing to correct that?" I have a reasonable and honest answer to that question also.
If the procrastinator has to answer that, it'll probably be "I'm going to get more self disciplined, but I haven't gotten around to it yet."
Matt
Re:Linked lists? (Score:2)
Re:Linked lists? (Score:2)
Depends on the company's culture; one interviewer looked at me quizzically when he asked me what dev environment I used, and I answered "emacs." He of course was expecting something like WebSphere (and I thought emacs was bloated), and it told me volumes about the company. They wanted people to know "methodologies" and such, things that sounded very sophisticated in business-speak, but could be possible crutches.
Still, interviewers in IT I've met are pretty damn openminded. When asked how I would deal with speeding up a database (I only know theory), I just said stuff like make data redundant (caching or not completely normalizing the data), connection pooling, looking for bottlenecks in general in the specific system and use. Those were not the answers they were expecting; my knowledge was purely theoretical and I've always had DB admins spoil me. But they knew that, and in any reasonable company there's someone abstracting it away for you.
To make a longwinded diatribe short, be honest, since they need you more than you need them. Don't fall for companies that expect you to memorize language features. And to interviewers: If you have to ask such a question, give them the language primitives to use or use pseudocode. You are not in control of the interview, because you need programmers to execute and yet they can work for many other companies. Be human, not an ass.
Re:Beer ...? (Score:3)
As long as we're in a seller's market, do what you damn well please. If they go ape over it, you will have just filtered out a place you didn't really want to work for.
--
True, but ... (Score:2)
However, I do think technical questions at interviews matter. Not necessarily the "How does this work in Java ?" type of questions (which are really just checks that you didn't exaggerate your knowledge on your CV), but problem solving and puzzles. Interviewers for really serious technical posts (not database grinding or HTML hacking) want to see your though processes and problem solving style, both to check that you really can do it, and to check that your "style" is compatible with "how we do it here". This can only be done at interview. On CVs, or over the phone, these things don't come through.
Importants of linked lists (Score:2)
I drilled some poor sod in a technical interview recently when he put "cryptography" as one of his skills. My first question was, "Which AES candidate do you prefer?" His response was "What's an AES?" at which point I knew he hadn't kept up with the field. Point being, if you say you have some skill, either qualify it, or make sure you're current in it.
From a technical point of view, I don't care if you're up on the minutiae of any particular programming language. Any decent programmer can learn a new language in a matter of weeks, especially if it is a language as simple as Python (which is what we use most at EST). What I do care about is whether you know basic object-oriented programming ideas and terminologies, basic structured programming concepts, etc. Beyond that, if you appear to be relatively bright, relatively well grounded in basic computer science, and either crazy enough or outgoing enough to deal with the crazies in our engineering department, we can't afford to be picky in today's labor market.
I can't stress the 'crazy enough or outgoing enough' bit. We got one guy, a very proper scientist type, who came in, who would never tell anybody hello, who would never say "bye" when he left, who never joined into the impromptu design discussions that happen whenever two people working on the same project run into each other in the hallway, who got upset whenever he, a junior programmer, did not get the senior programmers to do things his way, who seemed altogether uptight and tight-assed... he eventually, after we pulled him into a meeting and asked him to be a team player, turned in his letter of resignation, saying that the other programmers were hostile to him and he couldn't work with them. Oh well. But now you know why companies tend to trot candidates past the engineering department... we can't afford people who can't work with the nut cases who already work here :-).
-Eric Lee Green, Senior Software Engineer, Enhanced Software Technologies Inc.
Re:Some handy interview tips. (Score:2)
Except for acting jobs.
Re:Around here... (Score:2)
Because it's true. You think they like paying a premium in a market where the interviewee has the upper hand and feels he can take off for another company if he has a few bad days? This doesn't mean every company is hiring ignoramuses, most would rather leave the position unfilled than pay someone who can't do the job.
Market Yourself - Tips for High-Tech Consultants (Score:2)
Please read Market Yourself - Tips for High-Tech Consultants [goingware.com].
I'm a consultant, and I see a lot of other consultants out there groping for a clue. I also have lots of friends wandering in the dark trying to build a career.
I've been working as a programmer for thirteen years, and I've been an independent consultant for two and a half years. I do not do business with recruiters [goingware.com] - I find all my clients myself. The above page tells how I do it.
This is not spam. I'm serious!
Capture /flag at Apple (Score:2)
(Yes, Apple has always used Unix, I had a Sun 3/280 on my desk in 1990).
I got invited into the game after complaining long and loud at A/UX 2.0 wasn't living up to the CERT advisories [cert.org] during it's beta cycle.
I flunked "strcpy", got hired for tech support (Score:2)
"What is the most efficient implementation, written in C, of the standard library function strcpy?"
Well damn me, I wasn't able to answer this, and so I was put on technical support at six bucks an hour - graveyard shift, BTW, they offered 24 hour tech support.
If you want to see where I've come since check out my resume [goingware.com]