|
Agreed. And overall it was a good experience... still makes you wonder why we put ourselves through that in this industry though.
Jeremy Falcon
|
|
|
|
|
Surely the best correct answer is to use std::stable_partition
std::stable_partition(
v.begin(),
v.end(),
[](int n){return n != 0;});
Its an excellent question because it shows you know how to use <algorithm> and won't rewrite standard code.
|
|
|
|
|
I once worked for a company where everyone was a developer (except for two people in administration).
They had about 30 people.
This was from 2014 to about 2017 (just saying, because you may get the idea I'm talking late 90's early 00's).
Before I got to work there I got a questionnaire with questions like "what's the next number/figure in the sequence?", "what happens to a candle and a drop of mercury in an elevator that's going down at a certain speed?"(???) something with a sailboat and wind, one question where I had to make a basic HTML page, and two or three database design questions.
I skipped the nonsense questions like the sailboat and mercury because I really don't know anything about sailing or friggin' mercury 
I somehow made a mistake in the database design, which was unfortunate.
Anyway, I got the job and immediately noticed everyone's knowledge was stale.
They were working on old languages and frameworks, two teams did EVERYTHING in Oracle (yes, EVERYTHING, if all you have is a hammer...), I got across JavaScript code that returned various types from the same 100+ lines function, despite everyone being an "Oracle expert" (they wrote their own Oracle management tool) I got some very strange looks when I asked about JOIN syntax and tracing, etc.
The person who was in charge for keeping up with new technologies only shared the occasional Oracle update (he was in that everything Oracle team).
The few good people all quit, save for one who has a family and makes good money there, although he once told me "my career is going backwards here, I'm currently doing Oracle and Delphi."
I quit because my team was extremely toxic due to some people being stressed out because they couldn't keep up.
I really don't know what their questionnaire was testing, but it wasn't quality in any way.
|
|
|
|
|
Well the interview situation is a pretty good opportunity for you to interview them as well, so...
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
Yeah, that was only my second ever interview so I kind of lacked the courage.
In a later interview I literally said, I'm here to judge you as much as I'm here so you can judge me.
I think that caught them off guard 
|
|
|
|
|
Sander Rossel wrote: skipped the nonsense questions like the sailboat and mercury because I really don't know anything about sailing or friggin' mercury
Ouch.
Sander Rossel wrote: I quit because my team was extremely toxic due to some people being stressed out because they couldn't keep up.
Good move. You'll only end up hating tech that way if you stay in a toxic environment too long. We should be loving our work.
Jeremy Falcon
|
|
|
|
|
Some programming interviews are bad. Others are good. Let me flip the question on you: How would you interview a candidate?
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
That's a great question... I eluded to it in another response, but the gist of what I would do is two fold:
This interview didn't really probe into my experience at all to get a feel for me. Verbally that is. The interviewer did actually go through my resume (most don't) so props to him. I can't repeat enough that both the recruiter and interviewer were great. I'd also ask more questions about what makes them tick as a person. Algorithms can be taught. Personality can't. Work ethic and drive can't.
For the tech side, I'd have basic rudimentary questions to weed out the obvious ones that don't belong (difference between, let and const, etc.), mix them in with tougher ones (what is a weak reference in JS, etc.), and maybe an algo as a bonus.
The reason I wouldn't have a one-and-done algorithm question in and of itself, is maybe that person sucks at them, but they are great at design. It's a frontend job, people gonna have difference strengths. But if you one and done based on an algo alone, you'd never know. It's not the whole picture, especially considering algorithms aren't real world 90% of the time. So, I wouldn't base my entire judgment on them.
Anyway, not to sound sour over the experience. The folks were great.
Jeremy Falcon
|
|
|
|
|
At times in my career I have been in charge of the interviewing.
This is how I approached it:
GOAL: "Can the person fit in with the group, and contribute".
From the resume I glean;
1. I can see a lot of years of experience. (or perhaps "enough" years).
2. I see education.
3. I typically see a list of what the candidate feels is his core skills
(they may not be in a technology that we use, because we are using something new)
4. I invite a few dev's to participate, with the only rule being "You cannot use Google to ask
questions. (If you have to look it up, that is not fair).
5. The Goal is to get a feel for the candidate as a fellow team member.
The Goal is NOT to humiliate, judge, or ask complex algorithms.
I do not ask tech questions of a CS Grad, or post Grad.
Guess what? They might get it wrong. So what? All this proves is you can ask anybody anything,
and they MIGHT get it wrong.
If the Candidate is not proficient it will be revealed.
(Yes, this may wind up as an exercise in futility) -That's ok.
I might even leave him on the team, and adjust to his/her abilities.
For example - they be highly skilled in SQL, and less proficient in Angular.
You are never going to find "The Golden Candidate".
Work Ethic is what I look for. If you can bash your way to learning Angular, that is good enough.
You can spend all your time humiliating people, or you can cut to the chase.
Keep It Simple, keep it moving.
|
|
|
|
|
Well said. You can always spot the folks here who have actual hiring experience.
DumpsterJuice wrote: You are never going to find "The Golden Candidate".
It's like a relationship... there's no such thing as perfect. If you think that you're gonna die alone.
DumpsterJuice wrote: Work Ethic is what I look for. If you can bash your way to learning Angular, that is good enough.
You can spend all your time humiliating people, or you can cut to the chase.
Yeah exactly. Especially when most interviewers just Google stuff to ask before the interview anyway. For systems programming I do think algorithms are important actually. But for most LOB jobs... nope. In the past I've aimed for personality, work ethic, and overall competency. We can always Google the algorithms this day and age if we ever get stuck. You can't teach personality.
DumpsterJuice wrote: Keep It Simple, keep it moving.
Yup. Anyone in this industry long enough knows that devs have the expectation you're not allowed to have a life or family. You're supposed to spend your life 24/7 behind the computer on the off chance someone asks you a question you may not know the answer too. Shudder the thought. It's sad really because those devs rarely learn how to actually work with actual humans.
Jeremy Falcon
|
|
|
|
|
If I am being honest, I incorporate Stack Overflow a lot in my daily work.
If you take away the internet, I don't even have a help file in Visual Studio anymore.
I am going out on a limb here, but its the truth - I can't really code well without access to the internet.
My memory is not what it used to be, when we had no "Intelli-sense".
I used to have to memorize the Parameters of built in Method calls.
Guy come in, says "I don't have Angular experience, but it's because they only want people with experience"
and this one:
Requirements
"10 years Experience in " ( technology that is not 10 years old)
Keep It Simple, keep it moving.
|
|
|
|
|
Everyone Googles stuff though this day and age. What we are expected to know is growing exponentially. Even the younger guys experience things like JavaScript fatigue. It's almost to the point it's getting out of control.
DumpsterJuice wrote: I used to have to memorize the Parameters of built in Method calls.
Same here about IntelliSense. It's ubiquitous as an AC... we'll never not have it in humanity again... like never. Same goes for spell check.
DumpsterJuice wrote: "10 years Experience in " ( technology that is not 10 years old)
Jeremy Falcon
|
|
|
|
|
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!
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
