Nazis were generally right wing in outlook. Learn history from somewhere other than Infowars. Don't forget the newpaper editorial last week from Alabama suggesting that the KKK go and lynch Democrats in DC. Of course, if right wingers suggest this then it's just a joke, but if left wingers suggest it they must be serious about it.
Dodging tax by paying to charity isn't a scam really or a way to not pay the money. Many governments consider giving to charity as a valid, legal, and moral alternative and not the same as dodging tax. Now the people who don't pay tax and who don't give to charity either, or only give tiny pittances to charity, are the ones really cheating the system.
Even if crypto currencies will take over, the current crop of them are entirely unsuitable as a replacement. Most were designed as a get-rich-quick scheme, or a way to avoid law enforcement, and in a practical manner leave much to be desired.
Predictions of the future fall flat most of the time. Remember we were to have the paperless office predicted a couple of decades ago, and that is not the case anywhere. A paperless monetary system is likely to be similar. It doesn't matter how loudly some twenty-something hipsters argue that cash is useless, paper books are obsolete, or why are luddites still using keyboards, you can't change the entire world by whining about it.
Great, if a candidate brought up that question, I would be happy! I'd add a big plus to the resume and then suggest that it was ascii only or change it to an array of integers. I actually like to leave some things vague in my programming questions just to see if they are going to ask a question about it, which is highly relevant to many jobs.
Even then it's intended as an early "easy" question and I am often dismayed when the candidate has to draw a diagram on the board to figure it out.
Remember also that if the job involves programming, then programming questions are relevant even if the questions are not related to the actual code that the company has. Ie, I would ask about virtual destructors in a C++ interview even if the candidate is unlikely to be involved in that area. Similarly, if the job involves being able to think logically, solve problems, and debug code, then asking difficult problems that require the candidate to think are very relevant. You also want to get a broad idea of what the candidate is like, and you want to know if this candidate is better or worse than the one you interviewed the day before. Sure, all 10 candidates can program FizzBuzz but which one of them do you want working on Mars rover (or whatever your company's pride and joy is)?
If you want programming to be the equivalent of an assembly line worker, then yes, simplistic questions that are only directly related to current job requirements might suffice. But I don't want programming to be that way, it would be awful. Programmers should be like engineers instead.
The reading-a-file example is applicable in MANY contexts (data transfer using a limited size buffer), and people screw it up. So that's why it is asked. It is still a relevant question that provides insights into how the candidate can reason through a problem, even in high level languages. If the candidate says "I would just do File.Copy(a,b) and I refuse to decompose the problem further" well then you've just learned a lot about the person.
Uh oh, I've been 10 years in my job. It keeps changing though. But times change, it used to be the job-hopper was someone to avoid.
I lke specialists in some fields though, such as security. You really don't want a wannabe in that role but you do want a significant amount of direct and focused experience (which is why consultants and contractors in that area are highly paid). In most areas you don't want someone reinventing the wheel but would prefer that they can learn from past mistakes of others, and that is something I often see generalists failing at. I certainly can work in many different areas of programming and help out and gain experience, but I should not be the designer or lead for many areas because until I get that experience first.
I think this is a mistake of many companies who assume that programmers are interchangeable cogs and can work on any topic as long as there's experience with programming. So I see fundamentally flawed network protocols that look like college projects, a complicated security structure that is easily bypassed, commercial RTOSs with novice mistakes and so forth.
I write code that reads and writes to a file using that same sort of loop. That style is used quite a lot in real world programming It might not actually be a file but it may be something with a very similar API, the POSIX-like file API is a very commonly emulated API. If a candidate said he'd just do system("cp a.txt b.txt"); it just reinforces the idea that the guy is either a smartass or can't program. Maybe just say "implement the cp command for us"? The question is relevant because they need to know if the candidate understands writing a loop, can think things through, can deal with using buffers, or is able to write code that deals with POSIX files, etc.
What sort of programming question did you expect? "Please implement a random loop that does random things for us?" And yes these questions are good for 2019 because we are still using C and C++.
The thing is you can't trust the resume. Resumes are full of lies! You have to ask the candidate some questions to find out how much of it is bullshit and how much is real. A flippant answer just means the person is not suitable for working in a team.
I wish there was a way to just have someone work for a 30 day trial period. That's long enough to realize you've screwed up the hiring and the person will never be a good match. Sometimes you learn this in the first week, sadly enough. It's not practical I know. But on the other hand it does work for when you know you want to get that good intern after he or she graduates but not the other three who turned out to be clueless.
You don't do the whole project in the interview. The questions are to see if you can think about something you're unfamiliar with and work your way through it logically. One coworker used to ask "here are the components to a microwave oven, show in pseudo code how you would design the program for it"; then it shows if the interviewee can decompose the problem into parts and lets you see how they go about figuring it out. The goal was not to even have working code or catch every corner case possible, and the pseudo code part means they don't even have to know programming language details.
Trying to get project details out of a job candidate is a funny Dilbert joke, but it doesn't happen in real life. Building the project is what unpaid internships are for.
Don't candidates just copy and paste from the web, or go to stackoverflow? You need to toss in something unusual in the question, such as "the hash table has proven to have bad performance in the field because everything is clustering to only 3 slots, please say why this happens and show how you can fix it."
This slightly annoyed me that many contractors are never interviewed. You don't know that they're any good, you just know that their a friend of the boss. It's only later that you find out your job ends up being to sweep up after the contractor and fix the code.
But the Mac is Unix, whereas Cygwin is emulated Unix that runs noticeably slower than you want it to. Just don't bother with xcode or other built in tools since they've morphed into an iOS development system.
Sure, when I have control over it. The pay is decided at many levels and it's the place where the bullshitting on the resume works the best. Actual productivity over time will get you raises but it's not unusual to be a high productivity worker and make less money than a low productivity worker, all due to the initial starting salary. The annual raises won't get you caught up quickly either which is why, sadly, switching jobs will usually get you better pay than hoping for a stellar annual review.
I think this is the primary reason why companies don't want workers to compare salaries. I once found out the goof-off guy in the aisle was making significantly more money than I did and when I told me boss he said "this is intolerable" before marching upstairs to get me a really large raise. That's not typical though:-)
In my experience, the resumes are wrong. You can't rely on them. If you just rely on other questions you stand a good chance of hiring a bullshitter. I've seen this happen several times. Now that particular example of a programming test was awful, but it should be expected that *some* sort of programming questions will be asked and some code snippets asked for.
I'm in my mid 50s, I've ALWAYS been asked some programming questions or given examples on a whtieboard.
Sorry, was going to add that ANY system, even one you are very familiar with, will be difficult to use if it's not configured the way you like. Even if you love Eclipse, sitting down at a random Eclipse window brought up by someone else will be confusing. The idea that there is a universal system that anyone can sit down and use falls down once you need to do more than click or double click.
My current job was the first time I used a Mac, and I picked it up very fast. I wasn't really a hardcore windows users either though, and the Mac was essentially Unix anyway. Emacs was even built in (textedit was awful, though still better than notepad).
Counting leading zeros or ones gets used a bit. Ie, doing binary multiplication efficiently if hardware can't do it, finding the first element of a set (such as highest priority task), etc.
Agreed here, if you are making that much money and your goal is performance and scalability, you CANNOT program as if a magic library will do all your work for you. It's a complicated system and it needs to be thoroughly undertstood at many levels, high and low. Such a person probably understands all the ins and outs of the language, how it's implemented, how the libraries work, how the database works, what the network protocol is, etc.
I strongly disagree. Use int when you don't care how big the number is. I see lots of bugs arise because people use uin32_t everywhere and then end up with lots of casting to get what they really want. Worse, I see uin8_t which requires extra assembly instructions on some processors when there was never any need to precisely specify the size. I have actually shrunk code to fit on a processor in the past by replacing some uint8_t with int or unsigned int.
My rule of thumb is to only use the sized types when you actually need to know the size - such as data that get communicated to another processor or on the network, put into storage, it has to fit in a device register, etc. If you're doing basic arithmetic or indexing into an array, then use the basic types.
High magic because it involves thinking at a low level. Things aren't done for you, you have to do them yourself. You're space constrained so you can't just use Python or select your favorite libraries to glue together. But there are so many newer programmers who actually don't do much programming beyond a function call (or method call), and they treat everything in the libraries or operating system as a magical black box. Many of these programmers don't even have relevant domain knowledge so they can't even add value by doing the design or providing feedback on the design.
So you're left with the equivalent of an assembly line worker: get input from high up in the line, apply your local function, pass results down the line. You can get off that assembly line once you can understand more complex systems.
Now that's fine if that's all you know, but then in your career you will also be competing against millions of equivalent entry level programmers.
However there will always be a time when someone somewhere needs to know how to do arithmetic at a low level on a computer. These aren't things that are done once and then never needed again for all eternity. Maybe not many people will need to know this, but until we have AI that can do this we'll need people. Every time you have a new processor designed you will need to know how to do this, or when you have a new compiler, or when the third party libraries don't have what you need, etc. Even if you don't do exactly this arithmetic problem you will probably need to do something very similar to it or you will need to think in a manner similar to it.
Even beyond this, I see many programmers who don't know floating point well and because of that they introduce bugs. Ignorance of how things work under the hood causes lots of issues. Given that schools don't teach this anymore, and too many programmers rely on libraries to do anything complex, we may soon be in a time where knowing how to fix code becomes more and more esoteric.
No one gets taught how to do this. You learn it on your own. Even if you're new at this you can still demonstrate that you have common sense and can think logically about something you are unfamiliar with. As a candidate if you can say that you don't have much experience or knowledge in this area but can still think it through well, then you're going to impress the interviewers. But if you just say "we weren't taught that in school" you come across as a problem waiting to happen (and yes I have heard that excuse).
The interviews are about the actual job that needs to be done. Generally the interviewers aren't asking irrelevant questions, they ask questions that are about the job being applied for. If you look back at the post, these questions were asked around the year 2000 when C and C++ were still in very wide use and not even remotely obsolete and which were likely a typical part of the job.
As an aside here, it is an very useful job skill to be able to present on a whiteboard. Ie, be in a small team trying to describe what your bug is and what your proposed fix is, things like that. I know some people who are terrible at communication, and their whiteboard skills which should hellp with this are also terrible, and no one knows what the hell they are talking about most of the time.
A snag is that there's not really a great alternative. If you provide a laptop is likely will not have tools that the applicant is familar with (may as well just use notepad). You can't require the candidate to own a laptop. And the online coding/interview websites aren't much better than notepad anyway (though they are nice). I always preface the whiteboard questions by noting that we don't judge on neatness, and strict syntax correctness isn't needed (because that leads to endless amounts of erasing and focusing on minutiae).
Slashdot Mirror
Nazis were generally right wing in outlook. Learn history from somewhere other than Infowars. Don't forget the newpaper editorial last week from Alabama suggesting that the KKK go and lynch Democrats in DC. Of course, if right wingers suggest this then it's just a joke, but if left wingers suggest it they must be serious about it.
But I came here for an argument!
Dodging tax by paying to charity isn't a scam really or a way to not pay the money. Many governments consider giving to charity as a valid, legal, and moral alternative and not the same as dodging tax. Now the people who don't pay tax and who don't give to charity either, or only give tiny pittances to charity, are the ones really cheating the system.
Even if crypto currencies will take over, the current crop of them are entirely unsuitable as a replacement. Most were designed as a get-rich-quick scheme, or a way to avoid law enforcement, and in a practical manner leave much to be desired.
Predictions of the future fall flat most of the time. Remember we were to have the paperless office predicted a couple of decades ago, and that is not the case anywhere. A paperless monetary system is likely to be similar. It doesn't matter how loudly some twenty-something hipsters argue that cash is useless, paper books are obsolete, or why are luddites still using keyboards, you can't change the entire world by whining about it.
Great, if a candidate brought up that question, I would be happy! I'd add a big plus to the resume and then suggest that it was ascii only or change it to an array of integers. I actually like to leave some things vague in my programming questions just to see if they are going to ask a question about it, which is highly relevant to many jobs.
Even then it's intended as an early "easy" question and I am often dismayed when the candidate has to draw a diagram on the board to figure it out.
Remember also that if the job involves programming, then programming questions are relevant even if the questions are not related to the actual code that the company has. Ie, I would ask about virtual destructors in a C++ interview even if the candidate is unlikely to be involved in that area. Similarly, if the job involves being able to think logically, solve problems, and debug code, then asking difficult problems that require the candidate to think are very relevant. You also want to get a broad idea of what the candidate is like, and you want to know if this candidate is better or worse than the one you interviewed the day before. Sure, all 10 candidates can program FizzBuzz but which one of them do you want working on Mars rover (or whatever your company's pride and joy is)?
If you want programming to be the equivalent of an assembly line worker, then yes, simplistic questions that are only directly related to current job requirements might suffice. But I don't want programming to be that way, it would be awful. Programmers should be like engineers instead.
The reading-a-file example is applicable in MANY contexts (data transfer using a limited size buffer), and people screw it up. So that's why it is asked. It is still a relevant question that provides insights into how the candidate can reason through a problem, even in high level languages. If the candidate says "I would just do File.Copy(a,b) and I refuse to decompose the problem further" well then you've just learned a lot about the person.
Uh oh, I've been 10 years in my job. It keeps changing though. But times change, it used to be the job-hopper was someone to avoid.
I lke specialists in some fields though, such as security. You really don't want a wannabe in that role but you do want a significant amount of direct and focused experience (which is why consultants and contractors in that area are highly paid). In most areas you don't want someone reinventing the wheel but would prefer that they can learn from past mistakes of others, and that is something I often see generalists failing at. I certainly can work in many different areas of programming and help out and gain experience, but I should not be the designer or lead for many areas because until I get that experience first.
I think this is a mistake of many companies who assume that programmers are interchangeable cogs and can work on any topic as long as there's experience with programming. So I see fundamentally flawed network protocols that look like college projects, a complicated security structure that is easily bypassed, commercial RTOSs with novice mistakes and so forth.
I write code that reads and writes to a file using that same sort of loop. That style is used quite a lot in real world programming It might not actually be a file but it may be something with a very similar API, the POSIX-like file API is a very commonly emulated API. If a candidate said he'd just do system("cp a.txt b.txt"); it just reinforces the idea that the guy is either a smartass or can't program. Maybe just say "implement the cp command for us"? The question is relevant because they need to know if the candidate understands writing a loop, can think things through, can deal with using buffers, or is able to write code that deals with POSIX files, etc.
What sort of programming question did you expect? "Please implement a random loop that does random things for us?" And yes these questions are good for 2019 because we are still using C and C++.
The thing is you can't trust the resume. Resumes are full of lies! You have to ask the candidate some questions to find out how much of it is bullshit and how much is real. A flippant answer just means the person is not suitable for working in a team.
I wish there was a way to just have someone work for a 30 day trial period. That's long enough to realize you've screwed up the hiring and the person will never be a good match. Sometimes you learn this in the first week, sadly enough. It's not practical I know. But on the other hand it does work for when you know you want to get that good intern after he or she graduates but not the other three who turned out to be clueless.
You don't do the whole project in the interview. The questions are to see if you can think about something you're unfamiliar with and work your way through it logically. One coworker used to ask "here are the components to a microwave oven, show in pseudo code how you would design the program for it"; then it shows if the interviewee can decompose the problem into parts and lets you see how they go about figuring it out. The goal was not to even have working code or catch every corner case possible, and the pseudo code part means they don't even have to know programming language details.
Trying to get project details out of a job candidate is a funny Dilbert joke, but it doesn't happen in real life. Building the project is what unpaid internships are for.
Don't candidates just copy and paste from the web, or go to stackoverflow? You need to toss in something unusual in the question, such as "the hash table has proven to have bad performance in the field because everything is clustering to only 3 slots, please say why this happens and show how you can fix it."
This slightly annoyed me that many contractors are never interviewed. You don't know that they're any good, you just know that their a friend of the boss. It's only later that you find out your job ends up being to sweep up after the contractor and fix the code.
But the Mac is Unix, whereas Cygwin is emulated Unix that runs noticeably slower than you want it to. Just don't bother with xcode or other built in tools since they've morphed into an iOS development system.
Sure, when I have control over it. The pay is decided at many levels and it's the place where the bullshitting on the resume works the best. Actual productivity over time will get you raises but it's not unusual to be a high productivity worker and make less money than a low productivity worker, all due to the initial starting salary. The annual raises won't get you caught up quickly either which is why, sadly, switching jobs will usually get you better pay than hoping for a stellar annual review.
I think this is the primary reason why companies don't want workers to compare salaries. I once found out the goof-off guy in the aisle was making significantly more money than I did and when I told me boss he said "this is intolerable" before marching upstairs to get me a really large raise. That's not typical though :-)
In my experience, the resumes are wrong. You can't rely on them. If you just rely on other questions you stand a good chance of hiring a bullshitter. I've seen this happen several times. Now that particular example of a programming test was awful, but it should be expected that *some* sort of programming questions will be asked and some code snippets asked for.
I'm in my mid 50s, I've ALWAYS been asked some programming questions or given examples on a whtieboard.
Sorry, was going to add that ANY system, even one you are very familiar with, will be difficult to use if it's not configured the way you like. Even if you love Eclipse, sitting down at a random Eclipse window brought up by someone else will be confusing. The idea that there is a universal system that anyone can sit down and use falls down once you need to do more than click or double click.
My current job was the first time I used a Mac, and I picked it up very fast. I wasn't really a hardcore windows users either though, and the Mac was essentially Unix anyway. Emacs was even built in (textedit was awful, though still better than notepad).
Counting leading zeros or ones gets used a bit. Ie, doing binary multiplication efficiently if hardware can't do it, finding the first element of a set (such as highest priority task), etc.
Agreed here, if you are making that much money and your goal is performance and scalability, you CANNOT program as if a magic library will do all your work for you. It's a complicated system and it needs to be thoroughly undertstood at many levels, high and low. Such a person probably understands all the ins and outs of the language, how it's implemented, how the libraries work, how the database works, what the network protocol is, etc.
I strongly disagree. Use int when you don't care how big the number is. I see lots of bugs arise because people use uin32_t everywhere and then end up with lots of casting to get what they really want. Worse, I see uin8_t which requires extra assembly instructions on some processors when there was never any need to precisely specify the size. I have actually shrunk code to fit on a processor in the past by replacing some uint8_t with int or unsigned int.
My rule of thumb is to only use the sized types when you actually need to know the size - such as data that get communicated to another processor or on the network, put into storage, it has to fit in a device register, etc. If you're doing basic arithmetic or indexing into an array, then use the basic types.
High magic because it involves thinking at a low level. Things aren't done for you, you have to do them yourself. You're space constrained so you can't just use Python or select your favorite libraries to glue together. But there are so many newer programmers who actually don't do much programming beyond a function call (or method call), and they treat everything in the libraries or operating system as a magical black box. Many of these programmers don't even have relevant domain knowledge so they can't even add value by doing the design or providing feedback on the design.
So you're left with the equivalent of an assembly line worker: get input from high up in the line, apply your local function, pass results down the line. You can get off that assembly line once you can understand more complex systems.
Now that's fine if that's all you know, but then in your career you will also be competing against millions of equivalent entry level programmers.
However there will always be a time when someone somewhere needs to know how to do arithmetic at a low level on a computer. These aren't things that are done once and then never needed again for all eternity. Maybe not many people will need to know this, but until we have AI that can do this we'll need people. Every time you have a new processor designed you will need to know how to do this, or when you have a new compiler, or when the third party libraries don't have what you need, etc. Even if you don't do exactly this arithmetic problem you will probably need to do something very similar to it or you will need to think in a manner similar to it.
Even beyond this, I see many programmers who don't know floating point well and because of that they introduce bugs. Ignorance of how things work under the hood causes lots of issues. Given that schools don't teach this anymore, and too many programmers rely on libraries to do anything complex, we may soon be in a time where knowing how to fix code becomes more and more esoteric.
No one gets taught how to do this. You learn it on your own. Even if you're new at this you can still demonstrate that you have common sense and can think logically about something you are unfamiliar with. As a candidate if you can say that you don't have much experience or knowledge in this area but can still think it through well, then you're going to impress the interviewers. But if you just say "we weren't taught that in school" you come across as a problem waiting to happen (and yes I have heard that excuse).
The interviews are about the actual job that needs to be done. Generally the interviewers aren't asking irrelevant questions, they ask questions that are about the job being applied for. If you look back at the post, these questions were asked around the year 2000 when C and C++ were still in very wide use and not even remotely obsolete and which were likely a typical part of the job.
As an aside here, it is an very useful job skill to be able to present on a whiteboard. Ie, be in a small team trying to describe what your bug is and what your proposed fix is, things like that. I know some people who are terrible at communication, and their whiteboard skills which should hellp with this are also terrible, and no one knows what the hell they are talking about most of the time.
A snag is that there's not really a great alternative. If you provide a laptop is likely will not have tools that the applicant is familar with (may as well just use notepad). You can't require the candidate to own a laptop. And the online coding/interview websites aren't much better than notepad anyway (though they are nice). I always preface the whiteboard questions by noting that we don't judge on neatness, and strict syntax correctness isn't needed (because that leads to endless amounts of erasing and focusing on minutiae).