Programming Interviews Exposed
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
"I work cheap"
DrLunch.com The site that tells you what's for lunch!
Sugar, fat and caffeine make the world go round! The more, the better!
A feeling of having made the same mistake before: Deja Foobar
One thing that always helped me was knowing that they need you more than you need them, especially in todays' technical job market.
Link for 'publisher John Wiley & Sons' is broken. Please fix.
http://dtum.livejournal.com
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
air and light and time and space
No, the author is NOT justified in putting ANY specific programming information in. If the company asks me "can you implement a linked list in Java in 10 lines or less", then that's not a place I want to work.
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.
--
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
Beer in the fridge. Domestic and imported. Now that is a programming job I want to find.
Sometimes you by Force overwhelmed are.
I think it's important to realize that tech companies need good programmers more than good programmers need tech companies. There is no reason to subject oneself to a one-way anal probe. Push back!
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.
The real DunkPonch is user 215121. Everyone else is Bruce Perens.
...for being a good BS artist at times too. Granted this isn't always the best approach, but it can certainly help.
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.
For the last time, PIN Number and ATM Machine are redundancies!
If I were hiring technical staff here in the Boston area, there's one question I'd need to ask: "When was the last time you went to the MIT Flea Market?" If I get a blank look they'd be out of there...
There are plenty of American citizens skilled in programming looking for jobs. The software companies would like you to believe that there is a shortage of workers. Yeah right.
That reminds me of something. I'm going to graduate next spring, so I'll be interviewing fairly shortly. Anyway, my question is this: if the company takes you out to dinner, is it appropriate to order a beer?
Ask the Headhunter.
-- What you do today will cost you a day of your life.
Actually, quite recently the New York Times ran an article affirming the shortage of tech workers. There are fewer CS grads than there are new jobs created per year. Do the math.
You don't get it. The companies know that they can pay foreign workers less so they claim there's a shortage when there's not. If there really is a shortage, they need to start hiring in places like Ithaca, NY.
w0rk3d 4 m3
->mafiaboy
->mafiaboy
don't confuse political expression with vandalism
I suck at the whole job seeking process, not just interviewing.
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.
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.
I'm not weird, you're just all boring.
You might also want to check out this editorial at freshmeat (Negotiating for Nerds)
To get something done, a committee should consist of no more than three persons, two of them absent.
Every friday they truck in 8 - 10 cases, so at
any given time there is at least 2 cases in the
fridge. Nice selection too.
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.
"The Internet is made of cats."
...I think he invented something in the early seventies...but I can't remember what it is.
Treatment, not tyranny. End the drug war and free our American POWs.
See my user info for links.
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.
..don't panic
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.
I'm not weird, you're just all boring.
Gyrate
Debate
Delegate
Desecrate
Designate
Instigate
Investigate
Masticate
Probagate
Postulate
Relate
Dilate
Grate
Mate
However, it is OK for prospective porno actors to masturbate
that's the harder part really; you've got to be able to find companies you find suitable. Methods in doing this would be appreciated. I.E. in 1 year of being on boston.techies.com with a willingness to relocate, I've only gotten 1 email about something I found interesting, even with the very specific resume tool. and I get 2 or so a week. Also establishing what the job and company is about over the phone before an interview needs addressing. Sometimes a company will just ask you to come in without divulging much information, that's not helpful
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)
________________
I don't want free as in beer. I just want free beer.
There are plenty of people looking for programming jobs, who are unwilling to move or work on the things most companies need. There's a real shortage of people in the places where companies do development. There's also a real shortage of people willing to do anything other than Java and HTML. The DC Area, where I work, has a deficit of about 19000 developers (compared to the number of jobs) right now. This isn't conjecture; I've been a hiring manager/interviewer since '96, and I've seen the quality and quantity of interviewees steadily decrease.
Law is whatever is boldly asserted and plausibly maintained. -- Aaron Burr
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.
I'm not weird, you're just all boring.
Anyway, my question is this: if the company takes you out to dinner, is it appropriate to order a beer?
:-)
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.
Tell their sorry asses spread out around the country then. Like Ithaca, NY. I was applying for a full-time programming job, when they asked me what sort of salary I wanted I said $15k. End of that interview. $15k is high pay for Ithaca.
i read a good middle bulk of it, skimmed the whole thing (basically)... and i got the jist of what they were saying...and found ymself in disagreement. is this a suggestion for me to go back and read the whole damn thing in detail?
I'm not weird, you're just all boring.
I helped my boss's daughter in our C++ class and BOOM, I got a full time job writing Java Servlets for him :)
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.
I'm not weird, you're just all boring.
I've interviewed for a fair number (40+) of companies, and other than Veritas, no one's ever asked me anything truly technical. It may be because I've mostly worked for large companies, but even the small consulting shop I work for now was basically just fishing to see if I knew what the acronyms "EJB" and "CORBA" meant.
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.
Law is whatever is boldly asserted and plausibly maintained. -- Aaron Burr
Heck, if you are trying to get a job with GE Med Sales, you'll need to practice up on the following:
[] golf
[] ass-kissing
[] swilling cheap american "beer' (read: Miller)
heck, it's Milwaukee, after all...
--
"It's tough to be bilingual when you get hit in the head."
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
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.
At least from my personal experince (recent college graduate) this book probably wouldn't have helped at all.
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.
Fsck cluebie moderators. I'll say what I want, offtopic or not. And fsck having to qualify every bloody statement just
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.
I'm not weird, you're just all boring.
Masturbate
Attention all planets of the Solar Federation! We have assumed control! - Neil Peart
I find myself in the following situation. I've completed 2 years of my bachelors in Computer Science at Washington University. Due to school expenses and other personal reasons, I have decided to take a break from school and work full-time, perhaps finishing my degree taking night classes. I have some experience programming in C and Java (both in my classes and at two interships), but I am definitely still scratching the surface. Given that I don't have a degree (yet), and I'm still developing my programming skills, how can I go about finding a job that will give me further experience and moderate to decent pay? I cannot demonstrate expertise in a language. What should I emphasize? Anyone else find themself in a similar situation?
----
Celebrate the finer things in life
If you want to encourage American high-tech companies to hire Americans, here's what you should do: encourage the INS to allow people with H1B's to transfer to other companies. The same should be true for people who are applying for a greencard.
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).
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
Ive not read this book....however, my personal feeling is that any organization looking for people is in search of people that are willing to put forth the effort to identify problems and develop algorithms and produce the solutions...so the real challenge out there is to be a person that is or find a person that is willing to do whatever it takes to learn what needs to be done and then implement the appropriate algorithm...How many languages you know is a non issue...these days it is "What is the language of the week?" today it used to be c++, currently it seems to be java, next week M$ would like it to be C# ;-) What it all boils down to is being humble enough to realize that you dont have all the answers, admitting that, but that you are capable of developing the algorithms and producing the answers...Knowing where to look and acknowledging resources that you regularly use is always helpful...
so where am i going with this...its simple...its all about what you are capable of...College is evidence to employers of follow through, proving that you have learned how to learn...thats the most important quality in any employee...or employer for that matter....
end of rant...
if youre an unemployed web developer, offer to make "phatty" homepages for your friends.
if youre a c coder, write a linux app.
if youre a java coder, write a buncha javabeans.
having hard-coded to submit to an employer is a good thing.
being a young person, i had no problem taking a internship at my _current_ job. i was an intern for one summer..that next summer i transferred to a new private school... i became their sys&netadmin b/c of my "professional" experience in a "high secuirty environment". see, my internship was at a major finacnial company, where i worked with peoples credit and personal information on a mainframe database. not abusing the information that i had access to, along with me proven technical skills, convinced my computer teach/head of computer dept. to hire me (pay for half of my $20/yr - mind you this is still highschool - tuition bill) as a net&sysadmin.
this job at school landed me a new job that ill be starting in september as a sysadmin.
starting small works...quickly too. you just gotta build trust in people, thats all.
I'm not weird, you're just all boring.
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.
Ceterum censeo Microsoftam esse delendam.
-psxndc
The emacs religion: to be saved, control excess.
Are you serious?
Have you met people who really think that if you have a beer with your lunch, it's a sign that you're an alcoholic. When are you supposed to drink beer then? At home and alone after work?
-psxndc
The emacs religion: to be saved, control excess.
I'd add that if you get asked any question that has a factual or quantitative answer you can look up in a book then that is the answer you should give. "well I'll look that up in 'xxx' and let you know". The next thing I'd add about Big5 firms is that their tech interviews while rigorous, don't have any correlation to the job and dont' have any correlation to either the person asking you the questions or anyone's else's knowledge who works there. They open up a phone book sized list of questions and just read down the list.
I think it is...isn't it? oh its not? damnit. no, just kidding I agree.
okay boys and girls thats what we call a waste of bandwidth and hd space. i'll just go ahead and shoot myself in the foot now.
no really, i'm way too tired. ill just shut up...and close this dmaned webbrowser. nuff posting for the day.
I'm not weird, you're just all boring.
Goes like this -- "Can you spell 'C'?"
Its fine to ask someone a few tech questions or even have a basic knowledge survey but it is much more important to ask leading questions... such as "if you didnt know how would you find out?". "How would you deal with ".F /...
Honestly most of the people that I talk to are terrified... you got to get them past that. Because you could potentially be spending 8+hrs a day with this person 20 days a month. You had better like them and they had better like you.
---
Solaris/FreeBSD/Openstep/NeXTSTEP/Linux/ultrix/OS
--- I do not moderate.
On both sides of the table - you and them, is at joel.editthispage.com/stories/StoryReader$20
This guy knows what he's talking about.
Programmers generally wash out in the first two years. After that, they either become managers or buy a stump grinder and go into bidness for themselves. So there is a natural shortage of programmer with over 2 years experience.
I've been coding for 20 years. My advice; Screw the money, take the good job. Life's too short to prostitute your soul.
If you aren't part of the solution, there is good money to be made prolonging the problem
Equal pay for equal work, equal opportunity for everyone
-psxndc
The emacs religion: to be saved, control excess.
A couple of good ways I've seen interviewees impress the hell out of the interviewer is:
- The guy who brought a CD full of sample code he had written. The boss paid what the guy asked for on the spot.
- The web developer who had on their URL of their homepage on their resume so you could see the quality of their work
- The programmer who pointed out that their name was all over gnu utilities and that if the interviewer wanted to see how good a coder he was,
the interviewer could just download the source code.
One downside of this approach is that if the work you produce on the job is not of the same quality as what you used to impress them with, they will have no problems canning your ass! So don't even think about passing off someone elses work as your own.I don't ever want to work at a job where I have to fix what you broke, and I doubt I will have to.
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
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
People who go with what they think they know (but don't) are simply a hazard to your code-base.
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
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
Unless you're interviewing with the RIAA. :)
I'd rather have someone respond than be modded up.
And is that a bad thing?
In all seriousness, if they are those kind of people then I wouldn't want to work there.
(Note: I have never applied at a company that was large enough to have a HR department.)
---
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
In all seriousness, if they are those kind of people then I wouldn't want to work there.
For any price?
The more I'm paid, the more BS I'm willing to put up with. Life is full of trade offs.
I used to work for a consulting firm; I was the only consultant with my particular skill set (embedded and realtime programming) so when it came time to hire more programmers for that client it fell to me to interview them. I discovered that the best approach was to go down their resume item by item and just ask them either something about "how they did that" (if it was a project) or situations in which they "had used that" (if it was a skill). The best applicants were the ones who took it as a conversation, and we basically had a nice chat about that item, possibly going off into tangents where I got to find out more about their interests etc. I tended to emphasize things that I had some knowledge about, as that made it very easy to tell when someone didn't really know what they were talking about. I really hated having to pull out "the dreaded list of ten C questions", and if the interview degenerated to that level it was almost always the kiss of death.
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...
And the number #1 question is: Where's the good job?
Serious: Yes.
There are far less judgmental things than your beverage of choice that could cost you the job.
Bad table manners for instance.
All in all there are some very subtle things that go into choosing who to hire, everything counts.
--
send all spam to theotherwhitemeat@ropine.com
I'm always trying to get better at conducting interviews. The strategies that work for me:
* Ask them questions about work they've been doing recently. If it's a sizable project it should offer a wealth of technical and design problems that they had *better* be able to discuss in depth.
* I look for someone who can explain things clearly and completely, since this shows the kind of ordered thinking I want in a programmer. I've only met a *tiny* number of good engineers who couldn't fit this criteria.
* As them to write some code on the whiteboard. Even if it's not compilable-quality, I want to see a minimum level of fluency and confidence. A lot of people can't write well thought out code to save their skin!
* Puzzle questions (like the manhole cover qustion) tend to be kind of a waste of time. Instead, give them programming problems typical of your job. I'd rather see a good ability to break down problems into solveable chunks than mere knowledge of a language. Languages are easy to learn, problem decomposition isn't.
* If you get a lot of buzzwords, start probing hard. Most of the people I want to hire are good explainers and can explain things in english. People tend to throw a lot of buzzwords up as a cover for lack of knowledge.
* Look for confidence. It's very hard to maintain confidence over the course of a full interview unless you really believe you can cut the mustard.
* Interviewing junior engineers is different than interviewing experienced engineers.
the cheapest place I've found to buy computer books:
http://www.bookpool.com
They only sell tech-related books, but they're
always less than than Amazon, Barnes and Noble,
Fatbrain, etc...
Note I'm not affiliated with them in any way.
Ok, that's a good cultural tidbit to know, although the fact that drinking would not be approved during a job interview wasn't really that surprising. On the other hand, the "danger" of being suspected of alcoholism for having a beer was surprising. Amazing. I actually learnt something useful by reading Slashdot.
I personally don't mind having a beer or a glass of wine with my lunch (I weigh about 80 kg, so a small Danish beer in midst of all the food doesn't really hit me that hard), but I wouldn't drink during a formal, job related lunch either. Just to have an absolutely clear head.
Having an informal lunch with your buddies in the middle of your work day is another thing, though, as I learnt during the few years I spent working in Ireland. ;)
Actually, you can change employers under the H1B visa. The transfer takes around 90 days.
I wouldn't say drinking during lunch in the USA is completely wierd, but it isn't that common either. I have had many lunches at local breweries, of course my drinking habits depended on who is there (don't drink in front of the manager unless they do) and how much work i have (the more work the more beer ;)
Scuttlemonkey is a troll
Steve Magruder
Steve Magruder, Metro Foodist
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.
The net will not be what we demand, but what we make it. Build it well.
You mean: Salaries in the DC area are unrealistically low for 19,000 unfilled positions.
Such as 'If you were a tree, what kind of tree would you be?' or the ever popular 'What are your two biggest weaknesses[sp?]?' I've gotten both of these in technical interviews, and I usually use them to test the sense of humor of the interviewer.
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
You are thinking from the PoV of the person trying to get the job. I am thinking from the PoV of the person trying to fill the job.
The fact that the average interviewer doesn't know what to look for isn't very interesting to me...
Cheers,
Ben
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
I was strongly reminded of what I see a lot of people doing. Putting things on the resume that they were exposed to, don't know, and cannot answer questions on when asked.
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
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
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.
Hey!, I took that from the original script.
http://dtum.livejournal.com
What's Tannhauser?
http://dtum.livejournal.com
Blade Runner
http://dtum.livejournal.com
At my current job, to weed out the "Senior Programmer" wannabes from those that could really code, they give a VERY simple coding test:
Three methods, one little purpose, all wrapped in a single class.
As we are a Java shop, the test is in Java. You would be surprised at the number of people we talk to that seem really good on paper, and the initial interview, but flub the test, or just get up and leave.
Just to give you an idea, the test took me about 15 minutes to complete, compile, and demonstrate. Some people take a few hours and never even get close.
The purpose of the test is to separate those who can from those who can't, and to give a very rudimentary idea of the person's coding style. I think the approach is great, and would now do the same if I start my own company.
"We all do no end of feeling, and we mistake it for thinking." -Mark Twain
Deposit your resume on the root directory on a server at the NSA. Don't trash any files or do anything malicious, so you don't wind up in prison.
What you can do is seek a Software Test Engineer (or QA) position. These positions are not black box testing, they're more white box oriented (where you get to develop testing tools - quite cool actually, cause you actually develop something fast (ie. more than 100 lines of code a day, as opposed to 'regular' programmers who do 6-20 **tested** lines of code a day), since all code is for internal use only. That way you'll advance your programming skills faster by gaining valuable programming experience. These positions are usually open to people of your calibre and present an excellent stepping stone. Be prepared for a rude awakening in the modern IT industry. These days RAD tools make applications in a matter of days (weeks), so in the future greater emphasis will be on testing than on designing / programming. You might discover that a lot of developers convert to testers simply because there is less stress involved, for equal money. And its not a 'in' profession, so with skill you may reach a higher earning managerial position faster.
Revolution = Evolution
Your post is insightful and may spell employment suicide. In my experience, ( I have interviewed everywhere from 'consultant' partime work to employment for State senators.) I consistently behave with tact and candor. I am honest and do not stick to BTB answers. In every interview where I 'connected' with the interviewer, I got the job. Here is my conclusion: If your interviewer dictates a superficial interview, then give them superficiality.
Claatu, Verata, Nic---sig
The last time I was asked that was by an engineering manager. I replied "I think I would like to have your job". Three years later, I did.
. waterwingz
> if the company takes you out to dinner, is it appropriate to order a beer?
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.
--
Sheesh, evil *and* a jerk. -- Jade
Actually not that uncommon here in Denmark. In one larger company they had three drink wending machines in the canteen: 1 cola and 2 for beer. In the smaller ones it has usually been beer in the fridge, use at your discretion. Usually only domestic, though. At least Danish domestic, like Carlsberg and Tuborg, in a few variants...
In Murphy We Turst
Great timing on the review, /.
I just had my interview this afternoon for a Java coding job!
-Dexx
Feel the fear and do it anyway.
You're quite right that most of an interview depends on getting on with the interviewer. In fact, the importance of every second decreases exponentially as the interview goes on. Many interviewers will have decided whether they'll recommend hiring you or not before you even open your mouth. Indeed, quite a lot of training *to* interview (rather than be interviewed) involves learning to keep an open mind for as long as possible.
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.
Also the original script didn't have the voiceover and did have the dream sequence of course.
Skilled, or people who bought "Java for Dummies" and think they are skilled? I've been looking for people to work with me for 6 years now, and in that time I've found less than 10 who I've made offers to, even though I've always needed to hire lots more people. They way I explain it to our HR people is that I'm looking for people who know how to cook, not just follow a recipe. And you'll never find a cook by asking people how to make a sandwich. And if anyone says they have to ask quiz type questions, then they have no clue how to judge people. Give me 10 minutes with someone and I'll know if I'd want to work with them.
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.
Send mail here if you want to reach me.
To briefly summarize the article, there were a number of studies done on interviews. Videos were made of 30-minute interviews of college professors. These videos were then shown to persons who were asked to rate the professors. They then cut the videos down to about 30-seconds that showed nothing more than the professor walking into the room and shaking the interviewer's hand. These 30-second snippets were then rated. Finally, they cut the videos down to merely the two seconds of the handshake, and nothing else. Again, the professors were rated by viewers of those two seconds of videos.
What they found is that the ratings of the professors matched almost exactly the ratings given them by their students after a semester of study under those professors. The full videos, the 30-second clips, the 2-second clips -- it didn't matter. Even viewing a total stranger for no more than 2 seconds gave the reviewers the exact same impression received by students after viewing those professors for a whole semester.
The point, of course, is that we have a tendency to judge someone instantly, and then mold our subsequent experiences into that first impression.
The implication for job interviews, then, is obvious: Make a good first impression. Walk into the room with confidence, look the interviewer in the eye, give a firm handshake, etc. That will lay the foundation that will give you an edge.
It was a very interesting article, and well worth looking up.
Hallucinate
Desegregate
Mediate
Alleviate
Try not to hate
Love your mate
Don't suffocate on your own hate
Designate your love as fate
A one world state as human freight
The number eight
A white black state
A gentle trait
The broken crate
A heavy weight or just too late
Like pretty Kate have sex ornate
Now devastate
Appreciate
Depreciate
Fabricate
Emulate
The truth dilate
Special date
The animal we ate
Guilt debate
The edge serrate
A better rate
The youth irate
Deliberate
Fascinate
Deviate
Reinstate
Liberate
Too moderate
Recreate or detonate
Annihiliate
Atomic fate
Mediate
Clear the state
Activate
Now radiate
A perfect state
Food on plate
Gravitate the Earth's own weight
Designate your love as fate
At ninety-eight we all rotate
Hallucinate
Dessegregate
Mediate
Alleviate
Try not to hate
Love your mate
Don't suffocate on your own hate
Designate your love as fate
A one world state as human freight
The number eight
A white black state
A gentle trait
The broken crate
A heavy weight or just too late
Like pretty Kate have sex ornate
Now devastate
Appreciate
Depreciate
Fabricate
Emulate
The truth dilate
Special date
The animals we ate
Guilt debate
The edge serrate
A better rate
The youth irate
Deliberate
Fascinate
Deviate
Reinstate
Liberate
Liberate
Liberate
Liberate
Sax solo
Now 'scuse me while I kiss this guy...
--
This is not my sandwich.
Back in 1993 a friend of mine in Nashville was poking around looking for Clipper work here in Atlanta. He found out that UPS was reimplementing a small Summer '87 tool in 5.01, and the spec for the thing was almost an exact match for something he had written just for fun some weeks before. So here he was with an opportunity to make a quarter of a million dollars just for changing a dozen lines of code mostly relating to the banner page.
He dashed off a cover letter and a brief description of the program, put an executable and some sample data on a floppy and put the whole thing in an envelope and shipped it to UPS. Overnight.
Using Federal Express.
--
This is not my sandwich.
> The software companies would like you to believe that there is a shortage of workers
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.
I've finally had it: until slashdot gets article moderation, I am not coming back.
Mmmmnope, didn't think so. Look, son, if you're not willing to move, give it up. I can tell you that college towns are some of the worst places to find work, because slackers with degrees out the nether parts take all the jobs. Are you one of them?
I looked into the abyss, and the abyss looked into me--and we both winked.
So you work for a marketing company? I can't honestly say I have any skills in that. I prefer more technical fields such as math, physics, engineering, programming.
Please read Market Yourself - Tips for High-Tech Consultants.
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 - I find all my clients myself. The above page tells how I do it.
This is not spam. I'm serious!
-- Could you use my software consulting serv
(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 during it's beta cycle.
-- Could you use my software consulting serv
"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
-- Could you use my software consulting serv
Last I checked, even if you work for the worst-paying employer in town (Cornell University), you're still not ever going to find a programming job below, minimum, the $27k payband. You can easily make $50k from other employers. Which is low, yes, but not nearly as low as the FUD you're posting. 15k is 7.20 an hour. Even the traditionally low paid intern worker class makes more than that.
Spare us the whining and try picking up a Chronicle sometime. Or better yet, move to Boston, where the pickings are so much better.
You don't want to know how jobs from that Chronicle I applied to. I never even got a "sorry you're not hired" letter from any of them. I got denied jobs at minimum wage. My question has the job market drastily improved since early Summer '98 when I gave up at trying to get a job? If I couldn't get a minimum wage job with a HS diploma, 5s on several APs, 800s on 2 SAT IIs, there is something wrong with America.
Your dad? Hmmm.. So how many of these jobs go to people without connections? Although, you could be right, I only have considerable first-hand experience for anything within 40 miles of Ithaca in 1998, not Binghamton in 2000.
Where will you find the biggest management advantages in business?
You won't believe your eyes... Or your ears... Or anything else for that matter.
Because any way you look at it, one of the best places to build a management career is under the Golden Arches in a restaurant owned and operated by McDonald's Corporation or an independent McDonald's franchisee.
That's right, your neighborhood McDonald's. That billions and billions served "Did Somebody Say McDonald's?" McDonald's. Hard to believe? Keep reading.
A restaurant job with McDonald's Corporation or with one of our independent franchisees is one of the better kept management development secrets in the world. More than half of McDonald's Corporation executives and more than a third of McDonald's independent owner/operators started their careers in a McDonald's restaurant. What does that tell you about your chances to move up?
And that's just the beginning. McDonald's Corporation and McDonald's independent franchisees offer a world-renown management development program, including a chance to attend the college-accredited Hamburger University. A career path beginning in a company-owned or independently owned and operated McDonald's restaurant can take you as far as you want to go.
That's what restaurant jobs with McDonald's Corporation or an independent McDonald's franchisee are all about. You'll be encouraged to grow, learn and develop the broad-based skills you'll need to move up fast -- with McDonald's Corporation, an independent McDonald's franchisee, or almost any company in the world. Having such experience on your resume will open eyes, not to mention doors. It starts in a corporate-owned or independently owned and operated McDonald's restaurant. What comes next is up to you.
Do you think my 2 years of 6th grade education and 900 on 18 sections of the SAT 2's (I can't count gud, soree) will be enough?
Maybe if you dont mind working for a franchise built on recycled flesh you barbarian!
Join me or die! Can you do any less?
-Mr. Sparkle
(nt)
Beer with dinner is fine .. if it's one beer, with a meal. More then one beer can make things go downhill real fast.
Beer at lunch is a funny thing. I was taken to lunch a while back by a prospective employer. He ordered a beer and I decided to go for a soda instead. Oops. We got off on the wrong foot, and I kinda wished I'd been able to turn back the clock and have a beer instead.
I follow the beer with coffee to get back in shape for the afternoon or evening.
Don't go past one beer unless they've offered you a job and you've accepted. Then have one more.
Break a leg.