|
Are you sure that was the reason you were passed on?
Could it be an excuse rather than to say you were too old?
Anyway I am glad I never had to undergo any test of programming skill in my entire 45 year career as a programmer. When I did change jobs I was accepted due to my reputation.
|
|
|
|
|
dshillito wrote: Are you sure that was the reason you were passed on?
Could it be an excuse rather than to say you were too old?
That's what I was told and I trust them. They were great people. If there was another reason besides that like ageism it would surprise me. I suppose one can never know 100% but I trust them.
dshillito wrote: Anyway I am glad I never had to undergo any test of programming skill in my entire 45 year career as a programmer. When I did change jobs I was accepted due to my reputation.
That's a great point. In this day and age, one must market themselves. It's a skill I wish I knew a long time ago. Better late than never...
Jeremy Falcon
|
|
|
|
|
I was asked that question once....I told them "I've never done that particular function before so I would search for a solution before reinventing the wheel". I got the job.
|
|
|
|
|
I know exactly what you mean. It's fair to put newbies to the test like that and see how they approach a task, and whether they get to the actual result. But asking an experienced programmer is an insult. At the very least they should make sure that the interviewer or whoever else judges your results is equally experienced and able to appreciate what you're doing. And if they don't understand why you chose to approach the problem the way you did, they should be fair enough to ask why you did that, not require you to recreate the exact solution that's on their checklist.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Agreed 
Jeremy Falcon
|
|
|
|
|
Most companies go out of business buy not hiring than by hiring. 30 years ago as a young developer, I bought into the hire only the best of the best. My team would punish the candidate with insane technical interviews. Naturally we did end up with some of the best devs but we rejected a ton of other devs that probably could have done the job.
As an experiment many years ago we changed the hiring practice and if the developer had the basic skills we would sit down talk with them as if they were 'already' on the job. If they participated and started solving problems, coming up with solutions and contributing they were provisionally hired for 3 months. If they worked out during that time we hired them permanently. The results were amazing. Our rejection rate dropped to about 15% and we ended up with some of the best code in the company.
In looking back on the process it is clear to me what changed. When you punish candidates you only get those candidates that are desperate enough or unsure enough of their own skills that they will put up with that abuse. When you talk to candidates as the professionals they are you get a whole new level up interaction and find out what you really need to know. Which only comes down to ONE thing: Will they work with your team and be a contributing member.
|
|
|
|
|
This is a fantastic post and I wish more companies would really see it this way.
It is amazing that your company considered what they were doing to devs in interviews and tried a new way. Very cool!!!
If I just needed some code done then hire the best you can find (which means probably not in-house anyways, just go find someone on the web to do the work).
However, what your company did was to build a real team of contributing individuals where people's input was respected. Amazing.
I'd much rather hire:
1. the nicer / team-friendly / good-attitude candidate
2. who has good-enough skills
3. who is willing to grow and learn
4. who has energy! the desire to make things excellent
I'd much rather hire that person than the "genius" who can pass all these freaking algorithm tests and is obnoxious.
|
|
|
|
|
raddevus wrote: I'd much rather hire that person than the "genius" who can pass all these freaking algorithm tests and is obnoxious.
Exactly... especially when they can't even get the job done because all they study is algorithms and not the tech being used.
Jeremy Falcon
|
|
|
|
|
NightPen wrote: In looking back on the process it is clear to me what changed. When you punish candidates you only get those candidates that are desperate enough or unsure enough of their own skills that they will put up with that abuse.
You sir, deserve a +100 for this statement. It's true. For instance, I know I can run circles around most people with CSS. This is a frontend job after all. But I'd also like to have kids before I die. Life needs balance.
NightPen wrote: When you talk to candidates as the professionals they are you get a whole new level up interaction and find out what you really need to know. Which only comes down to ONE thing: Will they work with your team and be a contributing member.
Agreed. Respect goes a long way.
Jeremy Falcon
|
|
|
|
|
the best i could get is a one liner on the same idea as @raddevus.
data = [1, 9, 8, 4, 0, 0, 2, 7, 0, 6, 0];
for (var i = data.length - 2; i >= 0; i--) data.splice(i, !data[i]).length && data.push(0);
all thanks to JavaScript.
i could have never thought of the solution you found on the internet. it's brilliant.
let's C
int d[] = {1, 9, 8, 4, 0, 0, 2, 7, 0, 6, 0}, *s = d + sizeof d / sizeof *d;
for (int *c = d, *l = d; c < s; c++) if (*c) *l ? *l++ : (*l++ = *c) && (*c = 0);
|
|
|
|
|
sickfile wrote: i could have never thought of the solution you found on the internet.
I honestly didn't find that on the Internet. I really did think of the code myself.
The key to getting to that answer was thinking about the fact that you really just needed:
1. the list of all the values >0
2. the same number of zeroes at the end of the list (which are contained in the array)
sickfile wrote: it's brilliant.
 
Youre one-liners are very interesting. JS does allow you to do some interesting things grammatically. 
|
|
|
|
|
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
|
|
|
|
|
You are definitely one of the Cool Club! You're in! 
|
|
|
|
|
Yay! ![Jig | [Dance]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/jig.gif)
Jeremy Falcon
|
|
|
|
|
Those are good solutions man.
Jeremy Falcon
|
|
|
|
|
I agree 200%. I got so frustrated with interviews; I even got up and walked out on a couple because of the arbitrary-stretched-to-the-point-of-WTF who the hell has used one of those [insert obscure programming theory] in code in the last 20 years. The disgust has been so acrid that I started re-evaluating my career choices.
I got thrown into the deep end of a lot of projects and successfully swam out. No one in any interview asked about that.
I've given interviews and usually just by talking to the applicant inside of a few minutes can pretty quickly tell if the individual is a bullshit artist or not.
|
|
|
|
|
mrmike wrote: I agree 200%. I got so frustrated with interviews; I even got up and walked out on a couple because of the arbitrary-stretched-to-the-point-of-WTF who the hell has used one of those [insert obscure programming theory] in code in the last 20 years. The disgust has been so acrid that I started re-evaluating my career choices.
Amen to that. I've dated a medical doctor in the past... and they never did anything like this to her. This is for doctors. So why is tech held to this standard? Maybe... maybe if it was for NASA... but for most LOB jobs. I mean really.mrmike wrote: I've given interviews and usually just by talking to the applicant inside of a few minutes can pretty quickly tell if the individual is a bullshit artist or not.
Exactly. If you know what you're doing... all it takes is a chat IMO.
Jeremy Falcon
|
|
|
|
|
|
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.
|
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
