|
jsc42 wrote: rather than creating something new that may contain bugs.
Exactly 
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: Anyone else agree this is fundamentally broken?
Yes. The answer that I gave some folks a couple years ago was "Please don't ask me questions I can google the answer for."
There was a few seconds of silence.
The question they asked me was something along the lines of "what's an abstract class?" Seriously? I've been programming for 40+ years and you ask me that???
Marc
|
|
|
|
|
Marc Clifton wrote: The question they asked me was something along the lines of "what's an abstract class?" Seriously? I've been programming for 40+ years and you ask me that???
Ha ha ha ha ha ha. I laugh because I know developers who have asked a question like that way more than once. Interviewing is a bit of a skill unfortunately. It's not something that just naturally comes to people simply because they learn to program. Granted, it's important you are technical in one IMO, but you gotta learn the soft skills too.
Jeremy Falcon
|
|
|
|
|
Quote: Please don't ask me questions I can google the answer for
 great line idd ...
|
|
|
|
|
Marc Clifton wrote: "what's an abstract class?"
A lesson where you learn to paint like Mondrian?
|
|
|
|
|
Suddenly I think about "ICT-competences modelling" as a few years ago I participated in a research project on higher ICT education. Indeed I think that most HR "still" do not pay attention to relevant aspects of a "programmer"-profile such as communication capabilities, team skills, problem solving, organizing the work, etc ...
modified 23-Sep-20 11:19am.
|
|
|
|
|
It is annoying when faced with something like this, but it is surprisingly common. In my opinion a programming test should be short, simple and should only be possible to be failed by someone who can not program - ideally you should be able to use it as a springboard for discussing programming techniques.
A lot of people are not good at on the spot tests like this, so this type of interview gets a lot of false negatives.
I guess Acelook can pass over good candidates, because they have a lot of candidates to choose from. Perhaps they use custom algorithms and need every programmer to be able to create them.
One slight point though - your single loop solution will typically be slightly less efficient then the two loop solution, although it does seem clearer what your solution is doing.
Addendum: So when does OG start at Acelook? 
|
|
|
|
|
Fueled By Caffeine wrote: A lot of people are not good at on the spot tests like this, so this type of interview gets a lot of false negatives.
Yeah that's exactly right. It takes time to analyze a problem you haven't run across before. When the interview is cut short... time is not on your side. It's so much easier to spend time working on it when nobody is watching. It's almost to be a developer you have to study algorithms you'll never use and study what you'll actually be doing. Twice the effort for half the gain.
Fueled By Caffeine wrote: One slight point though - your single loop solution will typically be slightly less efficient then the two loop solution, although it does seem clearer what your solution is doing.
Oh I agree. The further up the loop you go in the second solution the quicker it becomes, but still... hard to work against the clock like that for something new. Such is life I guess. Bubble type sorts are slow, but at least they are tried and true... which is why I went that route for the second solution. Given enough time... I'd like to think I could've done better. Guess, I'll have to brush up on stuff I'll never use once I get the job.
Fueled By Caffeine wrote: Addendum: So when does OG start at Acelook?
Dunno... hopefully he'll get me in the door too.
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: ...the quicker it becomes, but still... hard to work against the clock like that for something new...
Grumpy Old Man mode (IE, Wise and Omniscient Programmer Mode): "Is this going to be a mission critical component of the software that will handle hundreds of millions to billions of values in an array, day in and day out? If not, buzz of - ANY solution I come up with for a twenty element array will be finished so shortly after the 'Enter' key is pressed with modern hardware that it doesn't matter. All that matters is getting on to the next thing.
But then again, that probably isn't the right way to butter up a prospective job, although a good interviewer should recognize the truth to your statement and be much more inclined to hire you.
|
|
|
|
|
|
I've had to hire for several firms. I don't think probing technical questions are even the best way to find good developers.
Testing how people think is I think the best approach, but it's not always easy to come up with good questions for this.
If I had my way, I'd be able to give each candidate a simple set of functional requirements and have them produce a small application (like notepad)
then I'd look at the code.
However, in practice, I've never had the opportunity to look at someone's coding style on demand like that. Whiteboarding is one thing, but it only gets you so far.
When I do ask technical questions they are usually things like what is the practical difference between a linked list and a vector just to make sure they aren't totally wasting everyone's time but I can get that out of the way on the phone in a lot of cases.
What I really look for though - and this puts a candidate on a shortlist for me is - do they love to code? Is it a passion? If the answer is yes, I can assume a fair number of important things about them, like that they will throw themselves at a new coding challenge rather than avoid them. The green ones are not always the best project managers, but they typically make solid coders who learn fast. Talent comes from passion, IMO. The nice thing about this, is you can tell. Do their eyes light up when they talk about code, or is it just a job to them? You can almost always tell when someone is really passionate about what they do.
All that being said, I guess it should be obvious that I profoundly disagree with the techniques of interviewers you had. The questions they asked didn't find talent, and didn't really rate your ability. It seems like a poorly executed question attempting to get at the way that you think. And apparently it was complicated enough to trip up the interviewer themselves, which led them to passing over you. It sounds like they think an interview is an attempt to outsmart others and they succeeded in only outsmarting themselves.
Even when I'm in your shoes I'm always the interviewer. The question in my mind when I approach a company is do *I* want to work for you? That has always served me well.
You know what I think? I think you don't want to work for people like that anyway.
I don't think they know how to find talent, so they probably don't appreciate the talent they have. If they did, one of them would have been interviewing you and what happened to you wouldn't have happened. So maybe they can't retain good people. It happens to a lot of large companies. Google and Microsoft work very hard knowing that. Maybe try them out.
Sorry for the long winded reply. I have a lot of feelings about the way the field hires.
Real programmers use butterflies
|
|
|
|
|
honey the codewitch wrote: Sorry for the long winded reply. I have a lot of feelings about the way the field hires.
It's a great post, thanks for sharing. To your points I agree wholeheartedly. I find it's much better to ask them what they study at home and what tickles their fancy the most about tech. You can teach an algorithm to people, but you can't teach personality and drive. Granted, you do need a baseline to ensure the job can be done... but a solution based on a task that's akin to the actual work being done is better than algorithmic questions alone. Or at least ask some technical questions alongside the algorithm test and not just one and done on the algorithm by itself... make it a bonus question or something.
Jeremy Falcon
|
|
|
|
|
Yes, it's nonsense. But, LOB software is also fundamentally broken. Millions of man-hours are spent (perhaps wasted) on software that fundamentally doesn't do anything.
|
|
|
|
|
Interview I mostly bullshit, I totally agree!
Often not done by the people who will work for you but by people who have no clue... with whimsical question either way...
It highlights the following truism
- being unprepared will guarantee you failure...
- being well prepared will leave success to luck...
To edge your luck a bit more one got also to work on social skill and self promotion! :p
|
|
|
|
|
Super Lloyd wrote: self promotion
I think that's the key right there... maybe it's always been this way throughout history. It's certainly true today... if you don't promote yourself nobody cares. Regardless of how good you actually are.
Jeremy Falcon
|
|
|
|
|
Unfortunately life is a bit too much about getting the exact right answer, not on how you get there. 
We've all been there. 
|
|
|
|
|
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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
