25 years of programming reduced to a question.
-
:thumbsup: Great post! So the short of it is, they asked you to solve a CS exam question on the spot and you did...your solution provided the correct output but they passed on you anyway. :confused: I once believed that if my company ever failed that I could find another job easily. (21+ years of LOB apps for desktop and web) I thought that a resume with dozens of successful (still in use and still generating income) applications might be some strong evidence that I know what I'm doing. After all, programming is just about solving problems using the tools at hand...right? :sigh: After reading this post, I see that I'd likely not pass this type of interview...but that's OK...we're expanding and very soon I'll likely be faced with hiring a jr. dev for some of the grunt work. :| Welcome back Jeremy! :)
"Go forth into the source" - Neal Morse
kmoorevs wrote:
.your solution provided the correct output but they passed on you anyway.
Pretty much.
kmoorevs wrote:
I once believed that if my company ever failed that I could find another job easily. (21+ years of LOB apps for desktop and web) I thought that a resume with dozens of successful (still in use and still generating income) applications might be some strong evidence that I know what I'm doing. After all, programming is just about solving problems using the tools at hand...right?
It's sad, but in this field you have to study how to pass interviews... on top of what you already know. There so many people that interview well but suck at their actual job and vice versa.
kmoorevs wrote:
we're expanding and very soon I'll likely be faced with hiring a jr. dev for some of the grunt work.
Glad to hear that man... especially considering the current issues of the world.
kmoorevs wrote:
Welcome back Jeremy
Thanks. :)
Jeremy Falcon
-
Any test that does not allow you to google the optimal answer to the specified problem is not a real world test and a flat waste of everybody's time. You should be allowed to google and rated on the answer you select from the search results. If you fail to google, you should be immediately disqualified.
I'd love it if I could ask questions back to the interviewer I know they couldn't pass. Tit for tat. :laugh: :laugh: :laugh:
Jeremy Falcon
-
I wanna be part of the cool club. :^) I'd like to think I would've gotten it had I not been under pressure and cut short... maybe. Can I be cool too, huh huh?
Jeremy Falcon
-
Jeremy Falcon wrote:
Does anyone else think that's a fundamentally broken way to find a good programmer?
Yes, its fundamentally broken, but it cuts both ways. If they reject you because you didn't give the answer that they found by googling, instead assessing the answer you did give, do you really want to work with that team? If its some HR flunkie that filtering you out, what caliber of engineer are they like to have working for that company? If if the actual devs, how savvy must they be if they can't see past a googled programming problem answer? In either case, do you really want to be working with those developers? Of course, this only matters if you already have a paying job.
5G -- more lies faster.
patbob wrote:
Of course, this only matters if you already have a paying job.
Yeah exactly. Truth be known I wouldn't care at all about this... but I did get hit by the pandemic job-wise. I was on an American Express contract and they downsized. The folks at Amex are awesome, but welcome to 2020 you know. Anyway, totally agree... it's a different ballgame when you do and don't have a job or contract.
Jeremy Falcon
-
Yay! :jig:
Jeremy Falcon
-
Does anyone else think coding interviews are fundamentally broken? So like, literally I've been doing this (programming) my whole life. We can all go through our accolades I'm sure, but suffice it to say I've done some things over the years to help rebuild departments in large corporations to garner the attention of regional VPs, etc. as we all have. But, I say this because, two days ago, I had an interview with Unnamed Company That Rhymes With Acelook. Don't get me wrong, they were super friendly, and it was a great chat. But I was asked questions like...
Are you comfortable with writing APIs on the backend?That's a generic question, so of course I say sure. To me this indicates the interviewer doesn't realize the best way to interview. No real probing... just questions like that. Ok, cool. Still was a great, super friendly chat. But, then the tech portion of it came up. I was asked this.../* given an array of random numbers, push all the zero's of a given array to the end of the array
for example, if the given arrays is [1, 9, 8, 4, 0, 0, 2, 7, 0, 6, 0], it should be changed to [1, 9, 8, 4, 2, 7, 6, 0, 0, 0, 0]Example:
Input: [1, 2, 0, 4, 3, 0, 5, 0];
Output: [1, 2, 4, 3, 5, 0, 0];Input: [1, 2, 0, 0, 0, 3, 6];
Output: [1, 2, 3, 6, 0, 0, 0]; */Ok fine... I get how this game works. So, let's get cracking. The first solution I start with used two arrays. Cool, no biggie. But then the interviewer asked for me to do it in-place. Ok, fine. So, I write some code that is like a bubble sort that brute forced it (ie, nested loops). We all know that it sucks to have nested loops. Anyway, the interview was cut short and that was that. I look up the "official" solution online, and it's no better than my first attempt. In fact, my first attempt was quicker due to only one loop. The one I linked to was using two loops that just weren't nested. So, not only did my original solution avoid two loops (using more memory though), but I found a more elegant solution online and I just know if that interview wasn't cut short I could've tried something like this the third go-round...
void moveZeroes(vector& nums) {
for (int lastNonZeroFoundAt = 0, cur = 0; cur < nums.size(); cur++) {
if (nums[cur] != 0) {
swap(nums[lastNonZeroFoundAt++], nums[cur]);
}
}
}But since I didn't try something like this first, I got passed on. D
ida gone for the fizzbuzz test and just asked like how do u debug your code ? and what was the most challenging thing you did...and like just sit there and think...can this guy handle all the crap code the last guy left behind and not to mention all the hidden bugs... could he last a few months ...can he make the cake and eat it too....and if it was a guy with 25 years in the industry.. well i'd ask him nothing ..just ask him like what kinda projects he did ..... how long would it take him to learn quantum computing and if he can write a sample program using quantum c++
Caveat Emptor. "Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
-
raddevus wrote:
Finally, they hit on a topic I didn't have experience with and I said so and they went cold.
In my experience... you want honest people. Nobody knows everything... it's impossible. I've managed devs before I helped train how to do interviews for. The vast majority of them just Google questions to ask and that's that.
raddevus wrote:
The thing is you could literally ask Einstein a particular question that even he didn't have experience with.
Exactly
Jeremy Falcon
if i interview people for a job the most important trait will be honesty.
-
Does anyone else think coding interviews are fundamentally broken? So like, literally I've been doing this (programming) my whole life. We can all go through our accolades I'm sure, but suffice it to say I've done some things over the years to help rebuild departments in large corporations to garner the attention of regional VPs, etc. as we all have. But, I say this because, two days ago, I had an interview with Unnamed Company That Rhymes With Acelook. Don't get me wrong, they were super friendly, and it was a great chat. But I was asked questions like...
Are you comfortable with writing APIs on the backend?That's a generic question, so of course I say sure. To me this indicates the interviewer doesn't realize the best way to interview. No real probing... just questions like that. Ok, cool. Still was a great, super friendly chat. But, then the tech portion of it came up. I was asked this.../* given an array of random numbers, push all the zero's of a given array to the end of the array
for example, if the given arrays is [1, 9, 8, 4, 0, 0, 2, 7, 0, 6, 0], it should be changed to [1, 9, 8, 4, 2, 7, 6, 0, 0, 0, 0]Example:
Input: [1, 2, 0, 4, 3, 0, 5, 0];
Output: [1, 2, 4, 3, 5, 0, 0];Input: [1, 2, 0, 0, 0, 3, 6];
Output: [1, 2, 3, 6, 0, 0, 0]; */Ok fine... I get how this game works. So, let's get cracking. The first solution I start with used two arrays. Cool, no biggie. But then the interviewer asked for me to do it in-place. Ok, fine. So, I write some code that is like a bubble sort that brute forced it (ie, nested loops). We all know that it sucks to have nested loops. Anyway, the interview was cut short and that was that. I look up the "official" solution online, and it's no better than my first attempt. In fact, my first attempt was quicker due to only one loop. The one I linked to was using two loops that just weren't nested. So, not only did my original solution avoid two loops (using more memory though), but I found a more elegant solution online and I just know if that interview wasn't cut short I could've tried something like this the third go-round...
void moveZeroes(vector& nums) {
for (int lastNonZeroFoundAt = 0, cur = 0; cur < nums.size(); cur++) {
if (nums[cur] != 0) {
swap(nums[lastNonZeroFoundAt++], nums[cur]);
}
}
}But since I didn't try something like this first, I got passed on. D
First off, a reasonably obvious solution to the coding problem is to move nonzero elements down, and then set the remaining elements to zero. It uses one array, makes one pass, and moves each element at most one time. It was the first thing that came to my mind. There is an STL algorithm,
remove(), that does most of the work, but I would have needed to look it up. If you say "I think there is an STL algorithm for this," it covers all bases whether the interviewer wants you to know the algorithm or wants you to code it by hand. It's just barely possible that in spite of your experience, you aren't a great coder, in which case the coding test worked exactly as expected. Second, who are you to say what the best interviewing technique is? Do you have any data to back up your claim that coding interviews are broken? I hate coding tests too, but I have come to respect them: * They catch people who are lying on their resumes. If you've ever done hiring, you know that's a big problem. * They catch self-taught people who skipped over algorithms and data structures, if that is important to your company. * They select people who prepped for the interview, people who really want the job. * Over-training on algorithms for software devs is exactly like over-training on anatomy and physiology for physicians, or over-training on procedures for pilots and astronauts. It's not enough just to have seen an algorithm (or an organ, or a procedure), you need to be able to call that memory immediately to mind, even under stress situations. Coding tests select people who have really dug in and studied. and rejects people who coasted. If you are a top company paying $200k for an engineer, this is the kind of engineer you want. If you are just writing CRUD screens, maybe this is overkill, but hey, every company wants a 10x developer if they can find one. If you are a developer of a certain age, like me, you resent coding tests because they didn't used to be required. If you are a recent grad, the knowledge that you have to run a gauntlet of coding tests is baked into your expectations. Times change old man. Get used to it. -
First off, a reasonably obvious solution to the coding problem is to move nonzero elements down, and then set the remaining elements to zero. It uses one array, makes one pass, and moves each element at most one time. It was the first thing that came to my mind. There is an STL algorithm,
remove(), that does most of the work, but I would have needed to look it up. If you say "I think there is an STL algorithm for this," it covers all bases whether the interviewer wants you to know the algorithm or wants you to code it by hand. It's just barely possible that in spite of your experience, you aren't a great coder, in which case the coding test worked exactly as expected. Second, who are you to say what the best interviewing technique is? Do you have any data to back up your claim that coding interviews are broken? I hate coding tests too, but I have come to respect them: * They catch people who are lying on their resumes. If you've ever done hiring, you know that's a big problem. * They catch self-taught people who skipped over algorithms and data structures, if that is important to your company. * They select people who prepped for the interview, people who really want the job. * Over-training on algorithms for software devs is exactly like over-training on anatomy and physiology for physicians, or over-training on procedures for pilots and astronauts. It's not enough just to have seen an algorithm (or an organ, or a procedure), you need to be able to call that memory immediately to mind, even under stress situations. Coding tests select people who have really dug in and studied. and rejects people who coasted. If you are a top company paying $200k for an engineer, this is the kind of engineer you want. If you are just writing CRUD screens, maybe this is overkill, but hey, every company wants a 10x developer if they can find one. If you are a developer of a certain age, like me, you resent coding tests because they didn't used to be required. If you are a recent grad, the knowledge that you have to run a gauntlet of coding tests is baked into your expectations. Times change old man. Get used to it.Yeah dude I'm not going to *fully* respond to your angry little post. You don't know who I am or what I've done. Go insult someone else and learn some people skills what you're at it.
Jeremy Falcon
-
if i interview people for a job the most important trait will be honesty.
:thumbsup:
Jeremy Falcon
-
First off, a reasonably obvious solution to the coding problem is to move nonzero elements down, and then set the remaining elements to zero. It uses one array, makes one pass, and moves each element at most one time. It was the first thing that came to my mind. There is an STL algorithm,
remove(), that does most of the work, but I would have needed to look it up. If you say "I think there is an STL algorithm for this," it covers all bases whether the interviewer wants you to know the algorithm or wants you to code it by hand. It's just barely possible that in spite of your experience, you aren't a great coder, in which case the coding test worked exactly as expected. Second, who are you to say what the best interviewing technique is? Do you have any data to back up your claim that coding interviews are broken? I hate coding tests too, but I have come to respect them: * They catch people who are lying on their resumes. If you've ever done hiring, you know that's a big problem. * They catch self-taught people who skipped over algorithms and data structures, if that is important to your company. * They select people who prepped for the interview, people who really want the job. * Over-training on algorithms for software devs is exactly like over-training on anatomy and physiology for physicians, or over-training on procedures for pilots and astronauts. It's not enough just to have seen an algorithm (or an organ, or a procedure), you need to be able to call that memory immediately to mind, even under stress situations. Coding tests select people who have really dug in and studied. and rejects people who coasted. If you are a top company paying $200k for an engineer, this is the kind of engineer you want. If you are just writing CRUD screens, maybe this is overkill, but hey, every company wants a 10x developer if they can find one. If you are a developer of a certain age, like me, you resent coding tests because they didn't used to be required. If you are a recent grad, the knowledge that you have to run a gauntlet of coding tests is baked into your expectations. Times change old man. Get used to it.I also followed your links on your profile and your websites look terrible. So you are clearly not qualified in the slightest to speak about frontend work. Feel free to give me some silly notion like you really didn't care about those sites. I have sites that I don't really care about that look 1,000 times better. Maybe you should look in the mirror when casting judgement bro. :thumbsup:
Jeremy Falcon
-
I also followed your links on your profile and your websites look terrible. So you are clearly not qualified in the slightest to speak about frontend work. Feel free to give me some silly notion like you really didn't care about those sites. I have sites that I don't really care about that look 1,000 times better. Maybe you should look in the mirror when casting judgement bro. :thumbsup:
Jeremy Falcon
Wow, talk about angry little posts (two of them). * My web site was not designed to seek your praise. It serves me as it is. * My answer was not designed to insult you, but to address the question of whether coding interviews are broken. * You only want to hurl insults and not talk about the relevance of the answer. So, like whatever dude. * I may not have the people skills needed to stroke your ego, but they are sufficient to figure out that lame code, arrogance, and self-righteousness are why you failed that interview. Humility will serve you better next time. Best of luck on your next coding test. They aren't going away any time soon.
-
Does anyone else think coding interviews are fundamentally broken? So like, literally I've been doing this (programming) my whole life. We can all go through our accolades I'm sure, but suffice it to say I've done some things over the years to help rebuild departments in large corporations to garner the attention of regional VPs, etc. as we all have. But, I say this because, two days ago, I had an interview with Unnamed Company That Rhymes With Acelook. Don't get me wrong, they were super friendly, and it was a great chat. But I was asked questions like...
Are you comfortable with writing APIs on the backend?That's a generic question, so of course I say sure. To me this indicates the interviewer doesn't realize the best way to interview. No real probing... just questions like that. Ok, cool. Still was a great, super friendly chat. But, then the tech portion of it came up. I was asked this.../* given an array of random numbers, push all the zero's of a given array to the end of the array
for example, if the given arrays is [1, 9, 8, 4, 0, 0, 2, 7, 0, 6, 0], it should be changed to [1, 9, 8, 4, 2, 7, 6, 0, 0, 0, 0]Example:
Input: [1, 2, 0, 4, 3, 0, 5, 0];
Output: [1, 2, 4, 3, 5, 0, 0];Input: [1, 2, 0, 0, 0, 3, 6];
Output: [1, 2, 3, 6, 0, 0, 0]; */Ok fine... I get how this game works. So, let's get cracking. The first solution I start with used two arrays. Cool, no biggie. But then the interviewer asked for me to do it in-place. Ok, fine. So, I write some code that is like a bubble sort that brute forced it (ie, nested loops). We all know that it sucks to have nested loops. Anyway, the interview was cut short and that was that. I look up the "official" solution online, and it's no better than my first attempt. In fact, my first attempt was quicker due to only one loop. The one I linked to was using two loops that just weren't nested. So, not only did my original solution avoid two loops (using more memory though), but I found a more elegant solution online and I just know if that interview wasn't cut short I could've tried something like this the third go-round...
void moveZeroes(vector& nums) {
for (int lastNonZeroFoundAt = 0, cur = 0; cur < nums.size(); cur++) {
if (nums[cur] != 0) {
swap(nums[lastNonZeroFoundAt++], nums[cur]);
}
}
}But since I didn't try something like this first, I got passed on. D
They cared about the details of your solution to some coding task? Yeah. Broken. Coding questions filter out those who can't write a line of code to save their lives. Over the years I've found that filter to be quite handy. But, for those who can code, the coding question is a forgettable formality. It doesn't matter whether your code works well or is clever. You're just showing you can write code.
-
Wow, talk about angry little posts (two of them). * My web site was not designed to seek your praise. It serves me as it is. * My answer was not designed to insult you, but to address the question of whether coding interviews are broken. * You only want to hurl insults and not talk about the relevance of the answer. So, like whatever dude. * I may not have the people skills needed to stroke your ego, but they are sufficient to figure out that lame code, arrogance, and self-righteousness are why you failed that interview. Humility will serve you better next time. Best of luck on your next coding test. They aren't going away any time soon.
Yeah... ok now. There's always one little angry dude on CP. Go run along now... go play by yourself. Nobody wants you...
Jeremy Falcon
-
They cared about the details of your solution to some coding task? Yeah. Broken. Coding questions filter out those who can't write a line of code to save their lives. Over the years I've found that filter to be quite handy. But, for those who can code, the coding question is a forgettable formality. It doesn't matter whether your code works well or is clever. You're just showing you can write code.
Agreed. But anyway... gonna bow out of this thread and get back to work... we have a rouge post here filled with angst who's gonna ruin it for everyone. Thanks for the response though. It's spot on.
Jeremy Falcon
-
Does anyone else think coding interviews are fundamentally broken? So like, literally I've been doing this (programming) my whole life. We can all go through our accolades I'm sure, but suffice it to say I've done some things over the years to help rebuild departments in large corporations to garner the attention of regional VPs, etc. as we all have. But, I say this because, two days ago, I had an interview with Unnamed Company That Rhymes With Acelook. Don't get me wrong, they were super friendly, and it was a great chat. But I was asked questions like...
Are you comfortable with writing APIs on the backend?That's a generic question, so of course I say sure. To me this indicates the interviewer doesn't realize the best way to interview. No real probing... just questions like that. Ok, cool. Still was a great, super friendly chat. But, then the tech portion of it came up. I was asked this.../* given an array of random numbers, push all the zero's of a given array to the end of the array
for example, if the given arrays is [1, 9, 8, 4, 0, 0, 2, 7, 0, 6, 0], it should be changed to [1, 9, 8, 4, 2, 7, 6, 0, 0, 0, 0]Example:
Input: [1, 2, 0, 4, 3, 0, 5, 0];
Output: [1, 2, 4, 3, 5, 0, 0];Input: [1, 2, 0, 0, 0, 3, 6];
Output: [1, 2, 3, 6, 0, 0, 0]; */Ok fine... I get how this game works. So, let's get cracking. The first solution I start with used two arrays. Cool, no biggie. But then the interviewer asked for me to do it in-place. Ok, fine. So, I write some code that is like a bubble sort that brute forced it (ie, nested loops). We all know that it sucks to have nested loops. Anyway, the interview was cut short and that was that. I look up the "official" solution online, and it's no better than my first attempt. In fact, my first attempt was quicker due to only one loop. The one I linked to was using two loops that just weren't nested. So, not only did my original solution avoid two loops (using more memory though), but I found a more elegant solution online and I just know if that interview wasn't cut short I could've tried something like this the third go-round...
void moveZeroes(vector& nums) {
for (int lastNonZeroFoundAt = 0, cur = 0; cur < nums.size(); cur++) {
if (nums[cur] != 0) {
swap(nums[lastNonZeroFoundAt++], nums[cur]);
}
}
}But since I didn't try something like this first, I got passed on. D
It is unfortunately, something that has never -not- been broken. Quite frankly, I don't see that there is a good solution to it either. I have interviewed people for IT jobs of all kinds. Some of the candidates I have selected have been gems, others have been rancid sacks of smelly refuse. The problem for an interviewer, for even someone with a background in the area being interviewed for, is that you can have someone that looks great on paper, and even presents themselves well in interviews, but turns out to be completely ineffective on the job. On the other hand, you can have someone who would be perfect on the job, but doesn't present well. Of course, you also have the people that present well because they really are great on the job. You also have the ones that don't present well because they really aren't good. So in the brief interactions you have with each candidate, how can you possibly determine which quadrant they fit into? It can't be done. It is all the same as in school. There are those who endear themselves to the instructor, and seem to ace every test, but don't really know anything on the subject and couldn't apply it if they tried. Then there are those who just sit in the classroom and absorb the information almost by osmosis, understand it like it was second nature, can apply it, and in some cases even turn around and teach it to someone else; but barely scrapes by with a passing grade, and never seems to get on the instructors good graces. Sometimes there is that one kid that just struggles with everything and gets nowhere, until one day someone gives him the right help. Then suddenly it all clicks, and he gets it all and starts outperforming everyone else. When you sit in a room with these people on a daily basis, you eventually figure out who is who. You'd be hard up to identify them in the first day or two of class. ---------- Money makes the world go round ... but documentation moves the money.
-
This just occurred to me ... JavaScript's Array.sort enables you to use a function to say how sorting is done. All that is needed is a simple function to treat 0 as bigger than non-0.
var data = [ 1, 9, 8, 4, 0, 0, 2, 7, 0, 6, 0 ];
var sorted = data.sort( (a, b) => a == 0 ? 1 : (b == 0 ? -1 : 0) ); // First attempt
var sorted = data.sort( (a, b) => a ? (b ? 0 : -1 ) : 1 ); // Exploits 0 == false, non-zero == true
alert(sorted); -
Yes, but ... it doesn't do it "in place" (part 2 of OP's "test")
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food
-
Does anyone else think coding interviews are fundamentally broken? So like, literally I've been doing this (programming) my whole life. We can all go through our accolades I'm sure, but suffice it to say I've done some things over the years to help rebuild departments in large corporations to garner the attention of regional VPs, etc. as we all have. But, I say this because, two days ago, I had an interview with Unnamed Company That Rhymes With Acelook. Don't get me wrong, they were super friendly, and it was a great chat. But I was asked questions like...
Are you comfortable with writing APIs on the backend?That's a generic question, so of course I say sure. To me this indicates the interviewer doesn't realize the best way to interview. No real probing... just questions like that. Ok, cool. Still was a great, super friendly chat. But, then the tech portion of it came up. I was asked this.../* given an array of random numbers, push all the zero's of a given array to the end of the array
for example, if the given arrays is [1, 9, 8, 4, 0, 0, 2, 7, 0, 6, 0], it should be changed to [1, 9, 8, 4, 2, 7, 6, 0, 0, 0, 0]Example:
Input: [1, 2, 0, 4, 3, 0, 5, 0];
Output: [1, 2, 4, 3, 5, 0, 0];Input: [1, 2, 0, 0, 0, 3, 6];
Output: [1, 2, 3, 6, 0, 0, 0]; */Ok fine... I get how this game works. So, let's get cracking. The first solution I start with used two arrays. Cool, no biggie. But then the interviewer asked for me to do it in-place. Ok, fine. So, I write some code that is like a bubble sort that brute forced it (ie, nested loops). We all know that it sucks to have nested loops. Anyway, the interview was cut short and that was that. I look up the "official" solution online, and it's no better than my first attempt. In fact, my first attempt was quicker due to only one loop. The one I linked to was using two loops that just weren't nested. So, not only did my original solution avoid two loops (using more memory though), but I found a more elegant solution online and I just know if that interview wasn't cut short I could've tried something like this the third go-round...
void moveZeroes(vector& nums) {
for (int lastNonZeroFoundAt = 0, cur = 0; cur < nums.size(); cur++) {
if (nums[cur] != 0) {
swap(nums[lastNonZeroFoundAt++], nums[cur]);
}
}
}But since I didn't try something like this first, I got passed on. D
Totally agree with you. You fail on how to build install a kitchen sink test, but no one in the company installs kitchen sinks. Yep been there.
