programming and human factors
by Jeff Atwood
I find it difficult to believe, but the reports keep pouring in via Twitter and email: many candidates who show up for programming job interviews can't program. At all. Consider this recent email from Mike Lin:
The article Why Can't Programmers... Program? changed the way I did interviews. I used to lead off by building rapport. That proved to be too time-consuming when, as you mentioned, the vast majority of candidates were simply non-technical. So I started leading off with technical questions. First progressing from easy to hard questions. Then I noticed I identified the rejects faster if I went the other way – hard questions first – so long as the hard questions were still in the "if you don't know this then you can't work here" category. Most of my interviews still took about twenty minutes, because tough questions take some time to answer and evaluate. But it was a big improvement over the rapport-building method; and it could be done over the phone.After reading your article, I started doing code interviews over the phone, using web meetings. My interview times were down to about 15 minutes each to identify people who just can't code— the vast majority.
I wrote that article in 2007, and I am stunned, but not entirely surprised, to hear that three years later "the vast majority" of so-called programmers who apply for a programming job interview are unable to write the smallest of programs. To be clear, hard is a relative term -- we're not talking about complicated, Google-style graduate computer science interview problems. This is extremely simple stuff we're asking candidates to do. And they can't. It's the equivalent of attempting to hire a truck driver and finding out that 90 percent of the job applicants can't find the gas pedal or the gear shift.
I agree, it's insane. But it happens every day, and is (apparently) an epidemic hiring problem in our industry.
You have to get to the simple technical interview questions immediately to screen out the legions of non-programming programmers. Screening over the telephone is a wise choice, as I've noted before. But screening over the internet is even better, and arguably more natural for code.
I still wasn't super-happy with having to start up the web meeting and making these guys share their desktops with me. I searched for other suitable tools for doing short "pen-and-paper" style coding interviews over the web, but I couldn't find any. So I did what any self-respecting programmer would do. I wrote one.Man, was it worth it! I schedule my initial technical screenings with job applicants in 15-minute blocks. I'm usually done in 5-10 minutes, sadly. I schedule an actual interview with them if they can at least write simple a 10-line program. That doesn't happen often, but at least I don't have to waste a whole lot of time anymore.
Mike adds a disclaimer that his homegrown coding interview tool isn't meant to show off his coding prowess. He needed a tool, so he wrote one -- and thoughtfully shared it with us. There might well be others out there; what online tools do you use to screen programmers?
Three years later, I'm still wondering: why do people who can't write a simple program even entertain the idea they can get jobs as working programmers? Clearly, some of them must be succeeding. Which means our industry-wide interviewing standards for programmers are woefully inadequate, and that's a disgrace. It's degrading to every working programmer.
At least bad programmers can be educated; non-programming programmers are not only hopeless but also cheapen the careers of everyone around them. They must be eradicated, starting with simple technical programming tests that should be a part of every programmer interview.
As a Software Engineering(Technology) Student in my first year, I can absolutely see why this is the case. I am 29 years old, returning to school for a career in something that I love to do.
The sad thing that I noticed was not that we completed one semester of programming and hadn't yet learned about classes/objects, but rather the fact that many people in the course were struggling so badly or not caring about the act of programming at all. Many people in the second semester got by simply by coping source code from others I am sure. If the colleges weren't businesses (thirsting over money like mad) they would have a 'pre-enrollment screening' which would move things along quicker during school, and produce better, more qualified graduates (capable of doing the jobs).
This assessment should be done at the college/university level - prior to enrolling. Weed out the ones who don't want to learn it.
Additionally, it might ge worth looking into adding a requirement for all applicants to have a minimum mark for Math and Programming. Or perhaps a form for them to fill out with a simple program prior to an interview.. Not saying that it's right for employers to have to go through this circus.. but on the other hand, not all of us are incompetent morons either.. :D
My favorite interview had me desperate to ask a programming question that one particular "expert" candidate could answer. After asking successively simpler questions, I ended up asking him to implement a while-loop using [drumroll] if and goto.
"Sure, that's easy!", he replied.
I offered the whiteboard marker. "Can you show me?"
"Of course!", he nodded, not moving to take the offered marker.
"Will you show me, now?"
"Sure, I could do that!" ... [pause]
"Please show me now." ... [pause]
"Well, no, I can't."
Here's the flip-side of all this, though. I love good programming interviews. Sure, there's only so much you can glean with these distilled and contrived programming problems. And yup, I've bombed some interviews that I smacked myself over later, and that I believe underestimated my true abilities. That said, answering puzzles like these for four to eight hours during a grueling day is my idea of a Good Time. Call me crazy, but isn't that why we've picked this career anyway?
Steve Hollasch on February 22, 2010 10:47 PMOK, from the comments I think we've established that we shouldn't give take home problems because people will cheat, and we shouldn't ask people to write code at the interview because they might be nervous. We shouldn't ask for code samples because code from their current job is proprietary, and not everyone has time to write code at home, because some people have real lives and shouldn't be penalized for it. We shouldn't ask mathy or algorithmic questions because those are irrelevant to 'real world' programming jobs. We shouldn't ask API or syntax questions because, hey that's just trivia and if I got the job I'd just look those up on google. We shouldn't ask puzzle questions because that's just the interviewer showing off. And of course we already knew that most resumes are tissues of lies, and nobody can give honest references anymore for fear of lawsuits. This should make for very short interviews since all we apparently all we can do is ask their name and what their favorite color is.
Is it so hard to grasp that there is no silver bullet in interviewing any more then there is in programing? Everything you try is going to make some good programmers look bad (false negatives) and some bad programmers look good (false positives). Job seekers would prefer tests that have few false negatives, but that doesn't matter. They aren't the ones giving the interviews. The employers are, and they, quite naturally, are going to favor tests that they hope have fewer false positives.
Charlesegrant on February 23, 2010 12:36 AMAnyone ever thought that the solution to all this might be to actually establish ourselves as a true programming industry? Meaning: just because you "know" C or PHP or Ruby or Perl or Java doesn't mean you can program. There should be certifications and licensure, just like there are for plumbers or architects or electricians, et al. Though, we'd all have to agree on some common standards for that to ever happen. But that'll never happen since we're all such cowboy coders at heart. ;)
Pennedav on February 23, 2010 12:38 AMI think this is another case of snobby programmers thinking they know so much. The problems mentioned are more suited to people who are 'programmable programmers' (code monkeys).
I'm a self taught programmer and keep seeing articles like this from experienced programmers who are just stepping on people who are trying to climb the ladder.
Crake on February 23, 2010 3:41 AMOh dear. This is a "the king is nude" situation, and most commenters are still looking for a patch. Could it be that most of these so-called programming positions do not actually involve, you know, writing program code? Maybe the industry can really go without real programming (algorithms and stuff), most of the time. Maybe all we need to do now is describe things (with a vocabulary we don't understand at all), not create them. But that is a good thing for an industry, isn't it?
I learn to program because I believed (and still do) that it is a craft that can't be domesticated. It is like writing: there is a publishing industry, but there isn't a "writing industry" (and that is quite refreshing in these web 3.0 days, isn't it?) Programming is writing, it implies having something to say.
Also, Check it out.
Aslemos on February 23, 2010 4:08 AM
Joseph Connolly wrote:
At any rate, I was asked in a phone interview the difference between a linked list and an array. The company does not do low level programming or code for mobile devices which would make the performance between the objects perceptible.
There's no need to do "Low-level programming" or "code for mobile devices", it's just needed that you have a lot of data to process. Use the obvious, wrong, strategy to extend your arrays as you accumulate more data and you'll end up with O(N^2) (n-squared) time complexity, where you'd same would be O(N) time complexity using linked lists. On the other hand, you'd then have trade-offs further down the processing chain, so it MAY be better to use one representation in one stage, then convert to another representation down the line.
As for "how many" the lots would be, I can't give you a hard answer, but if we're looking at 1500-2000 elements and the O(N) version takes 2 seconds, the O(N^2) version would be over an hour and that may be significant (it mnight also not matter, it depends on how frequently and under what conditions the code is run; if it's part of the annual balancing of the books, it might not matter, if it's code that runs every 3 hours, it probably matters a lot).
Vatine on February 23, 2010 4:18 AMThe worst\best answer I've ever got to the question: "What languages do you program in?"
"English"
It turned out he couldn't even name a language. Not one.
I've given up on hiring. It just is not worth the aggravation and anyway, the amount of time spent hiring, I could do the entire job twice myself.
Now, if somebody becomes available, it's like an auction. Basically. I no longer hire people I've not heard of or who does not have a direct reference from someone I know who is a programmer themselves.
Brian Vos on February 23, 2010 4:31 AMAs a SharePoint consultant with 40 years in IT (yeah I have coded in COBOL, so get over it already), my interview technique is pretty simple.
I ask the interviewee to give me a detailed description of their SharePoint experience.
Then I might intersperse more detailed questions during their dialog. I figure if you can't tell me exactly what you have done, then you actually haven't done it.
One problem with ALL technical interviews is that you can always find obscure questions with equally obscure answers to either eliminate a candidate or throw them off of their interview game.
So allow the candidate to tell their own story and make your judgement from that.
Props to Mike Lin for his positive and sharing attitude.
Way to go, Mike :)
I am an Oracle DBA.
I do not have a CS degree.
I can answer most of these programming questions. Well I can answer all the coding ones. May not always be the best code or in C ( I have not used C in 10 years)
That being said, I have no idea what the answer to the hexadecimal one is ,but I can google it in 5 minutes. When would I use hexadecimal given what I do?
About the one where you change what you print out based on base 3 or base 5. I know you use modulus for this. However, this is the kind of thing that would slip out of my head some times, since I rarely use modulus when I script or code. So it is easy for me to forget.
Ryang5000 on February 23, 2010 6:21 AMLicensing is definitely not the answer. Unless the question is how do you kill the interesting and energetic world of software development.
Jason Butler on February 23, 2010 6:44 AMIf it's so hard to find someone who can write ten lines of code, why does every job interview I see declare that they're not interested in me unless I have years of exerience in each of a half-dozen specialized tools and APIs?
As for the least common multiple problem, would you expect an efficient solution that computes prime factors, or would it suffice to write the following?
int leastCommonMultiple(int n1, int n2) {
return lcmHelper(1, n1, n2)
}
int lcmHelper(n, n1, n2) {
return (n%n1 == 0 && n%n2 == 0) ? n : lcmHelper(n+1, n1, n2);
}
It is interesting to me that most of the interview questions are write a quick program to do solve some silly math problem.
It shows math skills, not software engineering skills. It does not show you how well someone will do OO analysis and design or OO programming. You need to present a problem that forces the applicant to use the features of the language that you use in your daily programming (e.g., inheritance, polymorphism, etc.).
It is much harder to piece together solid interview questions than it is to simply say write some code that generates primes or reverses a string, but is necessary if you really want to find out if the applicant can do the job.
You may end up hiring someone who is good at math, but writes procedural spaghetti code.
Jerry TheCat on February 23, 2010 10:19 AMI found that an effective way to interview programmers (back before we had screen sharing) was to ask them to bring a program they wrote, and explain to me what it did. Then, I ask them what problem they were trying to solve, and ask about some other ways to solve it.
It's amazing how many people I interviewed, who brought in sample code that someone ELSE must have written, because they couldn't tell me what it did. :)
-- Anca
Techliminal on February 23, 2010 10:20 AMI am an awesome programmer, when using actual programming tools. You know, vi on a terminal. I find that programming over a phone or a white board is pretty useless to me. For instance, I just copy and paste skeleton projects and fill in the blanks to do programming tasks. In dozens of scripting and programming languages. So I don't remember syntax usually for a language without the hints provided by the skeleton modules.
I actually had one guy ask me to write out the program to do the Fibonacci sequence... without telling me what that was. Sure, I had done it before, back in 1989 in college. He seemed very disappointed that I didn't know what that was off the top of my head and quickly terminated the phone call, despite the job being for messaging, which I was prepared to discuss/program in excruciating detail.
James Rogers on February 23, 2010 10:42 AMIt's been said that "Googling" answers is frowned upon because the programmer never attempts to understand it. I'm quite the opposite.
Just for the hell of it I googled a Sudoku Solver written in C to better understand how backtracking worked.
Also as a side project, I was writing a small imageboard, I needed a thumbnailer so I found an open source implementation and I only needed to set about 4 lines to configure it, but instead I found myself tinkering with the code for a few hours.
The thing is, being self-taught and going through community college right now doesn't leave me in a good position to answer these "tough as nails" interview questions.
Not everyone who uses Google is completely unwilling to learn and understand the answers. They just don't have a large library of coding books or a wealth of knowledge gained from a 4-year university to fall back on.
I don't think Googling the answer is a bad thing. As long as you're learning and applying what you learn, and not simply dropping in the code.
Macmnc on February 23, 2010 10:56 AM@Paul Jungwirth
Hughdbrown on February 23, 2010 11:21 AM
def generate_expr(s):
if len(s):
yield s
for i in range(1, len(s)):
left = s[:i]
right = s[i:]
for r in generate_expr(right):
yield left + '+' + r
yield left + '*' + rif __name__ == '__main__':
print set(expr for expr in generate_expr("123456789") if eval(expr) == 2002)
mind-numbing jobs attract mind-numbing candidates. nothing new here.
64bitandchew on February 23, 2010 12:10 PMI'd like to plug my website, http://collabedit.com, it's a collaborative text editor with syntax highlighting.
Where I work our phone interview consists of about 20 multiple choice questions covering basic concepts like algorithms, recursion, databases, OOP, etc.
We also like to have them write code on the phone using collabedit.
Bennoland on February 23, 2010 12:21 PMIt is important to ask a very simple question, one so easy that if the person is nervous, a novice, or just even just low on caffeine they can still answer it. A good warm up is to show them some dead simple code and ask for the output, make the syntax extremely simple, there is no need to get into pointers or recursion. You are just trying to screen out people that can't and never will be able to program. It will be at least half of the people that apply.
RealZenfar on February 23, 2010 12:49 PMI think that a lot of these interview questions that are drilled down and are so specific (i.e - prime number function, etc) are great to get an overall picture of someone, but it shouldn't be THE deciding factor. I would think that a more of a "How would you approach this situation?" type questions would be more suitable. The applicant would be able to use more tools in their toolbox than just a loop pseudo-code and some math.
To the people that are just graduating and complain that you've got the resources/knowledge to code, you just have done it yet -- that's your own fault. It only takes a few days in an intro Java class in college to realize that you aren't going to get much coding experience in college outside the coding you choose to do on your own for fun.
Taylor Pickard on February 23, 2010 1:00 PMI believe the author belongs to mars or some outer space. As, clearly he is not aware of the IT industry. asking about Why Can't Programmers... Program?? The question has a tiny answer - because they are the product of IT industry. Software doesnt build ONLY by coding and programmers neednt do coding all the time they work.
199 out of 200 cannot answer the questions?? But dont you think that the rest of 199 are also working somewhere. And most probably they are working well.And i can bet many (MANY) of them can beat the hiring technical guy who rejects them by asking there own versions of remembered TINY puzzles to him just like the hiring guy asks him.
All programmers will program when there will be quality work available to sharpen there skills. In 4 years of experience a guy actual programs 30-40 percent of his time. In that too 90 percent of work is dealt with for and if else. From where the competency will come? and from where the rocket scientists will born to satisfy hiring manager's hunger?
As someone else has correctly put in his comment - you can always learn to pass interview tests of any kind - that doesn't mean you can program or not.
What about a common example about it. Which company is famous for its puzzle problem questions and very feared about not to hire any wrong guy? The Microsoft. We have even books for its puzzles of interview(How to move mount Fuji).
But please ask yourself which company has given us most bugs, security flaws and crashed systems?(if u dont remember recent IE flaw used by hackers).
And who has written all those buggy code if not the ones hired by their strict hiring measures??
My fellow programmers, despite your 10+ years of experience, your reactions are almost childish when you fail to recognize that the world around you is evolving. It may be scary, but this frustration you are experiencing is a side-effect to all that cool stuff that we developed to make our lives easier. We refused to write the same code twice, we complained about the tools, created new frameworks, controls, plugins, intellisense, code snippets so that we would never ever have to deal with those crappy pointers again. So don't be shocked if this drag-and-drop programmers never needed to write any code to make a dumb form. Blame it on Microsoft, whatever.
But think about it. What was the last time you had to implement a linked list? Do you want this change to stop? Would you really want to be back to writing assembly language, or are you ready to live with the side-effects of making programming easier?
Now... worrying that they will steal your jobs?! You, as competent programmers should instead feel confident, that while those non-programmers will be doing the easy copy+paste work, you have the chance to worry about real, hard problems to solve.
I am of totally mixed feelings regarding this entire subject. I realized just the other day that I am coming up on my tenth year as a programmer, having started at 18.
I have conducted only a handful of interviews myself and I usually try and find out if the candidate actually likes programming. So I ask questions about what cool new things they learned recently, stuff they never used before, how it was used. What the last interesting chunk of code they wrote was, why it was cool, how it helped in their job. Stuff like that.
The thing that bothers me and has bothered me for a while, is that I probably couldn't answer any of the questions posted here. I don't remember how most internal compiler stuff works anymore. I don't ever have to do any complicated math so I wouldn't remember any of that. And I worked with 3-4 different languages on any given quarter.. so I usually need to refresh my memory on the exact syntax of certain things every time I started a new project.
Does this make me a non programming programmer?
By the definitions above it might.
I would say that finding out if someone has the mind for problem solving is definitely important.
Knowledge of concepts is also pretty key (control statements, loops, recursion, inheritance, things like that). (I've talked to someone that couldn't understand why having 2 else statements in 1 if statement was a problem before...)
In addition to that I definitely think you need people that actually like programming, people that write a function or solve a problem and fire off an email asking for a code review. People that actually brag to their peers about the sweet design they came up with to solve integration problems.
Lastly, people that know how to develop maintainable code. You can write all the super complex math functions you want, or you can tell me exactly what the compiler is doing with memory. But if you produce code / design that causes a cascade of bugs every time a revision is made or code that requires changes in 300 projects across 5 applications for the same revision, then no one is going to want to work on your code.
Things like that.
A bunch of the posters have hit the nail on the head. Like, when was the last time you connected to an SQL server database in C??? Have you ever tried without using a wrapped library? I would describe it as horrible and... gross feeling.
Alex at the daily wtf had some things to say about that a while back but I cant find the post. The point was that most of us write boring code, most of the IT world is employed to do boring things for banks and insurance companies.
So if you have heard the words "Oh, and we need it to have reporting!!" as many times as I have you really wont care too much about how all the lower level calls work, you will care more about how long its going to take you to write the code, how hard it will be to maintain for 10 years to come and how hard it will be to integrate with your other systems.
blastomite on February 23, 2010 8:40 PM"I was asked in a phone interview the difference between a linked list and an array. The company does not do low level programming or code for mobile devices which would make the performance between the objects perceptible."
Unless they only ever work with small amounts of data in a high-level language, all programmers should understand the difference between an array and a linked list. It's almost akin to a carpenter knowing the advantages and disadvantages of nails versus screws. There are plenty of software creation activities where understanding how to use a hash table aren't important, but they shouldn't have Programmer or Software Engineer in the job title.
A surprising number of recent CS graduates have trouble writing a program. There's a tendency for CS classes to focus on theory more than practice. Algorithms classes, for instance, will often provide skeleton code so the student just needs to fill in the algorithm's implementation, because that's the important piece for that class. And at a first pass that's good: more of my software engineering worth comes from learning about computability and context-free grammars than comes from chasing leaky pointers in my freshman year. But I'm very glad that my program requires all students to participate in an actual software development project (sponsored by and in communication with local companies).
In case any CS students are reading this comment, here are my key tips:
* Know one language well. Use it to do math, manipulate strings, handle collections of data, read and write input (from standard in and standard out, if possible).
* Write simple but real programs. If you've got a repetitive task, write a small program to do it. You'll quickly learn the quirks and bookkeeping that aren't theoretically interesting but are critical for getting things to work.
* Learn a few tricks about your development environment, from IDE shortcuts to text-processing functions in vim/emacs. If you're interested in professional software development, these instincts will pay dividends.
* Learn why things work the way they do. When you use a utility function, think about how you might implement it. Then look at the source code to see how the library designers decided to do it. (They're usually pretty good.) Don't get worried if you don't understand something yet; there's a lot of "It just works that way" until you learn more.
* Program outside of school. Internships, ACM programming challenges, fun projects with friends, whatever. Just like students in music school should play their instrument beyond what's required for class, computer science students should program for fun and profit.* If you can't seem to get the hang of programming, assess your interests. There are lots of ways to be involved in software development without writing code. Quality assurance, user interface design, project management, system administration...
To folks commenting about the relative merits of algorithmic questions versus solving business programs:
Your interview should test the skills you need at your company. If you're applying for a job at my company, you need to know how to work out a solution to a novel problem, so an algorithmic question is great. If your company needs people that can create Visual Basic forms to call COM objects, create a simple one and have interviewees pop up a dialog with the result of a method call. I'd probably struggle in the latter interview, which is good for both of us: I don't want to work with VB and you wouldn't like the way I'd try to solve problems. The principle in both cases is the same: quickly reject anyone who can't do the work that, in your company, is really basic.
Of course, you need to decide how much of a learning curve you can handle. When I created a "take home" programming interview problem, I let candidates do it in whatever language they wanted because it's easier to teach a good programmer a new language than teach someone who knows a language how to program. But if you want someone who can complete the VB project in three months for a big client, you may not be happy with someone who's spent his time writing UNIX device drivers.
Flwyd on February 23, 2010 10:53 PMPerhaps one problem is that there are several articles on the internet ALWAYS stating that one of the top 5 best paying "hot" jobs right now (especially in this bad economy) is the "Software Engineer." Of course people are going to be drawn into thinking they can program when they can't.
Another problem is that colleges do not ever train programmers to drill themselves on answering simple coding questions. It's more about passing exams and learning theory. Most coding done in college is for assignments and projects that the students have one to several weeks to work on (with books, notes, etc.). When is a budding programmer ever trained to practice these interview-style questions from memory? I think part of this "epidemic" is due to lack of practice.
Devin Hall on February 24, 2010 5:08 AM"Google-style graduate computer science interview problems" are not the kinds of problems that a working programmer in business will ever encounter. Fortunately I live in podunk PA so I only have to be more competent than an Amish programmer.
Robert Robbins on February 24, 2010 6:37 AMTo people who say that in their many years of programming experience they have never needed to use recursion/linked lists/sorting algorithms/loops/arithmetic/etc., implying that those things don't matter:
The charitable explanation is that you really understand these things and when to use them, but were "lucky" that they weren't necessary for your job. If that's the case, good for you, because you won't have any trouble if someone asks you at an interview.
The less charitable explanation is that you really don't grok what these things are or when to use them, and in all your years of experience missed plenty of opportunities to used them to produce a better solution to a programming problem. And believe me, this happens. I've seen code by coworkers who apparently didn't quite get the idea of loops and arrays. The code "works" but is an unmaintainable mess. Or code that performs very poorly because someone didn't have a clue about the different performance characteristics of arrays vs linked lists (or more likely had no idea about the existence of the latter).
Good programmers have a good toolbox of programming techniques, algorithms, and basic logic; they are always eager to learn and improve their toolbox and are constantly thinking of better ways of using the best tool for the task at hand.
itub on February 24, 2010 6:44 AMI find these pompous posts from interviewers HILARIOUS! Sure, there should be some coding questions, but not to the point of mathematical riddles (12...9 to equal 2002? Give me a freaking break!).
Lots of people code by Googling. The purists would frown on that, but that's the way of the world. You don't reinvent the wheel when someone else has done it. The more an 'expert' you become, the more you realize how much you have to learn.
So, keep patting yourselves on the back, chuckling at the way you slam candidates with mind bending mathematical questions. While you are in your tiny cube doing the same monotonous thing over and over, the candidate you happily smacked down have probably written some iPhone apps already and earning twice as much as you.
EGO limits your world.
Doug Bortt on February 24, 2010 7:22 AMI am a computer science student. This blog and the comments by the recruiters have really surprised me. If this blog (and the comments) is anything close to reality, I highly recommend very recruiter in the country to come to IUPUI ( www.cs.iupui.edu ) for on campus recruiting. Most of the CS students at my university would easily be able to solves the coding problems described here. I promise, it would not be a waste of your time.
Diviyansh Bhatnagar on February 24, 2010 9:32 AM@Paul Jungwirth
Well for reference there are 2 solutions for 2001 if you include '-' minus sign.
one main reason i see, lot of people without computer science degree are into Programming. Well yes there are some very bright programmers who learnt the basics out of curiosity but most did not. if they had the ground work , then i think most prob'ly they won't be bad. we don't have Doctors who studied Physics, then why we have a chemical engineer doing programming ?
Prakash Gomathinayagam on February 24, 2010 2:13 PMI'm a freshman CS/Math double major, and I definitely agree with Jeff here. I've been coding for just over a year, and I found the 123456789 problem to be relatively easy(it took me about thirty minutes to work out in VBasic). It seems like CS graduates really shouldn't struggle with those kinds of problems.
Unfortunately, my upperclassman friends confirmed that most programming classes are 90% theory and 10% coding... Which is why I take it upon myself to write new code as much as possible. Every once in a while, I'll write a completely random script just to make sure programming becomes second nature. (Example: last week, I wrote a Sudoku solver, and the week before that I coded Minesweeper.)
Of course, no job would ever require you to code something trivial, but I still think that anyone who's applying for a general programming position should be able to do so, even if they only use pseudocode. Not being able to print the nth Fibonacci number is just embarrassing, especially if the math part is explained to you.
Jonathan Baker on February 24, 2010 9:09 PM@Murray Macchio IMHO if people don't know how to program, they definitely can't rate themselves. But I was asked this kind of questions sometimes, and it feel strange to answer something like "uuuh, this tech I don't know, something between 2 and 3 perhaps", but that's honesty to yourself and recruiter.
@Mikeash I agreed, that's not what we expect from a programmer. If he can answer this question by oral during the interview, he's damn smart and would probably make a really good programmer.
In that sort of questions, out-of-school engineers are most likely to find an answer, but exeprienced programmer could stuck on it because they are not used to think on purely mathematical problems like this one.
It seems that in Europe, and in France actually, we do not have such sort of recruitement issues. It happens, but I think less than 25% percent of applicants. That's why we filter them through their experience and references. As programming jobs is in general not so well paid and recognized here, and require strong skills, people tends to target other jobs (PM, consulting, or sales in computing field for instance).
Benoit Montuelle on February 25, 2010 12:34 AMI agree with the article but disagree. My background I did a Bachelor of Engineering in Engineering Geotechnics(basically a cross between geology and civil engineering) after 4 years of Uni 5 years doing the job I decided to go back to Uni and do a 1 year IT course. To get my first IT job the employer knew they were recruiting mainly non programmers, thus we all went through a long programming aptitude test to see if we could at least think like a programmer and produce pseudo code snippets to questions.
In the 10 years I have now been working in IT of have done pretty well for myself. I am not a brilliant algorithmic programmer but I can do all basics in my chosen language of Java (I am SCJP and SCWCD but just certs that can be crammed), I would call myself a alright coder thanks to my Google search skills and my focus on quality and being professional. I have coded and delivered many successful J2EE applications, but this is less about lots of algorithms but more about plumbing together frameworks with some business logic. I have worked with some very good people including some exceptional programmers that put my programming skills to shame. But writing small algorithms as a tiny part of a modern day senior developer in large businesses these days. So why have I done so well for myself? I spend many hours a week reading about many things in programming especially good design an coding principles and practices and have always been vocal in pushing these practices into the teams I have managed. I also make sure I work in teams that have smarter people than me so I learn. I have also developed my communication skills and tried to break down the barrier between geeky developers and the business. Being able to write algorithms is great but not the be all end all list of the skills a modern day developer must have. Give me a mediocre programmer that has read some Bob Martin (and other) books, has a passion for continuous improvement, can talk to the business and project managers and understand coding is all but a small part of delivering a successful software project. Rather than a great algorithmic programmer that sits with his headphones on and does not communicate. But hey his code is amazing, shame he is the only one that can understand it let alone the poor badly paid support team. I have seen too many times the mess that is left behind when great programmers have hacked a program together.
There is a place for all kinds of programmers in our industry we just need to stop thinking that everyone needs to be superstars. Know your own and those around you strengths and weaknesses and work with it. Why are very good technical people pushed into team leader position or architect positions if they do not have good communication skills?
All that said if you are going for a job as a low to medium grade programmer role you should know the basics of the your primary language and at least be able to produce basic pseudo code for logic problems.
Paul Grove on February 25, 2010 1:07 AMAll those people whining about the questions being irrelevant to your profession - you are the problem! For the sake of humanity, please go into some field that better fits your interests and capabilities, like taxidermy or landscape architecture.
PixyMisa on February 25, 2010 2:53 AMWould you expect an aerospace engineering to be able to fly a plan? No, but he should no the principles of flight.
Would you expect a civil engineer to be able to drive a digger? No, but you would expect him to know how deep a hole can be dug without it collapsing.
Would you expect a senior software engineer how to implement a specific algorithm in language x? No but you would hope he knew the fundamental principles and practices of how to produce we designed and quality systems. If he can still dip into code all well and good.
Would you expect a programmer to be able to program. Yes
Lets not forget their are lots of different roles and responsibilities in large software projects not everyone needs to be the best programmer.
That's all my point is.
PixyMisa - If you think I have a problem, well that's your opinion, but not one that I fully agree with :-p
Would you expect a senior software engineer how to implement a specific algorithm in language x?
Yes. Hell yes. Never mind senior software engineer, I'd expect that of a junior programmer.
I wouldn't expect someone to implement a flawless C++ quicksort on the spot, but I'd certainly expect them to be able to sketch out a decent sort algorithm (any of quick, heap, shell or merge sort), and know that it's better than bubble sort and why. I don't expect programmers to be writing their own sort routines very often - if they're doing that, there's something wrong - but I do expect them to know how sorting works and what the costs are, that there are different ways to sort data, that the different algorithms have different costs and characteristics.
If you can't do that, you're the problem. If you don't think it's necessary, you're even more the problem.
PixyMisa on February 25, 2010 4:44 AMI know there are different sort algorithms and there are pros and cons on each but could I off the top of my head sketch out an implementation for each algorithm probably not.
Yes I would expect a coder who is having to write a sort algorithm would know how to do it. Even better know of an existing framework to do the required sort algorithm.
But if I had to review some code I would ask myself what are the requirements, and it was sorting then I would make sure I re-acquainted myself with the finer details of sort algorithms in the language I was reviewing.
So maybe we have similar viewpoints just at at different ends of the scale?
I can think of few reasons.
1) There is a heavy demand for Programmers. unlike other professions, every field right now needs Programmers. Supply can not match up with it. It is not easy to find good programmers, as they are mostly already taken up by big instutions.
2) Scope of programming is increasing exponentially. Most of the people are good in one technology and they just learn that without learning computer science and become programmers. My friends who studied Electrical Engieering, have done few c programs - thats it. They did not get job in their field. many of them did a crash course on MQ Series and landed on Job. they could know most of the MQ Series and they would think they are programmers but when you ask them simple algorithm questions or from Java or Perl they would blink. Only who have the bredth knowledge and can dive into depth can ammuse you. we have lot of silos.
Early on in these comments was a fellow who had a lot of IT experience and wanted to move into programming. He asked how to get an interview. The first problem is the folks who get payed 40k+ to do string matching between resumes and job descriptions (90% of HR... there are a *few* who know what they are doing, but only a few). Once you get past them your second hurdle is to convince someone of the following things:
1. You can write code
2. You will listen and work *with* a team.
3. You have the mental firepower necessary to improve and for listening to do some good.
Those are the basic requisites for an entry level position. 2 and 3 are probably something to be determined from your past experience (were you the solo IT guy at a small firm, or did you work as part of a team, moving from entry level to supervisor etc.
The best way to address #1 is (are you ready for this?) Write some code!
If you can include a link to code you've written in the resume, it will help a lot. Every technical person will unable to resist checking out your actual code. (though they may reserve judgment on whether or not it's actually yours).
It's key that the code is NOT just some example from a book or one of the mini-problems that people use in interviews. You should pick something you want done, and write a program that does it. (in my case, before my first job I wrote a mostly functional Java Swing Application that acted as a board for playing my favorite board game, including rules enforcement).
Another, even more powerful alternative is to find an open source project that you like that is written in a relevant language, and check out the source code. Then go look at the bug tracker and try to find something that looks small and simple. Go see if you can solve it. When you have, join the dev-list, and send a message saying you think you have a fix for bug #whatever, and you would like to know the best way to submit it.
Do what the folks on the dev list ask of you, and be prepared for the very likely event that they will ask you to change something. Do it willingly and politely, and try to make sure you understand why they want you to change things. Submissions to open source projects are a great way to both learn to work in programming groups, and to demonstrate programming that is not a trivial exercise. Put links to the bugs you fixed, or features you implemented in your resume, PLUS links to your interaction with the dev list (these are usually archived on the web somewhere). The interaction should be with the same email that you use on your resume so that there is no dobut that it is actually you. I did this with Apache Ant, and I learned a LOT (that's where I heard of books like Pragmatic Programmer and Effective Java), and it helped me get into the industry. As a bonus, I get the gratification of knowing that most of the people who interview me probably are already using my code :).
So if you want to get a job writing code, you shouldn't wait for the job to start writing code. And if that sounds like work and not like fun, maybe writing code isn't for you?
Gus on February 25, 2010 11:14 AMAs a side note, if you interview somewhere and they don't ask you to write code in the interview... think twice about working there. You are unlikely to be working with folks from whom you want to be learning.
Gus on February 25, 2010 11:27 AMOh, people, just remembering old book "Hackers - Heroes of the computer revolution". People who made computers and a lot of discoveries in the programming field were not a programmers! Do you know why? It's not important to do this job and other one!
Maxim Welikobratov on February 25, 2010 1:10 PMBut you don't have to use fancy math (mod operator) to solve fizz buzz.
Since it is based on a game children play, how would they solve this problem? I imagine they would use one hand to count up to three, and the other hand to count up to five. Every time one hand reaches three, they say fizz, and every time the other hand reaches five, they say buzz.
No fancy math. Just counting.
I apologize for butting in, but you guys just don't realize how good you have it. In order to practice their craft, people in other fields have to buy all kinds of equipment, parts and tools just to do something basic. For some, it takes years to accumulate those things. For others, they'll never be able to practice their craft outside of work or outside of a university.
But you can practice your craft almost anywhere. Along with books and magazines, you can get your "parts" and "tools" from wikipedia, blogs, forums, etc. Professionals from major companies will even respond to nobodies like me in their blogs. Best of all, if you make a really bad mistake during your learning process, you can always do it over again by restarting your computer.
And with all of these advantages, is it too much to ask that a college graduate with a degree in computer science be able to find a way to solve fizz buzz?
Again, I apologize for butting in.
@Andrew Zen "When I (try to) code, the biggest difficulty I find is knowing the "right" way to code, that is, my finished product does the job, but I have no idea if it is the most elegant solution, or the most secure solution."
believe it or not, the fact that you "can't tell" if what you've written is ideal is a good sign. it means you have taste to begin with. while you may not be able to tell yet, other people can't even tell that there IS an "elegant" solution. the question "is this ideal?" would never come to them
all you need is practice/experience. get practice with a wide variety of languages... as many different paradigms as you can mess with
A on February 26, 2010 6:40 AMhmm: WRT the guys arguing you should just use a library function:
The best way to state simple problems in interviews (like the one I sat when I was being interviewed as a programmer) is not in the problem domain of a computer language. Languages these days are full of awesome lib functions that mean you don't have to solve the same problem 40 times (for the 40 slightly different edge cases) every week.
I was interviewed first over the phone with abstract questions about physical objects (not giving away the questions as I got the job and they'd be cross!) then in the face to face interview that followed I was given like +, -, goto and maybe one other command and asked to solve problems - really stretches your brain and gives the interviewer a good look at it in the process.
No auto checking from some website neither - part of the question is simply "will that work?" - being able to evaluate your own code after you've written it and see problems (debug...) is an important skill that npp's definitely lack, as they rely on the feedback of "compile until it (sort of) works!"
Yes, doing things the efficient way is important, but you can teach that after the person has arrived; that is a domain specific problem. The idea of the test, you would agree, is not to choose the language that lets you solve that low level problem in the fewest lines, but to watch you solve a tricky little problem (the like of which always pop up in the odd corners of whatever language you happen to be using.)
Joe Jordan on February 26, 2010 8:04 AMWatch out with your phone interviews that you don't pull crap like asking experienced "practical" programmers idiot questions whose answers are to be found only within the pages of programming theory textbooks. I've been around the block with respect to programming, and in my COBOL days I was subject to one phone interview where the interviewer asked ridiculous technical questions that had little to do with programming, per se. My favorite was: "What is the difference between an implicit and an explicit scope-terminator?" I told him I hadn't the faintest idea what he was talking about. He then explained that the implicit scope terminator was the period at the end of a COBOL sentence and the explicit was like the END-IF at the end of an IF statement. I thought to myself, "Thanks for adding to my fund of knowledge, dude, but just what did you think you were proving with that question?" There were a large number of similar questions, which the interviewer seemed to be selecting from a book, and which I couldn't answer. Needless to say, I didn't get the in-person interview, and I later got the back-channel word that the interviewer had thought I didn't know how to program -- which surprised my back-channel source because she had watched me punch out tens of thousands of lines of working code over the course of a year-long contract.
Mike Clark on February 26, 2010 9:04 AMI say, let 'em keep applying and interviewing... sure it's a pain on the interviewers, but they make me look like a programming superhero (and tbh, I'm only ok/good).
The question is: someone please show me their resumes because I've gotta start putting whatever they've got on theirs, onto mine if they can get an interview and I can't. Hell, these days, I don't bother applying to most jobs because they ask for '5+ years exp in all of java/jsp/c#/asp.net/c++/winforms/wpf/mfc/sql/sql server/mysql/oracle' (literally, I'm not kidding).
I think the point that should be made is: If you ask for ridiculous skills/knowledge then you're going to get ridiculous applicants.
Steve E on February 26, 2010 10:11 AMSteve, I have all those things on my resume, with experience ranging from 3-5 years to 15 years, and 25 years overall programming (none of those things existed when I started - C was a new language a few years after I started programming). However, this is what you see in a down economy, and it goes in cycles - during the dot-com boom, companies had large IT teams, and the resources to train people and let them specialize. After the bust/9-11 double whammy, you started seeing a lot of ads for "general-purpose computer guys" as companies tried to get away from proper IT departments which are more expensive. In the 80s, when people didn't take IT very seriously, you saw the same thing, and it wasn't unusual to see large companies with one "computer guy" on staff, who had to know/do everything computer related.
I agree with your point - it is ridiculous to ask for a "brain surgeon/Oracle DBA/Truck driver" in a job ad, because that's never what you really need... but there is a logical reason why we see that happening. It does tend to bring in some applicants who don't have the full skill set that was requested, but the industry should not have to tolerate applicants with NO SKILLS at all.
That is what the blog is written about. It's not about stupid interview questions, or use of APIs, or being a technical mastermind of some sort. It's about people who have no skills at all related to the job of writing code, and the inability of recruiters/HR to weed these people out before they've wasted everyone's time with an interview, or perhaps even been hired. We're not talking about people whose skills aren't up to snuff - we're talking about folks who couldn't code their way out of a paper sack if their life depended on it - people who couldn't explain an algorithm for anything, much less write one in a computer language. It is not about whether you understand math terms like Fibonacci sequence - it's about the fact that even if I explained how to generate Fibonacci numbers, they wouldn't be able to code it.
Everybody chill. Sure there are incompetent job candidates. There are also incompetent co-workers, incompetent bosses, and so on down the line.
I have a degree in CS and have worked almost exclusively as a contract programmer/writer since uni daze (typo is intentional due to my horrid habit of being a smarta$$). Since I have had maybe 30 job interviews over the past 20-odd years, I can spew answers to a myriad of goofy interview questions, such as these from the top of my head:
* Wwhy are manhole covers round? Because manholes are round).
* How do you represent all the days of the month with two dice? Use 6 as 9.
And on and on.
I love coding stuff. I occassionally blow the syntax, especially a C++ gig if I haven't had one for a couple of years. I manage to always keep up-to-date by writing little "fun" programs at least monthly. I'll be reading something like this page and try my own FizzBuzz solution (I typically use Visual Studio/C# as I used to code in Java and invariably get the case wrong for stuff like console.writeline().). Took my maybe two minutes.
I think some folks forget what a degree in CS signifies. It means you have suffered through writing your own QuickSort, double-linked lists, b-trees, etc. You do this so that when you are in the real world you never do it again. No one does. That's what libraries are for. However, you should be able to at least describe the algorithm and give a cogent reason why you might use a bubble sort instead of a Quicksort (small data set anyone?).
Does that make me a good developer? I don't know. In my only real dev gig I had one close colleague who was good dev and another who was awful. She invariably checked in code that DID NOT BUILD!!! If she wasn't so nice (and cute, the truth comes out), I would have strangled her.
doug (back to work writing the docs for our C++ library, including samples, a VS wizard, and tutorial)
Doug Schwartz on February 26, 2010 1:29 PMHi all,
There are plenty of readers of this Blog that aren't classically trained CS programmers.
I'm not ,for a start, with experience in AS/400 and Siebel (plus a bunch of things in between). Its not that the questions are hard, but they really are not useful for determining whether a programmer is any good.
At this point I have to ask , what is a programmer? Are we talking about a code monkey ? someone who just does what he is given ? or the more expansive Analyst Programmer who actually thinks about what the business wants.
Being able to solve coding problems is all very well , but it isn't what you are looking for in a business context. You want someone who is sharp and can get what's going on ...a trickier problem.
From what has been spoken in the comments there is a perception that solving the problem is trivial and anyone who doesn't get it is not a programmer. Well, not true - it might be for the subset of languages and methodologies you are talking about - but consider someone who has worked for 10 or so years in RPG on AS/400 or Mainframe technologies.
Its not that the person is useless , but their world of experience so removed from yours its a difficult to see that they are any good.
Jasmine, I'd like to ask a serious question: Are you skilled in all of those things (honestly)? When do you decide not to put something on your resume anymore? At one point, I've worked in/with all of those technologies (except oracle), but I can't say that I could be proficient with them if hired to do the job tomorrow.
Heck; in half of them, if you haven't worked with it in a year, it's not the same anymore. It's been 5 years since I touched MFC... does it belong on the resume anymore?
Steve E on February 26, 2010 3:04 PMOf course it is not too much to ask a candidate a FizzBuzz or LCM or question. I still stand by the fact that it isn't all that useful.
We (hopefully) don't write procedural code like that all day long in our Java, C#, or C++ jobs.
We write OO code and as such we need to ask questions that force the applicants to write OO code. If we don't then we haven't tested whether or not they can do our job.
Bottom line: It is an interview FAIL if you don't force the applicant to code in the language and style that they will be coding in the job for which they are applying.
Don't even have to read what's been written above. I can get a job as a programmer/analyst just by reciting the affirmation when I need to: "I am a programmer/analyst."
I show up. I say I am a programmer. I get the job.
I have a gift for abstract reasoning that I was born with. The rest is scribbling.
Neal Brenard on February 26, 2010 5:42 PMI have been wondering about this a lot. Programmers who are good enough so that they can be given a problem and can structure possible good solutions fast enough in their mind (and under the pressure of an interview) must have been living with code all day. There is one kind of programmer who has a personal interest and a strong focus into the subject, usually geeks who code as a hobby or for honor in their spare time and not someone who has just finished his computer science studies but shows no interest for programming outside of his studies/job. I have talked with computer science graduates who would be stunned when requested to type even the simplest program in a blank piece of paper in fifteen minutes. For most people this is a problem. A student I was doing private lessons in java is frequently curious how I am given a problem that was handed to them in the class and almost in an instant I can decide which functions, classes, variables and algorithms I have to create to solve this and why those and not other things. It's a talent that you acquire because you were burned in programming in your youth instead of doing what most other people were doing. It's not easily acquired by four years of studies except if you are really focused to learn and still you might learn the theory but miss the actual experience.
Michael Kargas on February 26, 2010 7:40 PMI think that even the "Fizzbuzz challenge" doesn't require computation. 100 lines of hardcoded "print" would do fine. The question clearly states "prints the numbers from 1 to 100" and not "calculates". Any programmer who can clearly translate the requirements to proper working code is a good programmer.
I realy pity the people that dump any solution here. One other quality of a programmer is to "read" the requirements and give an answer in code to it. Those wo dumped a solution here did not quite understand the post. If the post was a test for a job interview, all of you would have failed. Therefore it is great that the comments are back here. There is more info in the comments about programmers than in the article itself.
Caspar_Kleijne on February 28, 2010 10:15 AMMy Supervisor said, 90% of the informatic students can't code. I thought he was just a bit cynical and exaggerated things. After reading this I may reconsider the opposite- Maybe he was right?
Sixing Huang on February 28, 2010 6:09 PM@barney: "This is perhaps the most preposterous lie I've ever seen on a programming forum."
You say that, without any basis, where I can affirm that this does and has indeed happened. It happened to me; twice. I was broke both times, didn't have a choice, and did end up getting the job and the first thing I was to do was clean up my interview 'test' code and implement it in production.
Steve E on March 1, 2010 7:19 AMJeez, i felt the sudden urge to write that simple 1 to 100 counter in c, vb, c#, and ruby just to prove myself.
Now, that explains why I often have coworkers who can't figure out how to programatically write to a text file...
Andtherewaslight.wordpress.com on March 1, 2010 10:04 AMJust have one anecdotal data point to add: A few months ago I went on an interview for a Mac Developer position. I have a lot of iPhone and some OS X experience so I felt I had pretty good odds. I spent a lot of time studying Cocoa Design Patterns (great book BTW), Core Data, Core Animation, basically all of the things a good Mac dev would use day to day. I got to the interview and was asked stuff about atoi and itoa and arrays. Granted I was able to answer the stuff but I was pretty caught off guard and had to solve the stuff cold, from scratch.
After that experience I realized you don't study for the job, you study for the interview. That was my first technical interview and now I look back and realize how naive I was to think the interviewers would care about my knowledge of Cocoa design patterns and what I had written in Cocoa.
Fast forward to last week when I had an interview at a very prestigious company and spent weeks ahead of time solving as many interview questions as I could get my hands on (and consuming the excellent book Programming Interviews Exposed). The position was for basically a C# developer, I have very little experience with C# but got an offer because of (I suppose) my good fundamentals, ability to reason through problems, analytical skills, etc., but definitely not my C# skills.
So another possible solution to Jeff's question is that a lot of these interviewers who are coming back saying programmers can't program are interviewing for entry level positions which inherently means the candidates have little to no interviewing experience and probably don't know they are vastly different than traditional interviews.
tldr: Don't study for the position, study for the interview.
Brandon Malicoat on March 1, 2010 10:40 AMIf you are having trouble finding people who can program then you are doing it wrong. A while back I was looking for an entry-level programming job. I thought that it would be a good fit, given that I have a BS in CS and I am actually good at programming. It turns out that there are very few jobs available and they all require that you know a bunch of APIs that could, for the most part, be learned in a week or two. As a result I applied to very few jobs and although I did eventually get one it sucked and wasn't really a programming job.
I eventually wised up and realized that the software industry doesn't want people who actually know how to program and so I continue to program - for fun. Meanwhile I am back in school getting my BS in Math (4.0 this time!) and I am going to be a teacher. I will probably end up steering my students away from programming as a career because it just isn't a good way to find employment.
Oh you're not talking about the paucity of entry-level programmers? Yeah, I see a lot of ads for people with 4+ years of experience. Of course I could have been one of those people in a couple of years, if entry level positions existed.
Tom Cahalan on March 2, 2010 6:26 AMcan't close my tag, maybe I can do it from this post
Tom Cahalan on March 2, 2010 6:27 AM@Brandon - I would say if you have to study for the interview questions, then you shouldn't be applying for the job. Prepare by learning about the company, and maybe brush up on some arcane stuff nobody ever uses so you can nail the trick questions, but you should not have to study your coding. I get what you're saying though - a good interview is important, but if your object is to convince them that you know something you don't know, then it's dishonest.
@Steve - yes I am proficient in all those things you listed except "Oracle" in general. I know PL/SQL and a little Oracle admin, and have used it recently - but sometimes when people say "Oracle" they want you to be an administrator or a client app programmer, and I'm not well-versed in the whole Oracle stack of crap. On my resume, I would not list Oracle at all, or I would list it last, and make sure to say "minimal" experience.
The last time I looked for work, I actually tailored my resume to each position - that is what you have to do at my level. For entry-level stuff, it's ok to just make the laundry list, but for higher-level stuff, it pays to spend at least an hour tweaking your resume to match with the job description without being dishonest. Listing skills which don't apply to the job is a waste of space, and contributes to the reader's suspicion about you, and could actually prevent you from getting a call. Experienced HR people automatically suspect you are lying on your resume, and I've actually been told in an interview, "we gave you the SQL test because we thought you were lying about that," and they also told me I was the only one who got their trick question right. I told them their question was not a good judge of a SQL programmer, and suggested a better question. I didn't get the job :)
In general, I think a big problem in the industry is too many "programmers" who don't LOVE it enough to really know their stuff. It's not about book smarts really - it's about people who don't have the personality type to be programmers. These people don't love coding, and they will never be good at it.
I love coding so much that I've taken the time to learn lots of languages and different technologies, but I'm firmly grounded in the basics too. Questions to ask yourself are:
1. If a new language were launched tomorrow, would you want to learn it? Would program Hello World, or would you try something more meaningful? Do you think you have the chops to learn a completely new language, not based on any language you already know?
2. Do you like to open up your IDE and actually solve coding problems or do you just tell yourself you can do it and don't bother to actually try it?
3. Have you ever written a game that already exists? Or re-written a known software because you know you can do it better?
4. Ever work on a personal project all night? I mean literally until sunrise the next day.
5. Do you even have personal projects or do you just do this as a job?
If you can't answer affirmatively to all those questions, I don't think you should be a programmer. You need to love this job, or it's going to drive you nuts. This is regardless of skills - I've known people who had skills but hated coding.
BTW, @Caspar - we don't post solutions to FizzBuzz to prove anything really - any idiot can program FizzBuzz. People who love programming also generally love teaching programming, and solutions are generally posted in an instructive manner. And while 100 print statements might be a solution to the stated problem, it is not scalable, not efficient, and shows very little programming skill beyond a demonstration of KISS.
So... here it is in one line of C#... and yeah, I actually built and tested it. Would I answer this way in an interview? Maybe, maybe not, depending on the situation.
for (int i = 0; i < 100; Console.WriteLine((++i % 3) == 0 ? ((i % 5 == 0) ? "FizzBuzz" : "Fizz") : (i % 5 == 0) ? "Buzz" : i.ToString())) { }
Jasmine Adamson on March 2, 2010 12:06 PM
@Jasmine What I mean is the questions asked at interviews are very different from day-to-day programming and designing. They typically ask questions with bad/good/excellent answers and if you haven't experienced these types of questions you can be out of luck at interview time. Of course you still have to know what the job description outlines but the interview doesn't usually cover that.
I think my saying studying is your 'brush up on arcane stuff'.
Brandon Malicoat on March 2, 2010 1:02 PMJasmine: Your 5 questions serves as a litmus test for qualifying good versus bad developer. Would you ask 5 similar questions of your dentist? I highly doubt your dentist spends the weekend drilling cavities for free. They might attend a conference now and then but nothing like what developers expect from one another.
Do we ever get a break? Just because one prefers learning on the job during business hours instead of sacrificing weekends coding up video games no one will ever see doesn't mean they're bad developers. In fact, they may just be smarter because they found a way to get paid to learn.
Vin on March 2, 2010 2:24 PMRegarding the 123456789 problem, if you add "-" to your list of operators you get 2 solutions that add up to 2001.
Keith Brafford on March 2, 2010 2:28 PMNo those wouldn't be interview questions - those are simply representative of the kind of thing you might ask yourself if you weren't sure you liked coding or not. Dentists are a different breed - but I would bet that the good ones actually do love their work, and I know of a few who do spend the occasional weekend doing charity dental work. We know that there's a large number of people in the industry churning out mediocre code, and they have no desire to make it any better.
Those people aren't a detriment to the industry - in fact they are the life blood of the industry, and very little would ever get done without "grunt" programmers. Rather, they are a detriment to themselves, and while some of them will accomplish great things, the large majority will go on to other things, like management. There are also coders who do it because they have a passion for it - those people either go on to become Tim Berners-Lee, or they never accomplish much but spend a lifetime doing something they love.
You can not underestimate the importance of doing something you love. Those are the people I want on my team - if programming is a job, and you hate it like you would hate scrubbing toilets, then really it's not for you, and it doesn't matter how capable you are. Sure, you can be an asset for a while, but are you really doing what you love? Are your skills being wasted as a coder? Are you wasting your life here, when you could be the next world-famous astronaut, athlete, or toilet-scrubber?
When I see people with CS degrees who can't code at all, I know they have picked CS for some other reason than passion, and they are never going to be motivated to be good programmers, even if they can learn the skills - and that is an injustice to them... although it does get a lot of work done out there.
Jasmine Adamson on March 2, 2010 2:56 PMI work with a ton of paycheck programmers who could all write functions to find prime numbers or reverse strings. The secret is enthusiasm, passion and focus on quality.
Yes, some people are "frauds", but we're all frauds. Software is a huge confidence game, where we get paid to do something we're not even sure is possible until we're finished. Most of the time it works. When it doesn't, it's almost never because someone sorted an array wrong.
Christopher McCall on March 2, 2010 3:53 PM@DLitz: Or you could just, you know, use a >code< tag. It seemed to work for my answer.
Billy O'Neal on March 2, 2010 8:39 PMOops.. I mean <code> of course :P
Billy O'Neal on March 2, 2010 8:39 PMI found this post through twitter and I had to laugh. It is so true! I was interviewing Computer Science graduates at a college job fair. I asked the first technical question -- using any programming language you like write me a function that will return the mean of 10 numbers. Only 30% of the interviewees could do it. Sad.
Jimocz on March 3, 2010 4:06 AMFirst, I've been on both sides of the interview table. Clever math questions, "thought" provoking questions like how many eggs fit in an 747, clever questions about string reversals, linked lists v. arrays are all pointless. I've used 'em and had them used on me and in the end they had little bearing on the interviewee's impression of me or my impression of the candidate when I was the interviewer. I've run into plenty of "smart math guy" or "good puzzle solver guy" that couldn't build solutions to save their life. In my 30+ years coding, the number of times I've actually leveraged my math background or some CS trick like bubble sorts is tiny. I work with some people now that couldn't solve a simple math puzzle to save their life but regularly churn out clean, usable, maintainable solutions. I would much rather have "maintainable solution guy" than "clever math guy".
When I interview people, I look for a couple of things:
1. "Are they a tinker" questions. These include whether they have their own systems at home, what they are using, why did they pick what they did etc. If a candidate does not have their own setup at home that disqualifies them on the spot. If they aren't problem solving at home, they won't at work.
2. "Are they a resume leech" questions. A resume leech is someone that puts on their resume a project, on which they actually worked, but were a minor player. So they describe in great detail this complicated system that was mostly built by someone else and claim it for their own. To weed these folks out, I ask them in detail about the project and how they got specs, what were some of the pitfalls, who were the stakeholders, and so on.
3. "Are they honest" questions. The resume leech questions are part of this, but the single worst thing to me is to find someone that is dishonest. The simplest means to determine this is to ask them a question to which they are very unlikely to know the answer. I want them to tell me they don't know. This isn't a clever question. This is something tangible. For DBAs I used to ask them to tell me the difference between a unique constraint and a unique index. Most candidates will try to BS me. BS me once during the interview and that's the end of the interview which is why I usually ask this type of question early.
4. Lastly, the only way to truly know if a developer knows what they are doing is to actually have them do something. I typically have some minor projects handy to dole out to interviewees to see if they can do it. I remember one company to whom I contracted, had a simple app they had the candidate build on the premises. Once piece of the spec was intentionally missing. They used that to see if the candidate would spin their wheels or actually ask someone.
I can't say my system is perfect because it definitely is not. But I has helped me trim the interview times down and get good people or identify bad people quickly.
Thomas on March 5, 2010 10:08 PM[url=http://www.etoiledevenus.com][COLOR=blue] voyance[/COLOR][/url]: That article makes me feel good.
thnx
voyance : The worst thing about all this - apart from having to work with them - is realizing they keep average salaries down, because business have to worry about being profitable with some of these no-hopers on their team.
Extravoyante on March 6, 2010 3:55 AMScary but probably true. Thanks for the tips, I will for sure utilize some of the tasks to clear out some applicants.
http://ironicprogrammer.blogspot.com/2010/03/scary-but-maybe-true.html
Peter Johansson on March 7, 2010 7:07 AMSo what is the solution? As somebody who is looking forward to getting into the industry where does one learn to be a programing programmer(P.P?)? From the previous deluge of post it seems that a computer science degree is the least desirable option to learn real world problem solving.
Donald Thomspon on March 7, 2010 7:39 PMFrom the previous deluge of post it seems that a computer science degree is the least desirable option to learn real world problem solving
No, a computer science degree is fine; you just have to do it right. That means you can't just sleepwalk through the courses, pass the exams, and get the diploma. You have to seek out practicums, research projects, and internships, or start your own programming projects trying to apply the theory you've learned in the classes.
Charlesegrant on March 7, 2010 11:38 PMWith the current economic conditions, we don't hear so much about the shortage of programmers, but the problem still exists. Particularly when you start talking about the shortage of competent programmers. There simply aren't enough of us.
I while back I read an article in Business Week titled "Software gap - a growing crisis for computers". A few quotes:
"The overriding issue is people - specifically, skilled computer personnel... Already, the supply is far short of the demand, and the gap is widening inexorably. For the foreseable future, there is literally no possibility that we shall have enough trained people to go around."The implication of this gap for business and science ... is that
"use of computer systems five years hence will be seriously
hobbled". There are only about 120,000 programmers in the U.S. -
and right now there's a shortage of 55,000 or more of these
new professionals, according to some estimates.[...]
John A. Devries, chairman of Computer Applications Inc., emphasizes,
"Unquestionably there is a software problem that will extend for
two years or more."[...]
Want ads in any newspaper show brisk demand for programmers.
Recruiters are active and job-hopping is common; one company
is offering a $100 reward for leads to programmers. Salaries
for college-graduate beginners start at $6,000; a couple of
years experience brings $10,000 to $12,000; special knowledge
in key areas such as time-sharing or systems programming brings
$15,000 or more.[...]
"The market for EDP personnel is tighter than hell." According
to Dick H. Brandon, head of Brandon Applied Systems, there's a
need for 175,000 now - and by 1970 this need will swell to
220,000, plus 275,000 related jobs, in the U.S. alone. And
rapid growth in Western Europe makes it an international
shortage, as well.
from "Software gap - a growing crisis for computers", BUSINESS WEEK,
November 5, 1966, pp. 126-133.
(At least it's reassuring to know that things can only get better...)
The reason you get stories like this (apart from the fact most programmers have superiority complexes) is the computing industry has no real body to encompass a standard in the way other engineering disciplines do.
Google, Microsoft, IBM et al get around this by requiring a CS degree or masters as the minimum. There are some things you simply cannot learn through googling and Wrox books that you learn in a CS degree. Whether these things are useful or not for most programmers' careers - aside from back-patting interviews - is a different matter of course. My view is they are but not all programmers do it for fun.
Chris S on March 8, 2010 4:30 PMWhen I needed a developer recently I set up a time with the candidate to answer questions on StackOverflow. I then posted three questions - telling him the names so he could find them - and awaited his answers. This not only gave me a sense of his programming ability, it allowed me to compare his answers with others and to get a feel for his speed. This was a *great* way to do the evaluation and I highly recommend it for others!
Years ago at a larger corporation where we were aggressively hiring, I gained a reputation as a somewhat "difficult" interviewer. Why? Simply because I asked questions that forced people to reveal their state of knowledge. In one case, I uncovered an individual that clearly had no knowledge whatsoever of programming or our problem domain. I strongly recommended against hiring him but the management felt that we 'needed people with experience' (which his resume indicated but it was clearly a lie) so they hired the guy anyway. A debacle ensued in which the fellow "worked" for nearly a year without producing a single line of code. When they began termination proceedings, the guy claimed a disability and threatened to sue. He was still there when I left.
Mdbritt.wordpress.com on March 8, 2010 7:22 PMThere is also the case, made very well in this article, Confessions of a mediocre programmer by Alan Norton, that to do well in IT departments
"It doesn’t take a lot of advanced coding skills to move data around and magically turn it into information."
http://blogs.techrepublic.com.com/programming-and-development/?p=2329
Eoghan Murphy on March 9, 2010 4:05 PMJeff, on an unrelated matter, the link for your Visual Studio color scheme (very old post) is not working, any chance on making it available somewhere else?
Potiguar Faga Zawitowski on March 10, 2010 8:25 AMHello, I want to one day become a programmer.
I've been programming home and never been educated in programming.
I tried the Codility tool and was given the following assignment;
----
Equilibrium index of a sequence is an index such that the sum of elements at lower indexes is equal to the sum of elements at higher indexes. For example, in a sequence A:
A[0]=-7 A[1]=1 A[2]=5 A[3]=2 A[4]=-4 A[5]=3 A[6]=0
3 is an equilibrium index, because:
A[0]+A[1]+A[2]=A[4]+A[5]+A[6]
6 is also an equilibrium index, because:
A[0]+A[1]+A[2]+A[3]+A[4]+A[5]=0
(sum of zero elements is zero) 7 is not an equilibrium index, because it is not a valid index of sequence A.
If you still have doubts, this is a precise definition: the integer k is an equilibrium index of a sequence if and only if and .
Assume the sum of zero elements is equal zero. Write a function
int equi(int[] A);
that given a sequence, returns its equilibrium index (any) or -1 if no equilibrium indexes exist. Assume that the sequence may be very long.
----
This is my answer (and it is correct);
----
int equi ( int[] A ) {
int lSum = 0, hSum = 0;
for(int i = 0; i < A.Length; i++)
{
lSum = 0;
hSum = 0;
for(int ii = 0; ii < i; ii++)
{
lSum += A[ii];
}
for(int ii = A.Length - 1; ii > i; ii--)
{
hSum += A[ii];
}
if(lSum == hSum)
return i;
}
return 0;
}
----
Would anyone share your comments on my coding style?
What can I improve?
Thankful for answers, Henric.
Henric Johansson on March 10, 2010 5:55 PMI'm a non programming programmer and created this using tit bits off the net http://www.pathloans.com/ ... what do you guys think .?
Maxaxe on March 11, 2010 2:10 AMThis is a really annoying topic which seems to come up frequently and I don't know why you (Jeff) are so preoccupied by it.
If I apply to be a lawyer do I have to argue a case to get the job? For a doctor to join a hospital, do i need to operate on a patient while someone watches me do it?
So why is there such a preoccupiation with programmers 'proving they can program' in an interview?
Firstly, your assumption that someone who can't answer a particular knowledge-based question or code a certain function in an interview, "can't program at all" is often false. Sure, there are people who legitimately can't program who would flunk out of those interviews, but what about the ones who are good, just can't recall all the information off the top of their head?
Do you really think everyone programs off the top of their head with no resources, no information?
I look at programming as being a builder, a constructor. Often you need tools to build something. A house builder can't build a house without a hammer, nails, and a toolbox.
A programmer's toolbox is part Head knowledge, part Experience, part Information Gathering acumen (google, stack overflow, other resources) but most of all ability to get something done and solve a problem -- and i'm sorry but asking someone to define this or that term does NOT prove problem solving ability.
Jesus, this is like listening to the mass voice of insecure self righteousness. Unfortunately this is all too typical in the IT community. If egg heads could step back and look at business problems you would realize that being a good programmer is adaptability, business acumen and unless you are working for the Google's of the world the ability to sling some code to automate an otherwise expensive process. I would focus your interview questions to somethign relevant not just a nice recursion problem to partake in a proverbial "cock comparing contest".
Ryan Fisch on March 12, 2010 6:16 AMRyan Fisch put it more eloquently than i could. ;) someone should examine the phenomenon of programmer elitism from a psychological standpoint and analyze why this attitude is so prevalent.
Here's an interesting counterpoint read that I found compelling and entertaining:
http://blogs.techrepublic.com.com/programming-and-development/?p=2329
DavidC on March 12, 2010 9:59 AMI've been programming for 20+ years on a multitude of systems, and have been praised up, down, left and right for my extremely good technical skills. However, I still may not be able to whip up a good algorithm in an interview context, because one of my best skills is KNOWING WHERE TO LOOK THINGS UP. In any realistic job situation I have always had access to books, other programmers, and/or the Internet and/or other reference materials, and am extremely good at using these to ask precisely and exactly the questions needed to solve any given problem. At this very moment I would have to look up the algorithm for the "smallest common multiple of two numbers," to which I have been exposed exactly once -- when I first encountered it, in a graduate-level Computer Science course just last year. (The professor seemed shocked that nobody in the class knew this "familiar" equation, but I had never seen it in a class, book, or work context.) I can whip up a string-reverser in no time, though. :-)
DavidC, you have got to be kidding!
"If I apply to be a lawyer do I have to argue a case to get the job?"
Yes. You need to study for years, complete a degree, study more, pass an exam in the area you want to practice, and then assist on cases and then - if you're looking for a job as a trial lawyer - you'll need to have argued and won cases on your own.
"For a doctor to join a hospital, do i need to operate on a patient while someone watches me do it?"
Hell yes. It's known as residency. You go through pre-med, then get your medical degree, then you work under supervision for years, then if you survive all that you can get a job at a hospital.
"So why is there such a preoccupiation with programmers 'proving they can program' in an interview?"
Because you're applying for a job as a *programmer*. For a lawyer or a doctor, their history is fully documented. For a programmer, you have to show you can actually program.
This is not elitism. It's demonstrating that you have some grasp the basic skills of your profession. If you can program, this is not exactly an onerous requirement. If you can't program, go away and stop wasting my time.
Ryan Frisch -
"Unfortunately this is all too typical in the IT community. If egg heads could step back and look at business problems you would realize that being a good programmer is adaptability, business acumen and unless you are working for the Google's of the world the ability to sling some code to automate an otherwise expensive process."
"Egg heads"?! Asking a putative programmer to show that they can program, and we are eggheads? I'm sorry, but being a good programmer means you are able to *program*. If you can't program, then adaptability and business acumen might make you a great real-estate agent, but you're useless to me.
PixyMisa on March 12, 2010 7:32 PMThose examples are exactly NOT the same thing as what you ask a programming job candidate to do. A lawyer would talk in an interview about the cases they have argued and what they've been involved in - in short, what -work- they have done. I imagine a doctor's interview would be the same thing. The focus is on what you have done in your professional life, not "I'm going to assume you're a loser and don't know ANYTHING until you jump through some hoops for me".
Perfectly well and I would expect "what you've done" to be an important topic in interviews.
Anyway, "Showing you can program" means that you can take a design and translate it into solid, working code. It's not regurgitating algorithms from compsci 301.
All of this commentary is just proving to me that programmers are bad at interviewing and selecting good candidates... maybe that's my psychology background speaking ;) (Interviews, BTW, are the worst predictors of future job performance)
Actually, to prove programming ability aptitude tests are much more effective. It looks at the mind's core ability to compute, adapt and think, rather than what you've memorized about language syntax and algorithms.
I'm sure all can agree that memorizing syntax does not make one a good programmer. Then again you never know with this bunch!
Ah, I think I understand.
Maybe fizzbuzz should use the word "divisible" or "divisor" instead of "multiple". Compare the explanations for divisor, multiple, and least common multiple.
Oh, I get it! http://en.wikipedia.org/wiki/Divisible
In mathematics, a divisor of an integer n, also called a factor of n, is an integer which evenly divides n without leaving a remainder.
For example, 7 is a divisor of 42 because 42 / 7 = 6.
Can you explain that again? http://en.wikipedia.org/wiki/Multiple_(mathematics)
In mathematics, a multiple is the product of any quantity by an integer. In other words, for the quantity a such as integer, real number, or complex number, b is a multiple of a if b = na for some integer n. The n is also called coefficient or multiplier. Additionally, if a is not zero, this is equivalent to saying that b / a is an integer with no remainder.
Some said the multiple is the product of an integer by another integer so it is called integer multiple. When a and b are both integers, a is also called a factor of b.
WT... err... Huh? http://en.wikipedia.org/wiki/Least_common_multiple
A simple algorithm
This method works as easily for finding the LCM of several integers.
Let there be a finite sequence of positive integers X = (x1, x2, ..., xn), n > 1. The algorithm proceeds in steps as follows: on each step m it examines and updates the sequence X(m) = (x1(m), x2(m), ..., xn(m)), X(1) = X. The purpose of the examination is to pick up the least (perhaps, one of many) element of the sequence X(m). Assuming xk0(m) is the selected element, the sequence X(m+1) is defined as
xk(m+1) = xk(m), k ≠ k0
xk0(m+1) = xk0(m) + xk0.
In other words, the least element is increased by the corresponding x whereas the rest of the elements pass from X(m) to X(m+1) unchanged.
The algorithm stops when all elements in sequence X(m) are equal. Their common value L is exactly LCM(X). (For a proof and an interactive simulation see reference below, Algorithm for Computing the LCM.)
Francis on March 13, 2010 3:03 AMThis whole conversation is ridiculous, simply because everything really is relative. Glen Ford said it right, why should I give a flying crap if you can find the smallest common multiple of two integers if the job focuses on business rules and not on math? If one person knows .NET very well but has to write four lines of code for an algorithm, but the next guy knows C++ very well and uses a modulus operator for the same algorithm shortened to one line, but doesn't know .NET well, I'll take the first guy in a heartbeat.
A job in any workplace requires a great deal of communications between team members. Rarely used math operators can be learned with a 30-second lesson; experience with all of the tools that are used in the workplace takes a significantly greater amount of dedication.
Mikeash: "Do you really want to present yourself as someone who can only handle problems you've already solved in the past?" If those problems are applicable to the job, absolutely. It's called experience!! If you have the greatest handle on programming in the world but you have no real-world experience, you're pretty darn worthless. It took me years to get past the hurdles of understanding SDLC, practical patterns on each tier, and team workflows and processes, such that I earned the role of "Sr. Developer". I suck at math, but I can run circles around the know-it-all who sits around quoting algorithms all day and am able to stay productive, producing bug-free code, because with experience I have learned a strong grasp of the big picture.
That's not something 15 minutes can measure. You can take your 15-minute algorithmic test and shove it.
stimpy77 on March 13, 2010 12:59 PMIf one person knows .NET very well but has to write four lines of code for an algorithm, but the next guy knows C++ very well and uses a modulus operator for the same algorithm shortened to one line, but doesn't know .NET well, I'll take the first guy in a heartbeat.
But it's not an either/or choice. There are candidates out there who know algorithms (or at least the modulus operator!) and .NET and and can implement pragmatic business solutions. It's a competitive market. Why would I settle for someone who only has one or two of the skills I'm looking for? Sure there are lot more candidates who are only competent in one or two areas, but that why I want to screen them out as quickly as possible.
As an aside, I'm baffled by folks claiming the modulus operator is some obscure 'mathy' thing. It's the natural operation to use whenever you to execute some statement in a loop only every nth time through. For example printing a progress message only every 100th time through a loop.
For pity's sake, VB has 8 arithmetic operators and C# only has 5. You can't be bothered to remember the meaning of 5 operators? Yes, I'm sure you do everything you need to without it, but you could also write all your code using only IF and GOTO. Why would you want to?
Charlesegrant on March 13, 2010 4:06 PMI was just trying to figure out why words like "egghead", "algorithms", "compsci 301" and "memorization" were written in the comments. I thought that the choice of words lead people into thinking about LCM algorithms instead of just trying to solve the problem. My earlier comment was meant to show explanations of different terms in order of decreasing awesomeness, with the "simple algorithm" being the least awesome. I didn't mean to offend anyone.
But if someone asks an unfamiliar question, then isn't that the best time to genuinely show off your other skills, like adaptability, communication, and business acumen?
Ok, so you've never used the mod operator. How about int, fix, round, ipart, fpart, floor, ceil...? No? How about converting a number into a string and checking for a decimal point? Too WTFy? Fine. Write it calling imaginary functions called isFizz and isBuzz. They ask you to implement those functions? Maybe you can explain to them why you can't do this off the top of your head. Maybe you can ask, in a nice way, why it's so friggin important to them. Even if you disagree with their response, at least you've given yourself another chance to solve the problem: How to show them that you can program when their "simple" programming question is not so simple.
From the article:
At least bad programmers can be educated
I don’t think that’s true. I would hire a smart math or music major who had never programmed in his life before I’d hire a mediocre experienced programmer. I’d buy the smart math or music major a book on algorithms and a book on whatever programming language the company was using and I bet he’d be outperforming the experienced programmer in six months.
I think people are looking at this test as accomplishing more than it was intended to. My take was that these simple tests weren't intended to measure a programmer's skillset, but more as a form of captcha, intended to weed out the non-programmers from the thousands of applicants that every job application attracts.
The intent wasn't to decide who to hire, but who to schedule for a phone interview.
The problem is that given the web, every job query receives thousands of totally unqualified applicants, and we need a way to winnow the chaff.
As for the difficulty of this problem, note that it doesn't say anthing at all about the modulus operator. It says "for multiples of three, ...". To many of us, the obvious solution is to use the modulus operator, but it's not actually part of the specification, so complaints about how supposedly "obscure" it is, are off the mark.
jdege on March 15, 2010 12:04 PMWell, I am interviewing right now. I have written software for a while (Fortran IID, PL1 among others).
1. I don't get rattled much anymore. How many of the "non-programmers" are early/mid 20's, and freeze in the headlights?
2. What critical thing are you doing that you only want "the top 1%"? Why would the top 1% want to work for you? Is all your work such that only the "top 1%" can do it quickly and well? How about a reliable, hard-working 70th percentile programmer who's going to night classes and is easy-going and pleasant to work with? Is there no routine maintenance that the "top 1%" might find boring that he can learn from?
3. Especially for the younger engineers, what steps do you take to make them better? To help them move from the top "45%" to the "top 10%"?
4. Take a good look at the tone of these comments. Are these attitudes that you admire and respect? Would you really want to work for someone is is tempted to ridicule some candidate because they have insufficient humility?
5. Something that took me by surprise: the system and network administrators have little respect for developers, and see development positions as an entry step on the way to being a sys or DB admin. This explains more about the pay than poor programmers using up jobs and eating into employers profits.
6. For us with jobs and strong resumes, these are not tough times. For many others they are very tough times. Let's try this: try to put your candidate at ease, and determine what his/hers skills are. If you are trying to stump them, that comes through clearly, and your hostility is even more unsettling to the stressed candidate.
7. Somethings I am interested in: getting better, and helping my coworkers get better. To that end, I learn on evenings and weekends, and try to be as helpful and supportive as I can with my team. That said, how important is it whether my method of determining a prime made up on the spot in an interview is O(n), or O(n/2)?
8. I think there may be a real problem with American professional programming culture. This is not to say that anyone should be hired who cannot do the work. The eagerness I see in posts to denigrate those with (perceived) lower skills, however, is widespread, and distressing. I am concerned that younger people do not see Software Engineering as a challenging and interesting creative endeavor, as much as an unpleasant and combative arena. If this is indeed the case, expect to see the quality of the "top 1%" to decline along with the number of new practitioners entering the field.
The comments to this entry are closed.
Subscribe in a reader
Subscribe via email
|
|
Traffic Stats |