If you have a dregree in accounting and financial analysis, and nowhere on your resume does it say "Computer Science" then maybe I won't ask that question. Though if you are being a professional programmer and took some time to learn something about computer science by reading books in your spare time, then that's bonus points for you. At the very least, try reading "Gödel, Escher, Bach" for the fun of it.
Doing linked lists is not a waste of time. We have those in our code and they will encounter them while debugging things or writing new code. If they can't figure out something as simple as linked lists then maybe they shouldn't be touching our code (or touching kernel code in bsd or linux while they're at it). If they can't do this then something on their resume is likely wrong as we really only wanted to interview people who said they have experience with low level software.
They're not working for the company, they're working for themselves. They have a product they are trying to sell, that product just happens to be themselves. I'm the customer seeing if I want to pay for that product or not. I'm not going to just believe the seller's marketing fluff, I want to see if the product is as good as the label. If they fell it's a waste of their time to sell to me then they can go and try to sell to someone else.
I've tried that, didn't quite work out. First you can't ask anything with code you can't share, so you spend a lot of time stripping out all the proprietary stuff. I show them the paper and ask them to find the bug. They inevitably can't find it because it's way outside their experience or skill level and I'm seriously regretting even asking it because they want to know the answer when I want to move on to the next question. So I have a really really short snippet of code with tons of errors in it and ask them to point them out and see how many they can find (and they still want to know if they found them all or not).
You probably still should have gone to college. For one, it increases your pay over time. Maybe not for the early jobs but eventually those without a degree hit a ceiling, not just for promotions but for pay increases. I've been at places where the upper pay tiers can only go to those with degrees or advanced degrees. I had one early boss who was pushed out the door eventually for not having the degree.
People who taboo against premature optimization tend to never optimize, ever. But optimization inevitably ends up as something that's required just for scalability issues. Ok, so don't write bubble sort now, but maybe it's good to use it sometime and somewhere when you discover that the library's sort is a piece of crap and people are using it inside of nesting loops and the customers are bitching about how the software is slow. I have often seen cases where projects screech to a halt and they have to figure out how to improve performance. I've been on multiple projects where power up time takes too long and this has risen to a priority problem to solve. People need to stop treating optimization like anathema.
The purpose of the question is not about having someone join the team so that they can implement bubblesort. Granted, it's odd to ask about a specific sorting method as opposed to implementing any sort that's reasonable for a small set of numbers. Now the advanced question is how to sort a million numbers when you only have enough RAM to hold 100 numbers at a time. Is that a trick question? It's similar to some problems that actually come up on the job and eventually there is something that needs to be solved that isn't already on google.
Please sort this array of N numbers using any method you like except by calling a library routine. Not a trick question. Want to see if you can swap numbers in an aray, or if you're deathly afraid of writing code, unfamiliar with how actual coding works, can you think about the problem in a coherent way, and when you're doing we'll ask you about some lines.
On the job you will likely do something somewhat similar; not a sort maybe but you will have to write code without falling back on a library, or have to debug the library itself when it has bugs, or have to think about something you haven't done before and figure out how to do it.
Speaking as someone who is 53, the answer is that the resumes often lie or exaggerate. What looks good on paper isn't always good in person. Judging whether or not someone is good enough to handle the job is not at all easy. Just chatting with someone doesn't tell you much. Most of the stuff in the past is already on the resume, we can dig down and ask for details but what does it really tell us? So we'll pick a couple things on the resume to focus on, have you describe one complicated problem you have to solve, maybe ask a few pointed questions to weed out those who fluffed up the resume. But then we need to see if you can program, because we've been burned over and over by people who seemed great but turned out to be duds. I know mediocre programmers in their twenties and I also know mediocre programmers in their fifties, and all ages in between.
I had someone refuse to write anything on the white board. Not even simple one-liners. Passing notes back and forth with the other interviewer we agreed to no go further with the candidate and have other interviewers waste their time. I imagine that the person left thinking he was too good for us. But to be honest he really wasn't really coming across great while talking to him and we were hoping that maybe he could program and redeem himself.
If someone really is too good for such things then walking out of an interview without answering the questions isn't the way to show it. Instead solve the questions perfectly then walk out. Otherwise we just assume that the ego is not in check with the skills.
Sounds like a recruiter. No one actualy wanting to hire a good candidate would say "please memorize stuff in advance for the questions I'm going to ask you." All you're going to get is someone who can memorize stuff. It's already too hard to distinguish between someone who knows stuff from someone who crammed the night before. However recruiters on the other hand want the commision, so they're going to cheat all the time to make sure the mediocre candidate they found gets the job...
The goal here is not to reinvent. The goal is to see if you can understand the problem and figure out how to attempt to solve it. Getting the final answer perfect isn't necessary. Bubble sort is so simple that even if you don't know the details you can basically do it. Instead of saying "bubble sort" which probably freaks out the people who hated college, just say "write some code to sort this array in place".
Now then the person gets the job. If they're not just a code monkey they may end up fixing an algorithm in a library, or having to choose a new one because the library's sort is too slow. More often I see people whining about having to do problems with linked lists and such and saying they should just use a library.
However I look at linked lists a lot at work; they show up in the debugger when stepping through the code, the existing code has bugs in it that need fixing, or someone uses the linked list library wrong because they don't understand how they work, and so forth. The goal here isn't for the candidate to come in and rewrite all the linked lists, that would be dumb. But the candidate must be able to deal with low level code on a daily basis. We have no need for a candidate that can't write or debug any code unless there's a library available.
And I have figured out bugs in code merely by thinking about them. It's a very useful skill when you have a core dump that doesn't have enough information available to pinpoint things, or you're only told the behavior of the bug by a tester. Though I do have a lot of coworkers who are easily stumped by bugs if they can't get the extra evidence from the debugger.
Hmm, every single day on the job I have to solve what are essentially puzzles. They just happen to be programming puzzles most of the time, some times they are logistics puzzles, or puzzles about how to get two employees to get along, and so forth. If everything was easy then they could just hire someone with a certificate instead, or outsource the job.
For someone who will be writing code that has algorithms you really do want a candidate that understands algorithms and knows how to figure out the big-O behavior of code that they are looking at. It's not hard and doesn't require memorization and used to be taught as lower division undergrad courses. If the candidate doesn't understand theory then they're probably better suited to jobs not involving algorithms.
(Though you run into this problem occasionally where the smart self-taught programmer is baffled about why the code is so slow and demands faster processors. I remember a phd physicist baffled why his code that was O(n^3) only took 5 minutes when n==100 but had been running all day long when n==1000.)
The academic questions are asked so that we can judge if the person has an academic background or can at least reason coherently about issues that may be important for an advanced job. If someone doesn't know the answer then say so, but at least try to give a thoughtful answer instead of dismissing it. Sure, if the candidate is behing hired for a grunt level coding job it's not important (though the coding details are relatively more important), but if this is for a leadership or design job then this is important.
But when applying for a job one should first read the requirements of the jobs. They're not always well written, I will agree. But one should be able to figure out that the job is for someone writing real code versus someone to create a high level "solution" to package together components. Smaller companies don't usually have room for more than one or two of the second type of job.
Such people should consider being contractors or consultants, they are very rarely interviewed in my experience. However if they do a bad job on the job then they're unlikely to get more jobs that way, so treat it as a very long term interview.
And if they complete it satisfactorily then they get hired and thus compensated? If you want the job then you have to work for it. That usually means more of your own free time spent researching the company, boning up on rusty skills, getting a portfolio ready, and so forth. Why is this any different?
It could potentially be a straight forward problem. Implement merge sort. Use the internet if you want. But when you then come into the office for the interview we are going to ask you pointed and detailed question on every line by assuming that you either wrote it or understood it. Is the documentation correct, is there a set of test cases, and so forth. It's a lot of work and I probably wouldn't go that far for a candidate but it's not unfair. The candidate can always refuse to do the task and seek employment elsewhere.
Not being nervous is a good interview skill. Or actually, pretending not to be nervous. Seriously, showing confidence will greatly improve your chances of getting the job even if you're just pretending to be confident. This is playing the people game instead of the knowledge game. People who can do the knowledge or skill stuff shouldn't worry because they shouldn't be thrown off by stuff like bubble sort. Anyone decent can give bubble sort a go even if they don't know about sorting, just take how you'd sort by hand and then try to make an algorithm from it, and getting the right answer is not the goal of the interview.
I ask the simple questions because people with experience on paper get it wrong all the time. Then I work my way up. I even apologize for asking such obviously simple questions but then don't get an suitable answer. Past experience is often a lie. People will list everything their team did on the resume but then are unable to answer questions about what they wrote. It sounds lame but it is so very common (maybe people don't know the fundamental rule that if you put something on your resume then you will be asked about it at some point).
You know all those goof offs at work that can't really do their job and are carried by everyone else? Well they go out and interview with reallly great looking resumes that gets them past the HR screeners.
I agree. CS people in the last decade or so don't seem to have a lot of low level experience and probably don't know C/C++, but EE people do know this. The drawback is that EE people don't really know CS and from what I've seen have a tendency towards the quick and dirty solution.
I think what scares some people is that they're treating this like a college test where they have to have the right answer. That's not the point of an interview most places. The goal is to find someone who is capable of doing the job, does not need a ton of training every day, and is capable of moving on from early basic tasks to complicated projects. So knowing how to program well is just the first step, but so many people with programming experience on their resume really are terrible at programming and will need a lot of retraining. And solving some sort of problem gives a hint that the person can handle the complicated stuff and isn't just a person who looks stuff up on the net (and becomes confused when the net doesn't have the answer).
Agreed. I like the person who asks about the question such as asking what assumptions can be made. Often though I get excuses instead.
I don't want to see someone who already knows the answers to esoteric problems, but I want them to know how to get to the answer on their own. For a senior position with high pay I'd rather hire the person who writes the pages that gets looked up on google rather than the person who does the looking up. You can't always get that good person though, there aren't very many of them.
We tried once to have a non-whiteboard method. There are a couple web sites that let you type directly into a window in various language, compile the code and test it, and both sides cans see what happens. The candidate was a disaster though so it was hard to see how effedtive it would have been.
The reason for the whiteboard is plain though - people exaggerate or outright lie on their resume. People that look great on paper can be completely clueless when it comes to actually programming. We don't have the time to do remedial programming classes for all new hires.
For example, if someone's resume says they've written device drivers for 15 years and yet they don't even know how to clear a bit in a register then clearly something doesn't add up. Either they didn't really do the work they claim, or they have a different definition of device drivers, or they were merely just a part of a larger team where others did the work (this is extremely common to see on resumes). Seriously anyone bothering to spend an hour the night before cramming on how to program in C would know the answer. This is not a two hour job, this should take less than a minute!
Programming jobs require two things: ability to program and problem solving. These can be combined by just asking a programming problem. I like to ask things outside the comfort zone and those are invariably disasters. Over time I ask things that are simpler and simpler. And they still fail. The job requires looking at low level details - we do have linked lists and on the job the candidate needs to read and understand code like this, and I still see someone complaining "I would normallly just use a library for that" as a cop-out. Sorry, we have to deal with pointers on the job, we have to deal with debugging someone else's code that uses pointers, so if candidates can't handle a freshman level linked list then I have no reason to believe that they can handle the job. This isn't a couple hour job, it should take less than ten minutes.
Now I also like tougher questions. I wish I had time to give them, take a candidate out of the comfort zone, away from the questions you can look up online and crammed for already. Like convert from BCD to binary decimal, do a permutation, things like that. I don't need to see the correct answer but I do want to see the candidate have to think. I rarely get this far as they're still drawing diagrams of a what a linked list looks like.
Sometimes I hand over a piece of paper with some obvious bugs (and some subtle style problems like forgetting to declare "const") and ask the candidate to tell me what's wrong, and even that sometimes doesn't quite pan out.
As for the article summary: - yes, knowing np complete is important. It's not required! But it is a data point. If they know the answer it gives me confidence that they either have a broad background, remembered stuff from school, wasn't the C average student, etc. In some programming jobs knowing this stuff is nearly mandatory. It helps distinguish the generic programmer from the expert designer. - I have to look up how to get the length of a Python string myself. But I don't program in Python very often. I Python programming was my daily job or I was applying for a job where it would be my daily job then I *would* know how to do this without looking it up. - bubble sort on a white board isn't that hard. Seriously. Or at least getting something that's O(n^2) that sorts even if not strictly bubble sort. May as well call it "dumb sort".
The realistic test of actual ability is HARDER than doing stuff on the white board. The realistic test is "there's a deadline on friday and you're fired if you can't bring up this buggy board and have it working", or "here are 20,000 lines of code that keeps crashing randomly and you have until the end of day to figure it out, and oh by the way it never fails if run in a debugger". The interview on the other hand has turned into a lot of softball questions.
Agree here. A lot of people can't see the big picture. I see a lot of ideas about switching to different tools for example, but they seem to think it's easy to do. But you've got to get some budget for it, you have to get buy in from many departments, and so on. But even worse, it will take TIME and slow down everyone.
I see a lot of ideas that about about making the work environment more comfortable for the person with the ideas. They may think they're helping out the entire team but you never see the idea giver say "I personally hate this tool but I think the team should use it for the better good", instead it's "I love this tool, I used it in my last job, and you need to adopt it now!"
Or someone wants to just go an implement a new idea without seeing how other departments feel, or how it will affect the customer, how much retraining is needed, how it will affect the schedules, and so forth. Sure it may sound like the boss is just griping about your work all day long but you've got to get the primary job done FIRST. It is really distressing to hear one of your workers say that they didn't work on the assigned tasks because they were working on this cool new feature instead, because it means you have to go to your boss or director or the project manager and have them shout at you for being late.
The workplace is where you do work. It's not called the funplace. 90% of it will be dull and boring, the other 10% will be dull or boring. The job is to do what the company needs doing, not doing what the employee wants to do. And so many of these ideas don't seem to get that.
Slashdot Mirror
If you have a dregree in accounting and financial analysis, and nowhere on your resume does it say "Computer Science" then maybe I won't ask that question. Though if you are being a professional programmer and took some time to learn something about computer science by reading books in your spare time, then that's bonus points for you. At the very least, try reading "Gödel, Escher, Bach" for the fun of it.
Doing linked lists is not a waste of time. We have those in our code and they will encounter them while debugging things or writing new code. If they can't figure out something as simple as linked lists then maybe they shouldn't be touching our code (or touching kernel code in bsd or linux while they're at it). If they can't do this then something on their resume is likely wrong as we really only wanted to interview people who said they have experience with low level software.
They're not working for the company, they're working for themselves. They have a product they are trying to sell, that product just happens to be themselves. I'm the customer seeing if I want to pay for that product or not. I'm not going to just believe the seller's marketing fluff, I want to see if the product is as good as the label. If they fell it's a waste of their time to sell to me then they can go and try to sell to someone else.
I've tried that, didn't quite work out. First you can't ask anything with code you can't share, so you spend a lot of time stripping out all the proprietary stuff. I show them the paper and ask them to find the bug. They inevitably can't find it because it's way outside their experience or skill level and I'm seriously regretting even asking it because they want to know the answer when I want to move on to the next question. So I have a really really short snippet of code with tons of errors in it and ask them to point them out and see how many they can find (and they still want to know if they found them all or not).
You probably still should have gone to college. For one, it increases your pay over time. Maybe not for the early jobs but eventually those without a degree hit a ceiling, not just for promotions but for pay increases. I've been at places where the upper pay tiers can only go to those with degrees or advanced degrees. I had one early boss who was pushed out the door eventually for not having the degree.
People who taboo against premature optimization tend to never optimize, ever. But optimization inevitably ends up as something that's required just for scalability issues. Ok, so don't write bubble sort now, but maybe it's good to use it sometime and somewhere when you discover that the library's sort is a piece of crap and people are using it inside of nesting loops and the customers are bitching about how the software is slow. I have often seen cases where projects screech to a halt and they have to figure out how to improve performance. I've been on multiple projects where power up time takes too long and this has risen to a priority problem to solve. People need to stop treating optimization like anathema.
The purpose of the question is not about having someone join the team so that they can implement bubblesort. Granted, it's odd to ask about a specific sorting method as opposed to implementing any sort that's reasonable for a small set of numbers. Now the advanced question is how to sort a million numbers when you only have enough RAM to hold 100 numbers at a time. Is that a trick question? It's similar to some problems that actually come up on the job and eventually there is something that needs to be solved that isn't already on google.
Please sort this array of N numbers using any method you like except by calling a library routine. Not a trick question. Want to see if you can swap numbers in an aray, or if you're deathly afraid of writing code, unfamiliar with how actual coding works, can you think about the problem in a coherent way, and when you're doing we'll ask you about some lines.
On the job you will likely do something somewhat similar; not a sort maybe but you will have to write code without falling back on a library, or have to debug the library itself when it has bugs, or have to think about something you haven't done before and figure out how to do it.
Speaking as someone who is 53, the answer is that the resumes often lie or exaggerate. What looks good on paper isn't always good in person. Judging whether or not someone is good enough to handle the job is not at all easy. Just chatting with someone doesn't tell you much. Most of the stuff in the past is already on the resume, we can dig down and ask for details but what does it really tell us? So we'll pick a couple things on the resume to focus on, have you describe one complicated problem you have to solve, maybe ask a few pointed questions to weed out those who fluffed up the resume. But then we need to see if you can program, because we've been burned over and over by people who seemed great but turned out to be duds. I know mediocre programmers in their twenties and I also know mediocre programmers in their fifties, and all ages in between.
I had someone refuse to write anything on the white board. Not even simple one-liners. Passing notes back and forth with the other interviewer we agreed to no go further with the candidate and have other interviewers waste their time. I imagine that the person left thinking he was too good for us. But to be honest he really wasn't really coming across great while talking to him and we were hoping that maybe he could program and redeem himself.
If someone really is too good for such things then walking out of an interview without answering the questions isn't the way to show it. Instead solve the questions perfectly then walk out. Otherwise we just assume that the ego is not in check with the skills.
Sounds like a recruiter. No one actualy wanting to hire a good candidate would say "please memorize stuff in advance for the questions I'm going to ask you." All you're going to get is someone who can memorize stuff. It's already too hard to distinguish between someone who knows stuff from someone who crammed the night before. However recruiters on the other hand want the commision, so they're going to cheat all the time to make sure the mediocre candidate they found gets the job...
Ok, what if I handed you a sorting routine and asked you to debug it because it's causing performance problems at a major customer's site?
The goal here is not to reinvent. The goal is to see if you can understand the problem and figure out how to attempt to solve it. Getting the final answer perfect isn't necessary. Bubble sort is so simple that even if you don't know the details you can basically do it. Instead of saying "bubble sort" which probably freaks out the people who hated college, just say "write some code to sort this array in place".
Now then the person gets the job. If they're not just a code monkey they may end up fixing an algorithm in a library, or having to choose a new one because the library's sort is too slow. More often I see people whining about having to do problems with linked lists and such and saying they should just use a library.
However I look at linked lists a lot at work; they show up in the debugger when stepping through the code, the existing code has bugs in it that need fixing, or someone uses the linked list library wrong because they don't understand how they work, and so forth. The goal here isn't for the candidate to come in and rewrite all the linked lists, that would be dumb. But the candidate must be able to deal with low level code on a daily basis. We have no need for a candidate that can't write or debug any code unless there's a library available.
And I have figured out bugs in code merely by thinking about them. It's a very useful skill when you have a core dump that doesn't have enough information available to pinpoint things, or you're only told the behavior of the bug by a tester. Though I do have a lot of coworkers who are easily stumped by bugs if they can't get the extra evidence from the debugger.
Hmm, every single day on the job I have to solve what are essentially puzzles. They just happen to be programming puzzles most of the time, some times they are logistics puzzles, or puzzles about how to get two employees to get along, and so forth. If everything was easy then they could just hire someone with a certificate instead, or outsource the job.
For someone who will be writing code that has algorithms you really do want a candidate that understands algorithms and knows how to figure out the big-O behavior of code that they are looking at. It's not hard and doesn't require memorization and used to be taught as lower division undergrad courses. If the candidate doesn't understand theory then they're probably better suited to jobs not involving algorithms.
(Though you run into this problem occasionally where the smart self-taught programmer is baffled about why the code is so slow and demands faster processors. I remember a phd physicist baffled why his code that was O(n^3) only took 5 minutes when n==100 but had been running all day long when n==1000.)
No you don't have to write perfect code. People want to see how you think about the problems.
The academic questions are asked so that we can judge if the person has an academic background or can at least reason coherently about issues that may be important for an advanced job. If someone doesn't know the answer then say so, but at least try to give a thoughtful answer instead of dismissing it. Sure, if the candidate is behing hired for a grunt level coding job it's not important (though the coding details are relatively more important), but if this is for a leadership or design job then this is important.
But when applying for a job one should first read the requirements of the jobs. They're not always well written, I will agree. But one should be able to figure out that the job is for someone writing real code versus someone to create a high level "solution" to package together components. Smaller companies don't usually have room for more than one or two of the second type of job.
Such people should consider being contractors or consultants, they are very rarely interviewed in my experience. However if they do a bad job on the job then they're unlikely to get more jobs that way, so treat it as a very long term interview.
And if they complete it satisfactorily then they get hired and thus compensated? If you want the job then you have to work for it. That usually means more of your own free time spent researching the company, boning up on rusty skills, getting a portfolio ready, and so forth. Why is this any different?
It could potentially be a straight forward problem. Implement merge sort. Use the internet if you want. But when you then come into the office for the interview we are going to ask you pointed and detailed question on every line by assuming that you either wrote it or understood it. Is the documentation correct, is there a set of test cases, and so forth. It's a lot of work and I probably wouldn't go that far for a candidate but it's not unfair. The candidate can always refuse to do the task and seek employment elsewhere.
Not being nervous is a good interview skill. Or actually, pretending not to be nervous. Seriously, showing confidence will greatly improve your chances of getting the job even if you're just pretending to be confident. This is playing the people game instead of the knowledge game. People who can do the knowledge or skill stuff shouldn't worry because they shouldn't be thrown off by stuff like bubble sort. Anyone decent can give bubble sort a go even if they don't know about sorting, just take how you'd sort by hand and then try to make an algorithm from it, and getting the right answer is not the goal of the interview.
I ask the simple questions because people with experience on paper get it wrong all the time. Then I work my way up. I even apologize for asking such obviously simple questions but then don't get an suitable answer. Past experience is often a lie. People will list everything their team did on the resume but then are unable to answer questions about what they wrote. It sounds lame but it is so very common (maybe people don't know the fundamental rule that if you put something on your resume then you will be asked about it at some point).
You know all those goof offs at work that can't really do their job and are carried by everyone else? Well they go out and interview with reallly great looking resumes that gets them past the HR screeners.
I agree. CS people in the last decade or so don't seem to have a lot of low level experience and probably don't know C/C++, but EE people do know this. The drawback is that EE people don't really know CS and from what I've seen have a tendency towards the quick and dirty solution.
I think what scares some people is that they're treating this like a college test where they have to have the right answer. That's not the point of an interview most places. The goal is to find someone who is capable of doing the job, does not need a ton of training every day, and is capable of moving on from early basic tasks to complicated projects. So knowing how to program well is just the first step, but so many people with programming experience on their resume really are terrible at programming and will need a lot of retraining. And solving some sort of problem gives a hint that the person can handle the complicated stuff and isn't just a person who looks stuff up on the net (and becomes confused when the net doesn't have the answer).
Agreed. I like the person who asks about the question such as asking what assumptions can be made. Often though I get excuses instead.
I don't want to see someone who already knows the answers to esoteric problems, but I want them to know how to get to the answer on their own. For a senior position with high pay I'd rather hire the person who writes the pages that gets looked up on google rather than the person who does the looking up. You can't always get that good person though, there aren't very many of them.
We tried once to have a non-whiteboard method. There are a couple web sites that let you type directly into a window in various language, compile the code and test it, and both sides cans see what happens. The candidate was a disaster though so it was hard to see how effedtive it would have been.
The reason for the whiteboard is plain though - people exaggerate or outright lie on their resume. People that look great on paper can be completely clueless when it comes to actually programming. We don't have the time to do remedial programming classes for all new hires.
For example, if someone's resume says they've written device drivers for 15 years and yet they don't even know how to clear a bit in a register then clearly something doesn't add up. Either they didn't really do the work they claim, or they have a different definition of device drivers, or they were merely just a part of a larger team where others did the work (this is extremely common to see on resumes). Seriously anyone bothering to spend an hour the night before cramming on how to program in C would know the answer. This is not a two hour job, this should take less than a minute!
Programming jobs require two things: ability to program and problem solving. These can be combined by just asking a programming problem. I like to ask things outside the comfort zone and those are invariably disasters. Over time I ask things that are simpler and simpler. And they still fail. The job requires looking at low level details - we do have linked lists and on the job the candidate needs to read and understand code like this, and I still see someone complaining "I would normallly just use a library for that" as a cop-out. Sorry, we have to deal with pointers on the job, we have to deal with debugging someone else's code that uses pointers, so if candidates can't handle a freshman level linked list then I have no reason to believe that they can handle the job. This isn't a couple hour job, it should take less than ten minutes.
Now I also like tougher questions. I wish I had time to give them, take a candidate out of the comfort zone, away from the questions you can look up online and crammed for already. Like convert from BCD to binary decimal, do a permutation, things like that. I don't need to see the correct answer but I do want to see the candidate have to think. I rarely get this far as they're still drawing diagrams of a what a linked list looks like.
Sometimes I hand over a piece of paper with some obvious bugs (and some subtle style problems like forgetting to declare "const") and ask the candidate to tell me what's wrong, and even that sometimes doesn't quite pan out.
As for the article summary:
- yes, knowing np complete is important. It's not required! But it is a data point. If they know the answer it gives me confidence that they either have a broad background, remembered stuff from school, wasn't the C average student, etc. In some programming jobs knowing this stuff is nearly mandatory. It helps distinguish the generic programmer from the expert designer.
- I have to look up how to get the length of a Python string myself. But I don't program in Python very often. I Python programming was my daily job or I was applying for a job where it would be my daily job then I *would* know how to do this without looking it up.
- bubble sort on a white board isn't that hard. Seriously. Or at least getting something that's O(n^2) that sorts even if not strictly bubble sort. May as well call it "dumb sort".
The realistic test of actual ability is HARDER than doing stuff on the white board. The realistic test is "there's a deadline on friday and you're fired if you can't bring up this buggy board and have it working", or "here are 20,000 lines of code that keeps crashing randomly and you have until the end of day to figure it out, and oh by the way it never fails if run in a debugger". The interview on the other hand has turned into a lot of softball questions.
Agree here. A lot of people can't see the big picture. I see a lot of ideas about switching to different tools for example, but they seem to think it's easy to do. But you've got to get some budget for it, you have to get buy in from many departments, and so on. But even worse, it will take TIME and slow down everyone.
I see a lot of ideas that about about making the work environment more comfortable for the person with the ideas. They may think they're helping out the entire team but you never see the idea giver say "I personally hate this tool but I think the team should use it for the better good", instead it's "I love this tool, I used it in my last job, and you need to adopt it now!"
Or someone wants to just go an implement a new idea without seeing how other departments feel, or how it will affect the customer, how much retraining is needed, how it will affect the schedules, and so forth. Sure it may sound like the boss is just griping about your work all day long but you've got to get the primary job done FIRST. It is really distressing to hear one of your workers say that they didn't work on the assigned tasks because they were working on this cool new feature instead, because it means you have to go to your boss or director or the project manager and have them shout at you for being late.
The workplace is where you do work. It's not called the funplace. 90% of it will be dull and boring, the other 10% will be dull or boring. The job is to do what the company needs doing, not doing what the employee wants to do. And so many of these ideas don't seem to get that.
Everyone's own ideas are brilliant. Everyone else's ideas are a hassle.