Slashdot Mirror
Programmers Are Confessing Their Coding Sins To Protest a Broken Job Interview Process (theoutline.com)
A number of programmers have taken it to Twitter to bring it to everyone's, but particularly recruiter's, attention about the grueling interview process in their field that relies heavily on technical questions. David Heinemeier Hansson, a well-known programmer and the creator of the popular Ruby on Rails coding framework, started it when he tweeted, "Hello, my name is David. I would fail to write bubble sort on a whiteboard. I look code up on the internet all the time. I don't do riddles." Another coder added, "Hello, my name is Tim. I'm a lead at Google with over 30 years coding experience and I need to look up how to get length of a python string." Another coder chimed in, "Hello my name is Mike, I'm a GDE and lead at NY Times, I don't know what np complete means. Should I?" A feature story on The Outline adds: This interview style, widely used by major tech companies including Google and Amazon, typically pits candidates against a whiteboard without access to reference material -- a scenario working programmers say is demoralizing and an unrealistic test of actual ability. People spend weeks preparing for this process, afraid that the interviewer will quiz them on the one obscure algorithm they haven't studied. "A cottage industry has emerged that reminds us uncomfortably of SAT prep," Karla Monterroso, VP of programs for Code2040, an organization for black and Latino techies, wrote in a critique of the whiteboard interview. [...] This means companies tend to favor recent computer science grads from top-tier schools who have had time to cram; in other words, it doesn't help diversify the field with women, older people, and people of color.
Would be a trial (as in free trial). Throw a fairly standard problem at them, but not one with a simple, common place implementation. Drop them at a computer with internet access, give them a couple hours, and see what they have at the end of it. It's not perfect, but it's probably a better way to evaluate skills.
I have interviewed many people and I don't believe in trick questions. Programmers are not supposed to memorize every algorithm. They should understand how to attack and solve a problem. I was always more interested in their thought process rather than if they get the right answer. How they look at the problem is more important
It's not just enough to state that this is a poor interviewing technique and not a fantastic metric to determine job performance. They have to make it about minorities and diversity.
I work with so many programming languages and technologies that I often google simple things as well. I was feeling guilty for it, but after seeing this article I feel a little better.
Thankfully, I haven't been in any "gimmicky" interviews where they look for such trivial knowledge. The way I sell myself is that I can solve problems for you and make you more successful. If the interviewer would rather hire someone who's good at answering language trivia and solving already-solved problems like bubble sort then by all means do so, and good luck!
As for the word problems type interview questions, I really cannot be bothered. I can't say I've ever received a word problem like how do you get a fox and a sheep across a river in a real work setting. Again, you want someone who's good at that then hire them because I don't want to work somewhere with such misplaced values and/or poor interviewing skills. It shows me they don't know what's important to their company.
in other words, it doesn't help diversify the field with women, older people, and people of color.
While there are some good reasons to dislike "code on a whiteboard" interviews, this is not one of them.
How can we continue to believe in a just universe and freedom to eat crackers if we have no ale?
What does this have to do with women and people of color?
Hi, my name is Vince. I interviewed for Amazon, specifically for their PHP API for AWS development team. Despite an entire background of 10+ years of developing front-facing PHP APIs for other businesses, plus having a major part of my code available for public review on GitHub, I failed their interview process because they wanted me to write a specific type of searching and sorting algorithm, by hand, on white-board. This type of code would never have been used on the job, ever. Yet this is what they interview on. The job was to build a PHP API so PHP developers can call basic PHP functions, and the library would translate them over to HHTPS calls to AWS. All of the complex computing/searching/sorting is handled by the existing AWS services.
"Hello my name is Mike, I'm a GDE and lead at NY Times, I don't know what np complete means. Should I?"
Hey Mike, I once worked for the NY Times Shared Services Center. And, generally, no.
It must have been something you assimilated. . . .
Any "confession" along the lines that "hey, when I need to get the syntax of some specific function or language feature that I'm supposed to be proficient in, I have to google for it, look up the Open Group POSIX help page, check StackOverflow etc" is not really a confession. That's the way most of us work these days.
There's always that one guy on the interview team that would rather stroke his own ego by asking a "trick question". 100% of the time it will be either on an obscure function or feature of a language that may be used once in a career, or it will be so poorly worded as to be unrecognizable. I really don't believe that any other profession runs into this problem. With 40 years experience, an extensive resume, 100's of successful projects, I'm still treated like I graduated yesterday and am "tested" on what I know. It's insulting and companies need to stop. I'm at the point in my career that when the "trick question" person hits the white board, I ignore them and redirect the conversation back to the people asking real questions. If you are an interviewer you'll do yourself and the potential hire a much greater service by either presenting them with a challenge you've recently overcome or asking them to narrate one they've recently overcome.
IOW - trick question guy, knock the shit off, you're annoying the rest of us. It is much more important to determine the prospects problem solving methods and skills than their fluency in the programming flavor of the month.
"Show me an example of a program that you wrote and are proud of"
(and then go over the program with them to make sure they understand how it works and why they wrote it the way they did)
The proof is in the pudding.
I don't care if it's 90,000 hectares. That lake was not my doing.
I mentioned a failed interview to a musician friend. She smiled and said she understands completely. "An audition is very different from actually sitting in an orchestra pit and playing along with everyone else, even on opening night."
I've taken that to heart whenever I get asked to write a script on the board during an interview. I get syntax wrong or forget something. But that's how I code scripts. Very rarely does something spring from my brain into a text editor at first sitting. I forget that obscure syntax of bash that will remove a string from a variable when you assign it using % or #. I'll forget the bones of getopts and go back to version I wrote a month ago.
The good interviewers are looking for "how does he think?" The ones that are correcting my syntax or telling me "you could have done this with sort. There's an option for that." tend to be places where I'm probably not a fit. Especially when I point out that gnu coreutils' sort doesn't have that feature.
I did some interviews for a company I worked for a few years back, and my goal for those things wasn't so much to see if they could complete the problem successfully. My goal was to see if I thought the guy I was interviewing would work well with the team. I kept lowering the bar on the programming problem until it was a string reverse, which is just ridiculously simple. Even more so, I allowed the person to do it in the language they felt strongest in. For a couple of the OO scripting languages, that could be as easy as string.reverse(), and I would allowed it if anyone had ever said that. Even so, I was deliberately ambiguous about some things -- did I want the string reversed in place? Were there any error conditions I wanted returned, and should those be exceptions or return values? I had answers prepared, if any of them had ever asked me. I also had a very nice whiteboard, which they would almost to a person go up to and start crapping code onto, immediately. If they'd interacted with me and the whiteboard a bit before doing that, I would have actually stopped them before they'd written a single line of code.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
I'm an employer. I've interviewed nearly everybody we employ at my company. And treating a hiring interview like a rote memory exam is a terrible way to qualify a potential developer hire!
What do programmers actually do? Try testing that!
We do "whiteboard style" for part of our interviews, but only to cover basic comprehension of algorithms. More than anything, we look for basic familiarity with logic structure, and the demonstrated ability to solve problems. Our coding section of our interview process is in the subject's language of choice, including pseudo code, and is "open book" - we want to see what happens when the dev runs into a problem they don't already know! (Critical test: can they come up with a working, supportable algorithm for a problem they don't yet already know an answer for?)
After 20 years of programming experience, I STILL routinely look up the order of arguments for function calls via Google. Who cares to remember when Google has the answer in 0.10 seconds?
Test what the devs will actually DO in an anticipated normal work day and make your decisions based on that.
I have no problem with your religion until you decide it's reason to deprive others of the truth.
Look, as someone who acts as the interviewer, this sound whinny to me. If you cannot handle a simple logic flow for a problem, using pseudo code, then I would not recommend you to be hired. Pretty simple.
Sins, not fetishes.
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
Quick cheat sheets are important. Not everyone can memorize every single library function in every single language they use on a daily basis, even simple functions.
Is it:
strlen(string)
len(string)
length(string)
count(string)
string.len
string.len()
string.length
string.length()
or any number of other variations.
As a developer, I'm sure most everyone knows the task they're trying to do (get the length of a string), but there are so many variations of the same function between libraries and languages, that it is often quicker and easier just to search which one is appropriate for the given language, than to simply type each one out and test the code to see which one doesn't bail on execution.
... I was interviewing a lady for a clerk job at Mobil Oil, where she'd be doing data entry.
I was looking for:
1.) Dedication to accuracy and detail
2.) Willingness to work overtime
3.) Ability to get along with others
She was a single mom who was hungry to work; liked people; her children were almost grown, so she had the time.
SHE FLUNKED THE GODDAM TYPEWRITER TEST!
Typewriter? I told HR I didn't have a goddam typewriter -- test her keyboard skills.
Nope.
That was in the mid-Dilbert years at Corporation.
It little behooves the best of us to comment on the rest of us.
and I don't know what "truth" means. I look up things like "democracy" and "separation of powers". I don't do riddles.
Escher was the first MC and Giger invented the HR department.
These technical interview approaches aren't very good, in my opinion, because they basically assume that the beginning and end of all software development training happened in a second year algorithms class. Algorithms are very cool, I understand why people want to talk about them, but they represent a minority programming challenge in today's world.
Speaking only for myself, in a given month of coding I may only have to consider which algorithms I should use once or twice. The rest of my time is spent on GUI design, communicating with coworkers, working on documentation, and switching between projects. Putting aside the value of algorithms in an interview, how can the interviewer ascertain all of my other software development skills if we spend 2 hours mapping trees on a white board? I would argue that they can't, and by asking technical questions about algorithms or brainteasers, they really aren't properly evaluating the skills of a professional software developer.
This reminds me of one the anecdotes I picked up from one of my college engineering professors in regards to his philosophies on tests:
"Would you fly in an airplane forcibly designed in one hour with no notes?"
And before someone starts busting my balls, yes students should learn the underlying fundamental mechanics of the subject matter. It's more of a protest of the unnecessary aspect of memorizing the details that have no bearing on someone's understanding.
"successful"? no. That's the job of marketing, not the quality of the developer.
"functional"? yes. It should accomplish the task at hand given the parameters required.
GitHub or other online repositories should be one of the highest value markers for any developer. There are other repos out there, but I also like GitHub because it tracks contributions other than just code, such as bug ports and general communication about development projects. It shows how well a person can document and address issues.
As a CS professor, I find the use of these kind of review processes kind of contradictory.
In education, we often based pass/fail on two hours long exams where the student has no access to outside information. Then companies say that's not how the real world works. CS evaluation sucks!
We change to continuous evaluation or project based learning, where student has longer time (well, certainly not 2 hours in a closed room) and can access external resources. You know, like the real world. And now it's companies the ones evaluating candidates the old fashioned way!
Let's go back further in time and go for corporal punishments...
Nothing of course. But this is what passes for journalism in the 21st century.
It's infected just about everything including science fiction. Pointless to argue with them since they are full of ideological fervor for their activism. My relatives emigrated from the former Soviet Union and told of similar stories where you repeated the Communist Party line no matter how ridiculous it sounded.
Was cold-called by someone from Google, so I entertained the invite to interview, partially on a whim. I agreed I would not discuss specifics of interview process or questions, which I'll abide by, by suffice to the theoretical "design a system that..." questions and "how would you..." questions I did fairly well on and felt rather confident about. The detail coding component ended up drawing a question I wasn't all that prepped for (not being something that for me has ever come up in long years of working). So feedback was that due to the coding question performance, it was a no-offer. Which was fine -- after finally seeing SV area in comparison to where I'm happy with in fly-over territory (partly the area, especially cost-of-housing), I probably wouldn't have accepted anyway. No harm, no foul; just not my thing. Still, it wasn't a terribly great assessment of what I know and bring to the table. Local market does the same thing. /shrug
My own team here, we tend to assign a homework question with semi-vague requirements, and then grade on what their experience taught them to also include, in addition to implementation specifics, with a follow-up Q&A ... this seems to work.
If you can't write bubble sort or can't figure out how to get a length of a string in Python, you shouldn't be hired.
Tell us what company you work for so we'll all know where not to apply.
If you can't write bubble sort or can't figure out how to get a length of a string in Python, you shouldn't be hired.
That's probably why I don't apply for programming jobs. I got A.S. degree in computer programming that focused on writing code and not theory. If I need a sorting algorithm, I'll look it up. Most implementations of bubble sort in Python looked like copy and paste C code.
If given a problem to solve on the spot, I would write it in pseudo-code. You can have actual running code when you hire me. I won't solve your problems for free.
Every single day at my work I need to come up with new algorithms. I expect other people we hire to be able to do the same.
Bubble sort is a useless question, exactly because it can be done by rote so easily, but I absolutely expect you to be able to come up with an algorithm for a slightly obscure problem, and write up some details of it. Why? Because that's the fucking job - coming up with the best algorithm to do something.
How does a programming interview discriminate against "people of color"?
Red-black trees I suppose.
How does a programming interview discriminate against "people of color"?
You obviously do not know your algorithms.
Have you never heard of a red/black tree?
. But if you can't code a sorting algorithm without a reference, ... then you don't have the skills I need.
Except for a very small subset of the industry, the only skill you need to code a sorting algorithm is knowing how to type in the search box on google (or stackoverflow). Or know how to call whatever the sort() function is in whatever language you're using.
It's simply not knowledge that's relevant anymore.
I recently had the idea that the next time I'm part of an interviewing process, I'm going to ask the candidates to write a short essay on the importance of a programming principle like DRY or YAGNI. I think someone who understands why it's important and can communicate it clearly is going to write better code than someone who has memorized some technical minutiae.
Programming is not about rote procedure. It is about finding a way to accomplish a goal.
Clean and efficient code is a bonus, but not mandatory. Complying with any else's definition of Good Practices may be a consideration, but only to the ones making the definition. Working well with a carefully assembled maximally-diverse team may be helpful, or may be something to overcome.
In any event, rule # 1 is paramount. Get the job Done. Everything else is value-add, at best.
*Statistics independently verified by Slashdot
You don't know how to get the length of a string in Python? That's OK, provided you don't claim to know Python.
Some people seem to think that they're a capable engineer if they can look it all up on the internet / stack overflow. Sorry, I'd rather fail your interview and hire the guy who wrote the book or the stack overflow post.
Even if you can get the same results, which I doubt, stopping every 5 minutes to read up on core competencies of your job is going to be way slower than the person who is good enough to know it and apply it in the right place at the right time.
I've worked with folks who've claimed there textbook bad code is fine because "I've been doing it that way for 30 years". That doesn't make you a master of your field, it means you're lucky to have fooled management for that long.
Most of the time I've seen this in an interview, and when I've been interviewing, any of that list would be fine. Part of the purpose of whiteboard coding is to see whether the candidate gets hung up on syntax minutiae or whether they focus on algorithms.
I am TheRaven on Soylent News
What I've always found funny about this interview process is that the assumption is always that the interviewer knows the correct answer(s) to the question. It's painful when they don't.
Years ago I interviewed at Google and was asked a question about bit counting (some variation on "given a bit vector, wat's the fastest way to count the number of 1s?"). I quickly answered, "well, if your processor has a population count instruction, stream your vector through that and accumulate the result in a register". Having just evaluated bit counting methods as part of my Ph.D. dissertation, I knew this was the fastest way to do it, assuming the instruction was available (it's not on x86, but is on Power/VMX and most DSPs support it as well).
After I got a blank stare back from the interviewee, I said, "Oh, you were looking for the lookup table answer". We could have left it at that, but he went on to explain using some very convoluted logic how the lookup table would actually be faster than using a dedicated instruction and that my answer was clearly wrong. I mentioned a little bit about the number of cycles required for each approach, but he had none of it. In his mind, I had the wrong answer, even though my second answer was what he was looking for.
It was at that moment that I realized Google was not going to be a good place to work.
-Chris
I don't get the impression most interviewers know what they are looking for. Just like with software, testing in general is hard. You have to understand what you're really testing for and whether your tests actually tests for those qualities and rules out anti-qualities.
I find it hard to take anyone who thinks these coding tests really test for anything.
Those who do not learn from commit history are doomed to regress it.
Code schools aren't the place to go if you want to be a "rock star" at Google or Facebook. These are designed to turn out junior developers, or "apprentices" as they're known at Software Guild, which currently has 16 instructors and 148 students split between in-person and online programs. Students learn just enough to be dropped into teams of more experienced coders and continue their education at a company, even as they draw a competitive full-time salary. They aren't building the high-flying startups; most are simply translating business processes into code, transforming data or helping maintain and update legacy systems.
https://www.wsj.com/articles/a-new-kind-of-jobs-program-for-middle-america-1488114000
Technical expertise is only one part of the whole picture. But it may be the part people thrust into the interviewer chair are most familiar with. Sometimes the interviews feel like a final exam and I wonder if they interviewer had final exams pretty recently.
I have been known to point out these annoying little things to my colleagues when we are hunting to fill positions:
Do the candidates' personalities mesh well with yours? Do you think you can stand being around them and working with them day after day?
Will they be reliable?
Do they seem easy to train? They will need to learn how this group does business and works together after all.
Do they express curiosity when they don't know the real answer?
Do they make things up to fake an answer? Or do they say "I don't know the answer, but based on my experience I would guess this..."?
Do they communicate well? Do they listen well?
Give the guy a piece of code to debug. On screen, using the debugger. Oh, just a snapshot of your code two revisions ago, when you found that nasty bug.
Give them a piece of code written by that one jerk who believed in making his own job secure, tell to clean it up and add comments.
Hand customer's specs, present a couple solutions, "pick the best one, make an case about it." Just stuff collected from a meeting three years ago.
This piece of code is underperforming. Find the bottleneck.
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
Typical SJW hijack. Occupy Wall Street went down the crapper the same way.
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
My uncle told me about a Boeing interview process one time. They would put candidates in a room together and give them an engineering task/problem to solve. At this point, they'd already vetted them for knowledge/competence.
At first, the candidates would talk and do the chit-chat thing, who's who, background, blah blah blah. But at some point, one would push back his chair or pick up the notebook with the assignment or get up to the whiteboard and say something like "Well, let's get on with this thing."
That was typically the end of the interview. Of course they'd still observe the candidates as they worked on the project, but that bit of leadership was primarily what they were looking for.
Because of this, and stories like it (such as TFS), I intentionally go to interviews unprepared. My intention is to present them with the "real" me that they are more than likely to get. I don't want to present the best of me, because they won't get that all the time. If asked why I am not more prepared, I will answer with exactly this. One could argue that this IS being prepared...
I have had only one interview out of my last 7 (spanning the same number of years) that didn't return a job offer.
I think that "find the bug" questions may be more relevant.
From the IT side of the house, I can say I've been there. In the development world, it's the whiteboard test, but in the IT world it's a tool-matching exercise and trivia contest. I freely admit that I have a very bad memory and constantly look up information unless it's actively used in my daily work. I feel the field of IT is too broad for one person to remember even the basics of _everything_. I've failed interviews because I couldn't recall some trivia questions, and I've done well on others when I was given the chance to demonstrate skills I'm comfortable with. Worse yet, I've gotten shut out of interviews because I haven't used the exact brand and version of some tool they have in the toolbox, regardless of how easy it is to pick up on the job.
In an IT context, matching a laundry list of tools, platforms and software isn't going to get you the right candidate. I hate to self-promote, but I've been told by many employers that the reason they like me is my willingness to dig in and learn new stuff, then document what I know and teach people before moving on to something else. One example I like to cite is that this is essentially the 4th time I'm relearning Citrix XenApp at a level deep enough to do a new deployment -- when this is done I'll get assigned some other project working with a completely different tool set. Some people in our field are experts in Foo but not Bar, or worse yet, specific Foo 3.6.1 experts. There are products that I work with daily (Citrix XenApp, SCCM, etc.) that are easily full time positions, and are so complex that people get to be tunnel-vision geniuses on them. Same goes for platforms -- there are Cisco configuration and management experts who go so far down in the weeds that they can't see things like SDN and hybrid network gear slowly taking over. They'll continue to get paid a lot for quite a while, but eventually the contracts and FTE positions will dry up as the product is phased out. Look at how different a typical SAN engineer's job is these days compared to the times when you had to be an EMC or NetApp savant to get things functioning.
If you're looking for someone fresh out of school, the whiteboard interview is only going to get you a sense of whether or not the candidate absorbed basic concepts from their computer science degree. In IT, most of us don't come from CS and end up here because we're crazy people who like complexity and troubleshooting/firefighting. Smart employers recognize this, but often you get programmer-style interviews when you are trying out for a spot at a software or IT services company.
One of the reasons that we teach sorting and searching algorithms is that a huge number of complex domain-specific algorithms include a step that is either searching, pre-sorting, or both. If you don't understand these steps well then you won't have the tools to do a good job at the more complex parts of algorithm design.
I am TheRaven on Soylent News
You're right - the fucking job is writing code to accomplish the business' goals in an efficient manner. The business' goals in this case, are to produce tools for users that work reliably, fast, consume little memory, consume little power, etc. Writing good code absolutely is a requirement to meeting the business' goals. If you don't want to write that kind of code... well, that's why I'm rejecting you in an interview. That's why the business trust's my (and my colleagues) take on who's a good hire - because they trust that we understand the kinds of qualities needed to do the job well.
I haven't done any sort of actual programming since my original undergrad almost 20 years ago, needless to say I never went through an interview like this. As others have mentioned, the expectation likely isn't to get the person to write a perfect program during the interview. It is to evaluate their thought process, ensure they do actually have the skills they claim to, and see how the person can react to a pressure situation.
If I were the interviewer, I would hope the individual would first discuss logic with me. Then I would ask them to show me. Finally we'd talk about what they were able to get on the board.
If the company's intention was simply a straight coding test, do you think you'd honestly be happy there anyway? Sounds like if the interview was stressful actually working for the company would be a nightmare.
"Action without philosophy is a lethal weapon; philosophy without action is worthless."
Pretty much, just like finding the circumference of a circle is just plugging the radius into pi*2r. You don't need to calculate pi, or derive the formula yourself, only know that it exists and how to use it.
Experts know that it is almost always better to use the sort from the language's library, and if they can't then they would look up the code for Quick sort and use that.
Log in or piss off.
Do you grill a Lawyer on case law from the 1920s during an interview?
Often require a CPA to cite tax code from 1972 in order to apply for a job?
Perhaps we should just whip out the State Bar or CPA exam instead, you know to find out who's really good, since dredging up history and concepts you left in undergrad school seems to be the name of the game in other fields...
When I was interviewing for my current job I got asked one of these types of questions. I was honest with the interviewer, I told them I had a vague understanding of the concept, but I'd have to look up or ask someone how to actually implement it since it's not something that I'd ever done before. I figured I had nothing to lose by being honest since I wasn't going to be able to BS my way to a solution anyway. The interviewer appreciated my honesty and said that collaboration and being able to find solutions to problems you don't have the immediate knowledge to do were important and I eventually ended up getting the job. I'm not sure if that's what they were actually looking for or if they liked my other skills so much that they were willing to overlook it. To this day I've never come close to having to program what they were asking me to do in that interview.
Analogies are cool and dandy, but miss the point by far.
There are IT fields where you simply don't have to use specific algorithms for years. Hell, maybe even decades. Now you go on a job interview for the exact same field and interviewers throws around big O notation and critical system-level optimization questions, and obviously, even the non-Ivy league freshman who knows those like the back of his hand is gonna destroy any decades-experienced programmer.
Give the average dedicated programmer an internet connection and he'll get 90% of most needs sorted out, in reasonable time at a reasonable rate (in contrast to the industry), and here's the kicker: even if he never actually touched the subject at hand. Most people don't have photographic memory, and most programmers don't actually need it. Most certainly don't need it as much as experience, but man do they like to act like they do in interviews these days.
You did get the bubble sort being trivial part partially right: it is so trivial I actually have never written a bubble sort snipet ever, in my life, even managing to avoid it on most college assignments simply by going another work topic, or focusing on other exam subjects and still get an above-average mark. I happen to know the algorithm for one sole reason and that is I glanced at it for subjects college. And I work in a field that is as general as it goes.
Examples for wanting Rachmaninoff or Kasparov (them Russian geniuses...) expertise levels for IT are so remote they actually involve remote locations: programming in Africa or any region with a slow/non-existing internet connection. Or if I owned such a level of a sweatshop I couldn't allow my devs to lose 5min looking up common tasks through online APIs or programming communities. Also, did you notice all the fields you mention are actually very "like what you do" dependent? Most if not all "virtuosos" on board games, sports, music or theoretical (non-applied) STEM actually love what they do, not every coding one does, as this post actually proves it. Coding isn't a skill most of us like bringing home, it's not like it is a good party-conversation topic. I actually avoid making public I work in IT so people stop nagging me for all their computer basic needs (and other reasons, we all know the field is tainted socially). We charge our employers a fortune per hour and it would be insulting for them to provide such services to acquaintances for free.
I wrote bubble sort about 30 years ago ... in BASIC.
I probably re-implemented it in Pascal when I took that class. It probably came up again in C, FORTRAN and Java courses. I might recall an example in a learning Perl book I worked through ages ago. Even in those days, the instructors/book pointed out that the implementation of bubble sort was being used as a ready example to teach the constructs of the language, and that sort implementations of the respective language were far more sophisticated and optimized, and should be used rather than rolling your own.
Same thing with rolling your own command line argument parser, math functions, date/time functions, etc ... don't. Learn how your language does those things and use the provided algorithm. It's far more likely to have less bugs than the thing you just made up, especially for a well-established language.
It's more like asking an expert pianist to tune a piano. Yes, some can, and that's great. But others can't, and it's usually not relevant--because you usually hire a piano tuner to tune the piano. Just like how you really should use an existing function for sorting.
I wonder if it hasn't gotten this way simply as a synthesis of multiple agendas and their outcomes.
Management wants to hire the cheapest possible talent. For a while, they achieve this goal, and the staff mix shifts towards less talented people. Productivity expectations don't go away and the more experienced/better staff shoulder the burden.
Management notices (perhaps even having to fire some quantity of cheap staff for obvious gaffes and lack of productivity), and listens to the chorus of "hire smarter people". So the interviews get harder, with the idea that this will allow smarter *and* cheaper hires.
This works to a degree, but now the more experienced people are somewhat threatened by an influx of smart *and* cheap staff. So the interview questions get much harder and more unrealistic under the guise of ever-smarter people requirements, but the actual goal is just raising the bar so that you wind up with really smart people but too far out on the spectrum, deficient in the soft skills that would allow them to rise in the organization. The old hands gain talent that eases the workload but greatly reduce the risk to their own organization standing.
Even if none of this is true, it still seems that an obviously flawed hiring process like this has to be a byproduct of agendas other than simply "hiring the most capable people". Still I think cost and self-preservation are probably large factors in these processes.
Well, it's very brave of them to confess to their "Coding sins", but that doesn't mean they won't face the repercussions. This is Donald Trump's America after all.
"Don't know what np complete means? Deport him back to Mexico!"
"What? But that's ridiculous, I'm not even from Mexico"
But if you can't code a sorting algorithm without a reference,
You're missing the point.
I agree, that if you can't jot down a simple sort algorithm on a whiteboard you're probably not much of a programmer. That's not what's being asked here.
The issue here is being expected to memorise Knuth from cover to cover (ISTR there was a whole volume on sorting and searching) so that you can regurgitate [insert name of reviewer's favourite sorting algorithm] on demand without thinking - because any moron with time on their hands and a high boredom threshold could do that. It's a lazy assessment technique that gets used because the interviewers don't understand the job they're interviewing for so if they asked a sensible question (like here's a problem - how would you begin developing a solution) they wouldn't be able to understand the answer.
The correct answer is (a) use whatever sort() function the language provides (or change the database query to get a sorted list to start with), because its probably better than anything you could pull out of your arse in 60 seconds or (b) if that won't do, ask "why not?" and spend an afternoon researching sorting algorithms & libraries to find something that meets these oh-so-special requirements before, as an absolute last resort, writing your own.
A better solution would be to give them some broken code to debug - that would separate the persons from the other persons....
In a survey of 100 programmers, 111111 thought that duck-typing was a good idea.
Freefont uses bubble sort for sorting edge contour lists during rasterization. It is extremely well suited to the problem, as most sequential scan lines do not require a sort, making the algorithm an easy-to-optimise order validator. Further, most situations where a sort is required occur in localised pairs (from edges crossing) making the algorithm very efficient.
I personally steer clear of 'smart' answers in interviews. The more experience you gain, the more you come to appreciate the limits of your knowledge.
I get what you're saying, but I find that phrases like "expert [language] programmer" have so much room for interpretation as to be utterly meaningless.
I am very, very good at what I do. Part of what makes me good at it is setting up a system that allows me to respond to needs very quickly and accurately. As an example, before I was hired it took days of coding and testing to on-board a new customer. Because of the templates I have built, and the system I designed for testing; the whole thing can be done in three hours. Now could I write executable code on a whiteboard for that? Hell no! That's what I built the templates for, so I don't have to memorize syntax! I can instead focus my energies elsewhere. If I had to call upon a magic fairy to tell me the syntax of every line of code I've ever written...so what? The job got done on time and my company benefited greatly from it. I don't need the answer to every question, I just need to know how to get it, test it, and put it into production.
I could talk about how I've laid out my code, the workflow of it, the ease of maintenance, and why I made the choices I did, etc. I think that is valuable information on a perspective hire. I would think my body of work, and who I did it for would speak loudly enough for my abilities, and that's why I was being interviewed. If someone called me to a white board, I believe I'd politely tell them that the coffee was great, but no thanks. I don't need you. I don't have any deep-seeded need to bring what I do to your company. You need me, that's why you called me; and now that I'm here, I see you're unsure and you've wasted both of our time. You wasting your time is of no concern for me, aside from the fact I probably don't want to work for an organization like that. You wasting my time just pisses me off.
I'm sorry, but your opinion seems to be wrong.
Whiteboard coding questions aren't bad in and of themselves. The real problem is bad interviewers who don't know what's realistic in an admittedly artificial interview situation. Questions that require rote memorization should be obsolete today. Common flaws include:
* Requiring perfect syntax off-the-cuff
* Requiring exact names of library functions
* Asking questions that have just one correct answer (because a wrong answer tells you very little)
A good interviewer can run a beautiful coding interview on a whiteboard, keeping the candidate engaged and displaying his/her skills. You run it like an ongoing conversation with the candidate. If they hit a wall or don't remember something, you simply give them a hint or even the missing answer so they can continue. The end goal is to make the determination: does this candidate know what the hell he/she is talking about, and do I want to work with him/her? The end goal is not to determine if the candidate can take the length of a string in Prolog.
I have personally trained hundreds of technical interviewers in these skills. The problem at many companies is that nobody evaluates people's interview skills and separates the good one from the bad ones.
You can find developers who can say this?
... how can you be confident it was them?
And those who can
process is even worse. Many large companies pro grammatically review resumes looking for the mention of skills listed in their job requirements. The job requirements list 50 different skills as required and the expectation is that the resume will also list those same skills. Well, I am an experience programmers and I don't have 50 skills and I doubt anyone does. So now only people willing to lie on their resumes get job interviews. That is ridiculous.
David Heinemeier Hansson, a well-known programmer and the creator of the popular Ruby on Rails coding framework, started it when he tweeted, "Hello, my name is David. I would fail to write bubble sort on a whiteboard. I look code up on the internet all the time. I don't do riddles."
I don't buy the notion that someone with a CS degree cannot implement bubblesort on a whiteboard, regardless of real life accomplishments. With that said, his last sentence (I look code up on the internet all the time), that's the motto I live by.
Someone asks me how do you call function X on Y api?, and I'll answer that's what google is for, I don't memorize minutia. And I'd walk away from an interview that requires me to code something non-trivial without an internet connection. I'd work on a whiteboard to illustrate my problem solving skills, but ask me minutia or expect me to code without a reference?
Nope, I'm out. Life is short, there is plenty of game out there, and I'm too old for this junior level game playing shit.
I doubt that companies that want to do the old "Surprise! Write code with no reference materials to do complicated task X" are interested though. On a previous job I was allowed to interview by my manager for potential hires into the group and I would give people a simple problem and ask them to vaguely verbally describe a way to resolve it, like to take a file of names in first name, space, last name order that was sorted on first names and produce the same type of output (first name, space, last name) but sorted on last names. I just wanted to see that they had some kind of logical process to resolve this kind of issue. Something like using the right arguments to Unix/Linux sort to do it, use AWK or Perl to sort the 2nd field alphabetically, etc. were good enough answers. I remember in those days that recruiters would flood us with a bunch of unqualified candidates (it was a sys admin type job) and we got annoyed that people would say on their resumes that they totally knew Unix/Linux but we'd interview them and find out they didn't. So we started asking candidates "What command do you use on the command line to delete a file?" and got rid of the ones who couldn't answer that. That worked pretty well at the time. So I do get that they are looking for a certain type of employee and trying this as a way to find them.
However, the kind of people who are totally geeky enough to pass these types of tests do not always make for great colleagues. I know a guy at work who is now in a different department who would ace this kind of thing and he is smart but he is also super challenging to deal with in person. He's been given permission to work from home pretty much all the time because he's so challenging to deal with in person. I remember another really good programmer who one time disappeared for like a week with no word to his office. His manager had a couple of guys from work go to his apartment and they expected to find him dead. They knocked on the door and the dude answers. Told them that he hurt his ribs. He didn't bother to call work or his manager about it. Just didn't show up to work. So yeah, these are the kind of guys who pass that kind of test.
I've interviewed people for software jobs whom I thought HR had screened but who turned out to be useless. How do you establish competence with seeing how they handle some basic computer science questions? It's only a bit of white-boarding, not water-boarding.
Likewise, if you're an expert programmer, you should be able to write bubble sort on the whiteboard without a web search.
Who actually uses bubble sort on the job? Bubble sort is one of those algorithms that you should see roughly once in your career—in an introductory Algorithms class as an example of what not to do. As simple as a bubble sort may be, if you've been programming long enough to earn the title "expert" I think you can be forgiven for forgetting the details. For that matter, unless you've been doing bare-metal systems programming, best practice in almost every case is to use a standard library function rather than writing your own sort routine. The average expert programmer working in a high-level language has very little reason to reimplement any sort algorithm in the course of their professional work, though most should at least be aware that there are multiple reasonable sort algorithms, and that the proper choice depends on the task at hand.
A better interview task would be to compare and contrast some of the more common algorithms and give examples of situations where each would be suitable. I wouldn't expect bubble sort to make the list, but given the pseudo-code for a bubble sort I would expect the applicant to be able to reason about its time and space complexity and articulate why it would generally be a poor choice compared to the other options. (The only possible exception I can think of offhand, for bonus points, is where the array length is known to be trivial and you have a really pressing need to minimize both code and stack size, but even then it's a close call.)
Speaking as a Sr. Software Engineer with at least 15 years of professional programming experience, while I would be able to write bubble sort, merge sort, and quicksort by hand without a reference, I can't recall any instance where I actually needed to do so as part of my job. The implementation details are inconsequential trivia compared to knowing that quicksort is best for mutable data structures with fast random access, while merge sort is more suitable for immutable data structures or data too large to fit in RAM.
"The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
The point of an exercise like implementing a bubble sort algorithm is not to do something that you are regularly going to be expected to do on the job, the point is to test whether or not you have the necessary skill to figure out how to solve such problems on the spot even if you *DON'T* remember how, exactly, it might be implemented. Trivial algorithms such as bubble sort or merge sort are really good benchmarks in this regard because few programmers bother memorizing their exact implementation, and most skilled ones can spontaneously reimplement one from a general recall of only certain key points about the algorithm.
If you can show that you know how to solve problems that others might have already done, without having to depend on other people or other libraries to do all the work for you, then you have demonstrated at least having some of the skill that is generally likely to be highly transferable to solving new kinds of problems that nobody else has encountered before. Due almost certainly to the time constraints of an interview, they aren't likely to ask you to implement an algorithm that you might be expected to do on the job in a programming interview.
The answer to your question would therefore be at best a simple "no", and at worst, "thank you for your interest in this company, we hope you find success elsewhere".
File under 'M' for 'Manic ranting'
I have tools for that.
When I went back to community college to learn computer programming, we had to learn all flavors of Java because there was no money in the budget to renew the Microsoft Visual Studio site license to teach C/C++. The dean wanted to teach C/C++ on Linux, but the powers to be overruled him as surveyed Silicon Valley employers insisted that C/C++ programmers must know how to use Visual Studio as a tool. When the site license got renewed, none of the computers were up to spec to run Visual Studio .NET when it first came out. After the computers got upgraded, I took C/C++ as my last class before graduation.
Sorry but if you don't know algorithm theory you don't know how to evaluate the code you are writing.
I don't see why knowing the "len" function is so important. Does remembering it off the top of your head allow you to do something that looking it up doesn't? Some people just don't fill their heads with useless trivia.
Interview casually and friendly, by credential review, experience review, and conversation about current issues and trends and technologies in the field, with some open ended questions designed to probe for technical insight, comprehension etc.
Then take your shortlist of candidates after that, and code review a (preferably non-trivial) github repo that they are the originator of or the major contributor to.
Look for clarity of the "what the hell is this all for" commenting that comes with the project, as well as good header commenting, good method, variable and class naming, good code factoring etc.
That's it. No FOSS projects? Ask them to re-apply later.
Where are we going and why are we in a handbasket?
Let's all be honest here... when was the last time you did anything other than use a sorting library. While I know what a bubblesort is, moreover I know it's the least efficient sort... shouldn't that be enough?
Yes Francis, the world has gone crazy.
The length of a string in python is determined with the "len" function. If you don't know this, you don't know python, end of story. If they are looking for a python programmer, you're out.
If you only work with one or two languages, maybe. If you're trying to remember which syntax between Python, Java, PHP, VBScript or Javascript, then Googling is faster than recalling that slow-buried memory.
To continue your analogy, it would be like asking a piano expert to compose a 6/8 waltz with a G progressive chord structure with a minor chord on the 4rd beat of even measures that resolves to the tonic on by the 6th beat in the style of Mozart. And compose it on a whiteboard without a piano.
Yes, this is technically possible but I would argue the ability to complete such a task has zero to do with one's ability to compose or play music that would become popular. I remember a conversation where a music theory professor raves to John Lennon about the technical names for all the obscure chord voicings he uses and how he uses them brilliantly where John just laughs and says something like "I don't know what you're talking about, but I think it's a compliment. Thank you"
-- Political fascism requires a Fuhrer.
So, no.... they do not.
File under 'M' for 'Manic ranting'
Sorry but if you don't know algorithm theory you don't know how to evaluate the code you are writing.
I know code well enough to know when a sort algorithm is required. As for the implementation details, I can look it up.
https://github.com/Sayan-Paul/Sort-Library-in-Python/blob/master/sortlib.py
But if we think of an analogy as being like painting a picture, it becomes obvious that for most tastes a fine brush will perform better than the Jackson Pollock-technique, but as for a left-handed pianist with paint on his shoes, contemplating the quick sort algorith-- well, who can say?
I'd like to think this sort of thing will make a difference but I'm afraid any positive efforts will just be totally overwhelmed by the sheer numbers of incompetent/clueless HR departments that habitually outsource to even more incompetent web-based companies that claim to reduce applicants skills to a single score through automated tasting based on badly worded/ambiguous coding questions etc.
That's complete BS. A piano player as part of his skills has to play music from memory by definition. There are entire tutorials available describing strategies to memorize music.
As a programmer I am never asked to randomly crap out code on a whiteboard as part of my duties. Why should I do this in an interview?
love is just extroverted narcissism
It's called an internship. And it's the reason getting hired straight out of school isn't so hard...
It would be cool the do the same with other candidates. Maybe one could try to contract people for a month before hiring them.
I wrote shell-sorts in Pascal, myself-- almost as easy to write as a bubble sort, but way better performance-- but you'll note that our slashids are lower than his.
If we're still supposed to memorize stuff about sort algorithms, long after the need to *write* sort code has evaporated with my old decks of Fortran cards, then we had better have some reason to think that we get some benefit from knowing these algorithms.
The pretense that they're the F=ma of programming is just pretense, a matter of hand-waving.
(Why isn't circuit fab and transistor technology regarded as "fundamental" for programmers? Isn't that what the field is based on?)
Give the guy a piece of code to debug. On screen, using the debugger. Oh, just a snapshot of your code two revisions ago, when you found that nasty bug.
Give them a piece of code written by that one jerk who believed in making his own job secure, tell to clean it up and add comments.
Hand customer's specs, present a couple solutions, "pick the best one, make an case about it." Just stuff collected from a meeting three years ago.
This piece of code is underperforming. Find the bottleneck.
I like these. I wish I was allowed to use them at my current job.
Socialism: a lie told by totalitarians and believed by fools.
Likewise, if you're an expert programmer, you should be able to write bubble sort on the whiteboard without a web search
If you're actually an expert programmer, you know that writing any sort of sort by hand is an utterly stupid thing to do. It's additional code you have to write, test and maintain that gains you nothing.
An actual expert programmer calls sort() and goes on to the parts of the problem that are not implemented in a library.
If I'm hiring someone to program mathematical algorithms I'd want them to be able to prove the circumference of a circle is 2*pi*r because that means they understand what pi is. I would want them to be able to give several derivations of pi, and if the job were hard enough how to prove pi is transcendental.
The issue here is being expected to memorise Knuth from cover to cover (ISTR there was a whole volume on sorting and searching) so that you can regurgitate [insert name of reviewer's favourite sorting algorithm] on demand without thinking - because any moron with time on their hands and a high boredom threshold could do that. It's a lazy assessment technique that gets used because the interviewers don't understand the job they're interviewing for so if they asked a sensible question (like here's a problem - how would you begin developing a solution) they wouldn't be able to understand the answer.
I've had dozens of interviews in my career. The few times I've run into that, it turned out the shops were terrible places to work - failing such interviews is not a problem unless you're really desperate for work.
Socialism: a lie told by totalitarians and believed by fools.
Of course. But do you know which sort algorithms are required when? What the tradeoffs are? Since we are talking AWS how various algorithms decompose with out of order execution or on various configurations of network speed, disk speed and memory? Etc..
You can look all that up. But if you need to look it up then you don't know algorithm theory.
When I interview, I ask about the work you've done; if you can't give me a clear, cogent explanation of what you worked on, what it did, and how you did it, that's a negative. The rest is general conversation. If you can't bother to ask a slightly insightful question about what we, the employer, do, or how we do it, that's a negative. If you can't perform some simple personal grooming before showing up, that's a negative. I don't care if you know how to fizzbuzz, because I know you can always look it up. What I want to be sure of is that you have the ability to ask the right questions about the tasks you will be given.
Mission: To provide products that consume time and energy as entertainingly as permitted by the laws of thermodynamics.
Experts are only like you describe them with work they do more or less daily.
On my business card is written: software generalist. Because I have worked in nearly all areas that interest me, be it business wise (power companies, heavy industries, embedded autonomous car driving systems etc.) or task (trainer, mentor, Systems Analyst, Requirements Engineer, Dev Ops, Systems Administrator, Operator, Scrum Master, and plenty more)
I'm good, because I forget everything that I do no longer need. And reinvent it when people have a problem in that area and ask me. And your example regarding "working with strings" is plain wrong and arrogant. In a modern IDE the code completion makes 50% if not more of the work. When I program half a year with a certain library, you can be rest assured that I know far less about that library then I would have known 20 years ago, where the IDEs where much worse.
Trust me: when I have to use vi and bash, 50% of my time writing software is spent on forums like stackoverflow. But as my software usually runs better and I'm often still faster than the people I replace ... no one cares. I know plenty of things "not to do" in nearly all areas of IT and software, but plenty of things I simply forgot how to do them ... I look it up and can usually apply my knowledge immediately especially as I spot the wrong answers on the web more or less immediately.
When I started reading this article/thread I had guessed I would perhaps need an hour to write Bubblesort from scratch. But only writing here gave me old memories back so I could probably cut it down to 10 minutes now: on the other hand I'm already 60 minutes here on /. ;D
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
If you're an expert pianist, you ought to be able to reproduce a simple tune on the piano, by ear and blindfolded.
You'd be surprised how many very, very good pianists can't do this, because they've spent all their lives reading music instead of listening.
"First they came for the slanderers and i said nothing."
If you're an expert pianist, you ought to be able to reproduce a simple tune on the piano, by ear and blindfolded. If you're an expert skier, you can ski backward and ski on one ski. If you're an expert chess player, you should be able to memorize any chess board at a glance. If you're an expert mathematician, you should be able to do simple integrals without reference tables. Those are not skills that you need, they are skills experts simply can't avoid acquiring as part of working in a field for many years.
Likewise, if you're an expert programmer, you should be able to write bubble sort on the whiteboard without a web search. If you're an expert Python programmer, you should have worked enough with strings so that you don't need to look up trivial functions anymore. Those skills are indicators of your experience, not specific job requirements.
Plain and utter nonsense. All the skills you mentioned above are acquired by repeatedly doing a move or a task over and over again. Programming is doing the exact opposite and having the machine do the repeating - if you are a good programmer. Memorizing bubble sort is beyond pointless for a seasoned programmer. To the contrary, if you can still recall bubble-sort, you're probably not that seasoned yet.
If you test problem solving in a job interview for programmers, you're good. If you're testing for by-heart reference knowledge, you're being silly. Perhaps the nearest equivalent would be to test how fast a programmer navigates his favorite development environment. That might actually be a useful test, vis-a-vis asking for him/her to recall bubble-sort in PL X,Y or Z.
Bottom line:
You got it totally wrong and missed the core and prime difference of programming to performing arts, sports and whatnot.
We suffer more in our imagination than in reality. - Seneca
CS geeks like to ask CS trivia questions to make sure no one with the "wrong" background gets in the door. ("No, I don't know how to write a binary sort algorithm off of the top of my head, I use existing code for solved problems.")
This Google-inflicted problem is a huge improvement over the old Microsoft dominated days when "the cult of the puzzle" loomed ("A priest, a vampire and Richard Stallman all need to cross a river, but they have only one wind surfer, the vampire can not ride with the priest, and the priest is a Windows user, so...")
The only job interview-style that I actually like is "Get out your laptop, here, can you write code to do this?"
Even that has drawbacks though-- you could exclude a competent programmer that doesn't own a laptop, for whatever reason...
in an introductory Algorithms class as an example of what not to do.
That is wrong. I suggest to check Wikipedia, facepalm.
I can't recall any instance where I actually needed to do so as part of my job
I guess that is true for nearly everyone here.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
We could always keep an old motherboard and sound blaster card around, and have interview candidates move jumpers around till the correct sounds come out. Probably about as relevant as re-implementing bubble sort, and as relevant to a modern software job. :)
FWIW when I interview candidates I far prefer to get them to whiteboard/pseudocode a solution to a real problem that we have faced recently and how they would have approached it. I stress that I'm not looking for a "correct" answer, I want to simultaneously give them an example of the problems they would actually face on the job they are being hired for (so they know what they are getting into), as well as for me to see how they develop a solution and then have that solution critiqued by someone. The interface of the whiteboard is preferred since it gets passed the "you don't have my OS" and "you don't have my editor/IDE" problems and gets right to the thinking, which is what we are ultimately hiring them to do. In today's polyglot programming environment, the thinking is key.
I also put a high value on asking about how they interact with others, how they document their work, how they interrogate a spec, how they write a spec or make a design given a desired feature and how they write tests. Writing code is one part of the equation. In our organization, unit tests are required and you need to interact with a quality person to get other system tests sussed out. We also have doc, marketing and customer facing technical and marketing people who developers interact with on product teams on regular intervals. Code reviews can be quite rigorous (although not cruel -- there's a difference -- but you must know your code).
It's important to find people who can deal with that environment AND deliver good code, far more important than finding someone who memorized bubble sort.
I always ask technical questions, but never "trick" questions or really hard ones. If you ask a FizzBuzz-like question, there's no reason anyone needs reference material and it separates most of the fluff that apply for programming jobs right away. There's no way I'd ask for a bubble sort or a binary-heap-blah-blah-blah because I wouldn't be able to answer it. But you *must* ask technical questions in an interview.
"I have never let my schooling interfere with my education." - Mark Twain
Since we are talking AWS how various algorithms decompose with out of order execution or on various configurations of network speed, disk speed and memory?
AWS is just a bucket for storing my website assets over the Internet.
But if you need to look it up then you don't know algorithm theory.
I don't use sort algorithms for 99% of the code I write at work (IT stuff) and home (web development). I know how to implement binary and bubble sorts. If those don't do the job, I'll look for something else in the "Mastering Algorithms with C" book. ;)
Some software companies, like some painters, are successful through making horrible, under-performing software that happens to work. Likewise some horrible programmers end up developing great code that works even though they don't use best practices. Quality isn't on the product, it's on the audience.
Granted, chess and the other stuff are highly analytical, and in the end, skilled strategists are prone to rank up elo, yet even in chess the elo system is not fail-proof.
But get two guys in front of an internet-connected laptop: one who has been winning programming contests the past 5 years and an industry veteran developing for the web the past 5. Now tell them to build a simple, native mobile app in 1h with multiple features that take 3 hours to make together, without restricting access to any source material as long as they don't flat out copy-paste core functionality. Who do you think gets farther in the allotted time? I'm pretty sure it's not the whiz-dev.
And most people use for that the database.
Then you have the data already in memory in the way you later want to "walk over it".
As others have pointed out: doing stuff like this by hand, is no longer relevant. Probably since 20 or even 25 years.
It helps to learn stuff like this in university, as plenty of other stuff is build on top of it, but the requirement to code such algorithms, sorry ... never experienced that outside of the university.
In other words: the requirement only exists if you are a contributor to the STL or boost, or similar libraries.
I guess the only ones who touched such topics are the big data guys from Hadoop/Spark, Casandra etc.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
I spend actually very little of my day doing actual code, that's the fun part. Design + tests takes most of the time.
Most of the job is actually architecture, not implementation...
I am a notoriously poor interview candidate because of all this stuff. I don't spend my work days memorizing algorithms or other stuff that can be looked up elsewhere. What I bring to the table is someone who can find and solve problems. Basically what an engineer does.
What I look for when I'm on the other end of the table is someone's thought process and how they go about solving problems. Can they learn? Can they problem solve? Are they easily frustrated or give up without a fight? That's important to me. I can't tell you how hard your job gets when you hire someone who BSed their way through these technical questions. Then you realize that they have no aptitude other than to memorize interview questions.
which probably would only be required for 0.01% of the jobs...
By using a "name-brand algorithm" which I learned in 2nd year or whatever, umpteen years ago, you are testing for cramming ability, recency of test-cramming at school, and mental copy-paste of whatever was crammed.
You are definitely not testing for problem comprehension and creativity of solution or methodical approach to solution. All of those skills will be severely impaired by time-pressure panic, if you have a good programmer in front of you who has not crammed that particular cookie-cutter name-brand algorithm lately.
It would be one step better if you just said: write an algorithm to sort this array/list of values. But you still chose a problem for which comprehension, creativity, and methodical solution skills are not needed, if the person happens to pattern match your posed problem with the bubble-sort they just memorized for interview-readiness purposes.
So if anything, choose a simple-ish problem that is NOT one that has readily available mental copy-paste cheats available.
Where are we going and why are we in a handbasket?
Architectures & tests (as in unit-test / integration test) questions. Implementation details is almost irrelevant today.
And you consider designing an algorithm to be implementation not architecture? I hope I never use anything that you've written.
I am TheRaven on Soylent News
That's really only true for entry-level code monkey jobs. Anything else will involve a lot of data structure and algorithm design.
I am TheRaven on Soylent News
This means companies tend to favor recent computer science grads from top-tier schools who have had time to cram; in other words, it doesn't help diversify the field with women, older people, and people of color.
I suspect that, in many cases, that's the actual goal of the entire interview process. It's a clever, subtle way of discriminating with plausible deniability.
Those are not skills that you need, they are skills experts simply can't avoid acquiring as part of working in a field for many years.
Good point. The problem is that a good candidate isn't necessarily the same thing as a seasoned expert in that field. Sometimes the best people come from outside the field, with new ways of thinking about old problems. Even within a specific IT field, for example, a decent programmer is supposed to be learning new languages and tools every now and then. If you're expected to work for years with the same static skillset, it doesn't exactly look like a great place to work.
Escher was the first MC and Giger invented the HR department.
Because all those stupid snobbish tests tend by their very design to keep newcomers out. If most programmers are white and male, this will make sure things stay that way.
Bubble sort is not something you stumble upon when you learn to program by yourself -- in real life, people tend to re-invent selection and merge sort (and probably, rats or bees will do the same if you trick them into having to sort stuff). If someone is able by to consider by himself a scenario where bubble-sort is useful, then he is either someone from inside the "culture" (so part of the existing demographic) or someone who is over-qualified for a code-monkey position.
I'm frankly amazed that apparently no-one replying here can even write a simple bubble sort.
yes I know that in the real world it makes no sense to reinvent the wheel, and that most modern languages/extensions/toolkits would already have something more optimized available, but still a bubble sort should be a pretty basic problem for anyone with a CS degree or anyone that calls themself a software developer.
Programming is about creating something that hasn't been created before. So a programmer has to be someone who can create something new. It is the interviewer's job to find out if the programmer can create something new so the interviewer asks a question they hope the programmer doesn't already know and observes how the programmer comes up with a solution.
Every interviewee should know ahead of time that this is the type of question they will get. The interviewer should also know why they are asking the question. The problem is that no one told these rock stars who are taking to twitter this. (maybe over use of twitter has a correlation with intelligence) The other thing I see is interviewers who don't know why they are asking the question and how to evaluate the answer. However this isn't a problem, it is just a great big flashing warning not to work at the company.
You will know how to check string length.
That some dude at Google with 30 years of experience, who is likely not coding much, let alone in Python, doesn't know how that works, tells nothing. (oh, I don't know how either, but I'm pythoning only to fix a thing or two in my enigma2 sat receiver)
This whole thing sounds like someone fails to get people in on merit and wants to somehow justify using "other ways".
This has been around for a very long time and is nothing new. I agree, it is ridiculous and unrealistic, but it is what it is. There are a number of reasons why I believe it is done.
Firstly likely the person that put together test doesn't know a snippet of code from his elbow to start with. That could be the Manager, or the folks from HR. Could be they just stole the method from somewhere else to use. Secondly is the same reason why they want someone with 20 years of coding experience with 10 different specific languages for an entry level job. Part of this again could be the person who wrote the job description doesn't know what any of those things are really, only that they are important and someone told them they were used somewhere in the organization. The other somewhat unreasonable expectation is that the person being hired is able to literally walk out of the interview and sit down at a desk and start coding on a particular established project...
Many many moons again I remember I had a particularly bad C programming "professor". His class was a joke. I'd already taken C at a higher level at a different school, but was required to take it again. His overheads (yes this was a million years ago) were filled with errors and he was a horrible teacher. He had a Phd I believe, I'm not sure if it was really related or not. In any case his final exam worth 60% of the grade consisted of some paper, a pencil and several problems he wanted solved using perfect code. His grading consisted of a couple red "X's" and a seemingly random percentage as your grade. I complained, and asked him to explain to me exactly what was wrong with specific sections, to which he refused. I thought about going to the head of the department, when I leaned he was the head of the department. I let it go and moved on with my life (I passed the course anyway, I had a 97% going into the exam anyway, it was the principle of the thing).
Several years after that (still about 100,000 years ago) I applied for a job, which admittedly was a bit out of my pay grade at the time in hindsight, however either the other applicants were few or horrible as I won an interview. There were a bunch of components to the interview, but one of them was the technical test. Again, like above you're sitting in a room with a #2 pencil and a bunch of paper, and several questions and the ask is for actual code. At this point I *had* at least done some contracts which did require coding, however I always have my reference material, the internet, and most importantly all my previous code I've written in the past which has been leveraged and re-leveraged a million times over, "stealing" this or that sections of code I've already written that would work with minor modifications.
I do very little coding these days. However what little I do people are usually impressed I can pull something out so quickly, which is almost entirely because I've probably already written something similar at some point in the past and all I have to do is find it, modify it and bam! Done, Whenever I think about backing up my work computer the first thing I think about it the tiny amount of space occupied by my library of code. Could I do it from scratch, sure it would just take me a lot longer... Could I write it using a pencil and paper and have it compile without issue and work properly on the first pass? Probably not.
Anyway it is a stupid method, but it's been around forever and I don't see it going anywhere. Really they should let you use whatever you want, if you have the resources to get to the eventual answer who cares. Hell even if you give it to someone else to do, at least you have the networking skills to know people who know how to do it! :p
Hello, my name is Anonymous Coward. I am a software developer.
I was talking to you about a database kernel position which is a field I have spent much of my career in and in one case was a key member of the design/coding team developing the initial (and several subsequent) releases of a revolutionary enterprise class scalable DBMS which is still being sold over thirty years later and in production at many of the biggest companies. You, of course, must have known that because you contacted me and, unusually, I decided to stop by and chat with you because I have a soft spot for startup companies, database, and engineering managers who look around seeking talent themselves rather than relying solely on recruiters. You asserted that your startup was developing an enterprise class scalable DBMS system so it seemed like it might be interesting.
You then asked me to write, on the whiteboard, a 'debit/credit' function that took three arguments and returned, IIRC, the amount transferred (admittedly that was a little odd). The first two arguments were account objects (passed by reference if I recall) representing the source and destination accounts respectively and the third argument was an amount (presumably in the same currency as both accounts were maintained in) to transfer (a float if I recall -- that, of course, is likely stupid in itself when dealing with currency).
I, understandably, was perplexed -- you must want something more than this simple function (I'm not fresh out of high school looking for a summer job) and I tried to get more requirements out of you and got none except when I asked if this function was to provide its own concurrency control or if a higher level would have insured both accounts were sufficiently locked you said something like "Okay, you need to provide the locking" and agreed that I could assume existence of "Acquire/ReleaseWriteLockAccount(AccountObject)" functions.
Okay -- so I'm thinking this is a concurrency problem, no problem (still lame, but okay...). Obviously I need to deal with deadlock potential so I ask if I there is some unique attribute of each account (you didn't give me a description of the account object's public members) that had a well defined order that I (and other developers) agreed to use to order locks when locking multiple accounts to eliminate or at least reduce deadlocks. You weren't prepared for the question so I asked if I could assume (I think) that the account number was a public field, unique among all accounts, and supported the LessThan operator with traditional semantics. You said, sure.
I wrote the code making sure to lock the accounts in order of account number, transfer the funds, unlock correctly and return the required value.
You were not happy -- what you really wanted me to check, it turns out, was that the source account would not end up with a negative balance and fail to do the transfer and return 0 as the result.
What you didn't seem to realize is that in the real world cash balances on individual accounts go negative sometimes. In fact, at that instant, I had one (of multiple) accounts at one brokerage firm which had had a small negative cash balance due to an inter-account transfer out for over six months and no one cared because I had multiple accounts at that firm with a net value of well over a million dollars and cash balances (well, "cash equivalents"), overall, of a few hundred thousand dollars.
Both of us made a decision in that discussion. You decided you didn't want to hire me. I decided I would never work for you or your company as I didn't want to risk working on/at a team/company which was so poor at evaluating people and would pass on good developers who know how the real world works and would likely hire unqualified people who answered your kindergarten questions the particular way you wanted.
Of course, I was glad that we both made those decisions because your company seems to have never got past a very modest A round and seems to have disappeared off the face of the Earth quietly.
Why is there an "insightful" mod and why isn't it "-1"? If I wanted insight, I wouldn't be reading
I give them a problem to solve. I ask for an algorithm, not specific language. Something like: "A trip has a starting city and an ending city. There is a list of all the trips made by John. Where did he start and where did he finish?". Then the interview proceeds based on the answers I get. Most people do linear search. "How does this answer scale as the number of trip increases?" "What happens if he started and ended in the same city?" "What if the trips did not form one chain?" "Can you find how many chains there are?" "How will you speed up your code?".
More than the solution or the answer, I am looking to see if the candidate understands me and can he/she tell me what she/he is doing. If I say, "ok, Let us say you build a map between starting point and the trip index. Would that help you speed up your code?" can the candidate understand what I am saying, if he/she can't understand ask intelligent questions to understand me, do they show an interest in understanding and solving the problem, are they comfortable in communication etc.
Puzzles have their place. If you solve puzzle instantly, it just means you have seen it before. That gives me no input. If you muddle through the solution, it means it is a fresh puzzle. Opens up lots of avenues for communication, letting me ask questions, offer suggestions and hints, and see how these hints are understood etc. I take extreme pains to put the candidates at ease. Tell them up front, "I am not looking for a final finished correct answer. I am looking to see how you find the answer. So feel free to think aloud, tell me how you plan to solve the problem, ask me if something would work or not etc. "
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
I for one totally agree with your point and am already more than fed up with the obvious double standards in our society.
If your objective is merely to hire a code monkey, adapt the interview to assess immediately applicable coding skills (like knowledge of syntax, coding speed and accuracy, ability to code to specs, code readability and maintainability).
If your objective is to hire a programmer who has to be able to come up with an algorithm to match the specs, by all means review algorithm knowledge and coding skills, but be sure to include problem solving skills.
When looking for a software engineer, ensure the applicant can program, but focus on above-average problem solving skills plus theoretical background plus ordinary engineering skills.
That alone gives you three different types of job interview.
Red-Black trees.
I am very small, utmostly microscopic.
Someone who works with me asked me not to tell anyone at work he is a contributor to a well known open source project even though the project has nothing to do with what we do as a company and his contributions are mostly for architectures we don't even use.
If you're an expert forum poster you would have realised by quoting the things you did you have missed the entire point. Which is that when you employ an expert in a field for a job you don't ask stupid unrelated shit.
>> Karla Monterroso, [...] This means companies tend to favor recent computer science grads from top-tier schools who have had time to cram; in other words, it doesn't help diversify the field with women, older people, and people of color. ...or you could make the far more accurate argument that it works against people that are using whatever lame peecee excuse to dismiss the fact that they haven't actually bothered to learn their subject.
BTW as an "older" engineer myself, I am happy to not get a job if I can't sufficiently demonstrate that I actually do know my shit, and I resent liberal peecee morons like her trying to grouplabel and speak for me.
Having been on both sides, I can tell you why companies ask these questions -- they're looking for basic technical knowledge and competence. All too many times we've seen candidates who can talk a good fight and who can (given lots of time and access to Stack Overflow) write a program that succeeds using copy-paste. However, these are not the people we want to hire. Once we're past the basic knowledge and competence we can look at fit, people skills, etc., but I for one have been burned by new hires who bamboozled a non-technical manager.
x86 has had POPCNT since SSE 4.2.
This exact thing has happened to me at Amazon and Google interviews. At Amazon the interviewer was apparently one of those people who don't like to be corrected and ended the interview right there. Now I always reply, "The answer you are probably looking for involves a lookup table..."
If you want to work at some huge Company with a hard interviewer, that's your choice to make. I have known a bunch of coders who got together (either from getting the old-age boot - or simply in disgust of their job) and form their own little company. They are happy and doing quite well! If you are looking for huge sums of money; that comes with a price: Stress, time constraints, working late hours. and maybe working through weekends. If it were me, I would have majored in at least one other field in college. Just in case I was unhappy with the one I'm in. (You can always code on the side for fun and staying current. They have Internet classes.) Coding is fun and I wish I had extra time to hone my skills.
Firstly, isn't most of this information online for free? If you have the skills necessary to work as a software engineer then it shouldn't take much time to practice and learn the skills necessary for interview. No matter which job that I apply for I have to take time to research the company, learn about their ethos, modus operandi and be able to explain to them how I'd fit in. I also have to exhibit the skills relevant to the job, which in this case is the much hated whiteboard but could equally be through presenting a portfolio, examples of past work and answering their question as they crop up. This isn't anything unique to software engineering, it applies to pretty much any professional job, whether something as low paid as an "administrative assistant" or more advanced roles as a translator or software engineer.
After reading the rest of the medium article, all that it seems to state is that the interviewing for tech roles is broken by prioritising algorithms which may not be relevant to the role posted. Again this isn't discrimination, it's a testing of unnecessary skills or are white males born with an innate ability to spew forth algorithms which they are unfamiliar with?
Have I missed something here, are interviews genuinely discriminatory?
Thank you moderators for proving me right.
I'm an American. I love this country and the freedoms that we used to have.
Bubble sort is four operations: two loops, a compare, and a swap. It's not just simple, it's idiomatic. And it demonstrates that you understand the basics of how sorting works, rather than as some magic black box that takes one lump of data and returns another sorted lump of data with who knows how much dependence on heap usage. Did you know you can use bubble sort on a singly-linked list? If you have data in a small linked list (not uncommon in the embedded world), this (combined with linked-list-fu) will let you sort something that isn't in a tidy little array. And for small data sets, bubble sort isn't that much worse, and the code will be easier to understand. If it isn't fast enough, you can always replace it with something better.
It's better to be right and a little slower (especially with the speeds of modern jellybean CPUs), rather than implementing your own version of a "faster" sort and getting it wrong. It's hard to get four operations wrong. In embedded, you don't want subtly wrong code lying around in your product. I had one case where a subtle bug caused a relay to sometimes not change state. Four (!) years later we figured out it wasn't just the relays not getting enough coil current. Ripping out the interrupt-based code and replacing it with foreground-only code not only got rid of the bug (interrupt synchronization errors can be truly evil), but the code was a couple hundred bytes smaller, too. (the device had 4K of flash)
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
Except that the point isn't to sort some data as fast as possible, or even to be coded perfectly, it's to watch you write some code for half an hour.
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
So do you expect on interview surgeon to perform surgery? Want to sign up as a test subject at your local hospital so that they can have potential hires perform some surgery on you?
Looking up API info on the net is indeed a usual thing. Especially, in areas where you seldom operate. For example, making a string out of an object is a thing I do rarely, as such stuff is done by the logging framework for me. However, the one question about NP is valid. At least you should know what it means and why complexity matters.
Probably because Google sees you as a "resource". I'd personally never would work for a company that asks these dump questions. I don't have CS degree or PhD or even formal computer education. I barely finished school, but I'm working for over 19 years in software industry.
ff your dataset is 20 elements then every in-place sorting algorithm will be equally cache friendly (on the d-cache), if you are worried about the i-cache, I guess it is better to use just ONE sorting function, qsort for example (you will need a fast sort for larger arrays anyway).
If you would run your sorting algorithm on a really small data such as 20 elements (and care for O(1)), my guess is that a normal bubble sort is not what you want. I guess you would use a combination of loop unrolling and some SIMD tricks and maybe a memory pre-fetch and that the result would NOT look like bubblesort.
I can't recall any instance where I actually needed to do so as part of my job
I guess that is true for nearly everyone here.
Which is exactly why it's a bad interview question. The more experience you have, the longer it's been since you've been in that introductory algorithm class and the less likely you are to remember the details of a sorting algorithm which you should never choose for any non-trivial task. The ability to answer that interview question has nothing to do with your practical skills as a programmer; it tests only your ability to remember useless trivia.
in an introductory Algorithms class as an example of what not to do.
That is wrong. I suggest to check Wikipedia, facepalm.
Since you refer to Wikipedia, I'll leave this quote here as further evidence that bubble sort is best relegated to the role of a bad example:
Even among simple O(n^2) sorting algorithms, algorithms like insertion sort are usually considerably more efficient.
Due to its simplicity, bubble sort is often used to introduce the concept of an algorithm, or a sorting algorithm, to introductory computer science students. However, some researchers such as Owen Astrachan have gone to great lengths to disparage bubble sort and its continued popularity in computer science education, recommending that it no longer even be taught.
The Jargon File, which famously calls bogosort "the archetypical [sic] perversely awful algorithm", also calls bubble sort "the generic bad algorithm". Donald Knuth, in his famous book The Art of Computer Programming, concluded that "the bubble sort seems to have nothing to recommend it, except a catchy name and the fact that it leads to some interesting theoretical problems", some of which he then discusses.
Bubble sort has a few niche uses, as I already alluded to. It can be faster when the list is extremely small (like three elements or less) or when the input list is known to be very nearly sorted with only a few close elements swapped. Such cases are vanishingly rare in the real world.
"The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
That's micro-architecture, which would lead to a test failing if that block is relevant, so we're back at the spec sheet design. YAGNI in 99.99% of the time.
I've worked as a programmer mainly at companies in Silicon Valley. I've taken and given plenty of whiteboard coding interviews, including for Google.
The problem is that they were designed originally to find recent college graduates who have topics like red-black trees or counting sort at top-of-mind. This process weeds out older folks who might have a lot more practical knowledge but aren't as well versed with more academic topics that aren't encountered much in the real world. Instead, people are given an expectation that they need to brush up on their academic skills for a non-academic job interview, which is an indicator of a broken process.
Besides, even Google has publicly admitted that there is almost zero correlation between interview scores and the resulting job performance score. It's disheartening to see that they really haven't revisited this process then, despite their claims of data-driven decision making.
(insert witty/esoteric/dumb quote here)
Not if you want circumference. If you want area, that's correct.
I have an advanced degree in Computer Science, yet for various reasons, I'm in the market. I usually just have to bite my tongue and go through the paces, but I've never been in the room with anybody that understand algorithms to the degree that I do that asked these questions. Because the people that have the same understanding that do look at my education and just skip to what I'm interested in, what they are looking for and so on.
Once, I decided to use recursion just for a change of pace. In the end, the interviewer just showed that he didn't actually know what tail call form was. Remember, the people that really know what they are talking about will always admit what they don't know and what they look up. It's the one that are trying to be and look clever that are problematic.
Also, if you are just trying to see how people approach problems, just say so. Also, the vast majority of programming isn't oriented around algorithms and data structures, it's all domain representation and library integration. But nobody asks "let's try to capture the essential properties and methods of a class for a shopping site customer." for example.
not that you're wrong, but programmers have been complaining about whiteboard tests since they were still blackboard tests, and haven't accomplished jackshit to change things. i don't see how the "SJWs" could do that much worse.
"They were pure niggers." – Noam Chomsky
Much better way is just do a contract to hire.
Only if your goal is to abuse or misclassify someone.
Twitter supports and protects racists - by smearing their critics with the "Hate Speech" label.
The point is how much you already know.
Or don't know. As Dirty Harry (Clint Eastwood) once said, "A man got to know his limitations."
I can read French with a dictionary I can read English without one.
If you know the English language, and since 45% of English words have a French origin, a French dictionary should be optional.
Worst hire I ever made.
I don't give that kind of interview, I mostly ask leading questions. But it very quickly became clear this guy I was interviewing for a team lead position had an encyclopedic knowledge of the GoF patterns book. You could stick a pin in the index and he could sketch the pattern from memory. And he knew a whole bunch of other stuff. He could discuss the latest developments in the field easily and fluently. So I thought, the team will probably enjoy working with this guy. He's pretty interesting.
When they started fail to meet deadlines I looked at the code they were producing and I was shocked. Superficially the code had all the right bits, but if you dove in you quickly realized that functionality was scattered hither and yon. It was lava flow behind a facade of design. I might as well have given the team a book as a leader because this guy had no actual understanding of how any of that stuff worked. And yet if you asked he could deliver a cogent, but canned explanation that was utterly convincing... until you asked him to show how the stuff he actually produced corresponded with the theory.
It was the most perfect facsimile of knowledge I have ever encountered. I had no idea that anyone could keep so much in his head that was, in effect, gibberish to him.
Now it so happens this guy was Indian. In my experience Indian programmers are neither better nor worse talent-wise than American ones. The best are outstanding and the worst are terrible. But this guy was bad in a particular way that could only have come out of an educational system that puts a high premium on rote memorization and facile regurgitation of what the teacher says. And that took this guy far, as far as a master's degree at an American university, although in retrospect that's pretty disturbing.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
I wouldn't call these 'confessions' nor 'sins'. They're observations I'm also making as I go through the process right now, 7 years since my last job search.
This is my experience thus far -
Context: I have over a decade of experience and a MS-CS. In the last 6 years I was part of some amazing projects (easily the most meaningful), I worked on getting a business off the ground, and spent little over a year being a full-time parent. I've been in many positions to interview, and make hiring decisions before.
I've interviewed unsuccessfully at the big employers in my area (GOOG, AMZN etc.) As I think about the places I didn't enjoy the process and wouldn't have looked forward to working at, the common theme would be that none of those groups cared to go into my past work history. They'd jump right into their academic-CS questions after introducing themselves. I can't imagine what the review process looks/sounds like afterwards, but they don't gather much data points about other qualities that separate each of us. These are also usually the places where a main reason for joining seems to be - "you'll be working with very smart, intelligent colleagues." My personality is such that the application matters more, so it doesn't matter if everyone around has high IQ if they're applying it towards the development of say, advertising platforms.
I wouldn't follow these practices put in place by MSFT/GOOG if I were to either run my own business, or were involved in at another company. There are other qualities to determine whether someone would be a good fit, and there are many groups out there who do a better job with this. What matters is if you hire/join colleagues you enjoy solving problems with, and having a civil and professional environment to do it in.
I may be able to write bubble sort on the whiteboard (with some mistakes like a missing semicolon), but I may not know that it is called bubble sort.
Yeah, and I'm happy to pass on being hired by you, as well.
Long Live the Sorting Hat.
I've read electronics data sheets that were riddles, wrapped in a mystery, inside an enigma. Those data sheets are tying to tell you something, and it's probably not that you should busy yourself with becoming better at solving riddles.
Riddle me this, Batman: what do your customers want? That problem probably shouldn't be addressed with riddle-brain either.
But I will concede that there's a time and place for mastering the art of solving the Really Big Riddle. Like that time the London Whale put $2 billion up for grabs by whoever was brave enough take the other side of those positions.
Those are the riddles that are really worth solving.
Ivanchuk missed mate in one
Is it a riddle how this kind of thing happens, or a problem requiring deeper cognitive skills? For example, was Anand hoping that Ivanchuk would miss his easy out, because of the complexity and urgency of the rest of the board? Or were they both so wrapped up in the larger riddle, that neither person noticed the coup de grace? (Not that I've ever witnessed this in the trenches, while programming under an intense deadline.)
What does a real programmer do? He or she notices that there's a pattern to the error mode of top chess players—long moves by bishops in the backward direction are the ones most often missed, and writes a script to catch those instances. Is that a riddle? "What class of moves is missed most often by top chess players?" I don't think you can approach that question as a riddle.
Often the hardest thinking is that which allows you to escape from riddle mode.
You're Anand. You don't even know if your opponent is a lone wolf who has wandered off the reservation or a world-renown investment bank executing a deliberate strategy. Whatever he might be, he appears to be leaking $100 million bills. The clock is ticking. Your move.
But when applying for a job one should first read the requirements of the jobs. They're not always well written, I will agree. But one should be able to figure out that the job is for someone writing real code versus someone to create a high level "solution" to package together components. Smaller companies don't usually have room for more than one or two of the second type of job.
I once asked someone to capitalize the first letter of a string
That can get quite nasty in unicode (depending on language and libraries), especially if you need to support i18n.
Every break I ever got came from doing an end-run around HR. Picture HR as a bunch of 300 lb. tackles in the middle of the field, each and every one of which has had way too many concussions; but they can still fuck you up. Your first job is to get the ball and run fast and wide, hoping to squeak by the sideline without stepping out of bounds, and get into the end zone. The actual job is usually so much easier. Think of it as kicking the extra point; but you get 1000 points instead of 1.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
How about being proficient in some skills relevant to the job you're applying for instead of saying being mediocre at your job is ok?
And even then you can't tell if they'll be any good because a lack of common sense can trump any skill level.
I'm not. So, you're free to not hire me as a forum poster, even though you yourself may be a professional (=shill).
Not necessarily, which is why not every employer asks these kinds of questions.
But when people ask those questions, they usually are looking for a seasoned expert.
Well, gosh, and in those jobs, people probably aren't going to ask you those questions! Imagine that!
Nothing I mentioned is "genius level"; it's something anybody with a few years of professional experience in those fields should be able to do.
Did I say anything different anywhere?
Confession: I run technical tests when recruiting IT persons. But it is on a computer, with Internet access, and looking up documentation or forums is fine.
In fact, using Internet or documentation to find something is a very good indicator that the candidate has skills and experience.
That works both ways: if people invite you for an interview, your resume obviously misled them into thinking that you were something that you were not.
Personally, I don't give whiteboard interviews; I consider it a waste of time. There are simpler and faster ways of telling whether you know your stuff.
However, when people have given me whiteboard interviews, I viewed it as a matter of professional pride to get it right, even if I had already decided that I wasn't going to take the job.
If you had implemented it many times, that would defeat the purpose. The reason people ask about bubble sort is because it's a simple (or simple to describe, if you don't remember it) algorithm you rarely implement. Hence, you have to actually think through things like edge cases, generic typing, argument validation, correct pointer usage, etc. It's a programming test, not an algorithms test.
And that gives rise to nice follow-up questions. Why don't people use bubblesort? Can you think of any applications where bubblesort might still be a good algorithm? Can you think of hardware architectures where bubblesort might be a good choice?
If you think that writing a correct bubblesort on the whiteboard is that complex, then I don't think software development is a good job for you.
Took me less than a minute.
The make up of college CS programs is different if you're female or have brown skin?
He thinks that if a language shares 45% of root word origins, that you can speak it.
Read a language, not speak the language.
Apparently we all speak Spanish, French, Italian, and Latin as well as English.
The English language has stolen many words from other languages over the centuries. What few words that weren't stolen got made up by William Shakespeare.
https://en.wikipedia.org/wiki/Lists_of_English_words_by_country_or_language_of_origin
https://en.wikipedia.org/wiki/Shakespeare's_influence#Changes_in_English_at_the_time
C, perl, bb and other programming languages are mostly just dialects of assembly, which is entirely of English so I guess we know those too!
If you understand the structure of one language, you can understand the structure of other languages.
A programming expert:
(1) Can implement it correctly in less than a minute.
(2) Knows not to use bubble sort under most circumstances.
(3) Can answer why it's a bad algorithm.
(4) Can come up with situations where it might be the best algorithm to use after all.
(1-4) are not mutually exclusive.
It can be considered as piecework, not paid hourly but for completion of the task. If they manage to complete the task, the amount will be added to their first paycheck. If they fail to deliver - what's there to pay for?
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
This summary was posted early on the first, I think. Then I see it again early on the second. Dupe? Nope, it's the exact same summary with all its comments.. The parent comment is even now dated earlier than the summary. Wednesday March 01, 2017 @11:47AM vs. Thursday March 02, 2017 @01:58AM
It's a bad article. The point is valid though. Sure, ask for fizzbuzz. That's something that any developer should be able to work out from scratch. A sorting algorithm? Not all that useful, especially if it's explicitly a bubble sort they want. What if I give an insertion sort instead? Understanding time complexity makes sense, but memorising the algorithm is pointless.
The locking scheme always feels like a "I've read a book on basic threading algorithms and I want to prove it" questions. The issue I always come up with here is race conditions. Much harder to track down!
I've gotten this far in the comments at least twice and I somehow haven't seen the code. I suppose I could scroll back up, but meh.
I didn't say that you should implement bubblesort when doing a job, I said that any decent programmer should be able to implement it. I even gave examples of lots of other silly things experts can do, like ski backwards and play the piano blindfolded. How utterly stupid do you have to be to still not get the distinction even if it is spelled out for you like that?
In a recent job interview I had this question among others:
What data type in SQL Server I would use for a data column that would be filled with numbers between 1 and 100?
After looking in the SQL Server documentation, I've seen it's tinyint, but seriously, who actually tries to remember stuff like that? The point of the article is probably applicable in this case, they want to hire people who recently graduated or finished their courses as they are more likely to know stuff that everyone else thinks it's pointless to learn since it only takes a quick Google search to find out the answer.
Not all questions were like that but I still failed the interview.
If you post as an AC, don't expect me to spend a mod point on you.
Yours [Walt Sellers'] was one of the few insightful-rated comments that really seemed to merit the mod. If the mods were logarithmic then high (e^5) mods would really mean something.
Or maybe you just read Work Rules! from the google guy? Most of your comments follow along the lines of the google interview process as reported in that book. Mostly admirable ideas, but I still think the old "Don't be evil" motto has been replaced by "All your attention are belong to us." (I've been reading a lot of google-related books lately, but nothing else in the various parts of the LARGE discussion that I read seemed to ring any other bells.)
My suggested improvement to the google's interview process would involve making videos of the interviews, either just the interviewer's face or both sides. Then the interviewer could focus on the interview itself rather than making the notes at the same time. If the interviewee agreed to both sides, then the two-sided interview video would actually allow other people to get a much better feel for the interview without taking any of the candidate's time... (Also much better for evaluating the skills of the interviewers.)
However the insight I was looking for and failed to find in the comments was a bit upstream of the actual interviews. It was how the job-search websites earn their income from the corporations by helping them drive salaries down. It's kind of like lotteries focusing their advertising on the winners while ignoring all the losers who made the lottery profitable. Of course they boast about the few winning jobs (as with the google) that attract lots of candidates, but where their money is really coming from is all the lesser candidates who compete for the lousy jobs by seeing who is most willing to accept the position.
I wish there were a job-search website that was driven by the candidates. An economic model where the website actually profited by helping each person get the best job. Perhaps the economic model aligned from the employees' side would produce rather different results?
Talk about a pipe dream. Whatever I've been smoking, I better cut back.
Freedom = (Meaningful - Coerced) Choice != (Speech | Beer^2), and sad sock puppets' bad mods avail them naught.
They really shouldn't, but you keep telling yourself they should and I'm still waiting for a consistent reason. Companies allot 30 to 90min for technical interviews (most candidates won't submit to more), and if they focus on requesting proof of unnecessary long-term memorization skills, of stuff you're really not supposed to memorize because you have references at hand at all times, they're wasting your time and taking the wrong conclusions. You don't need to "play code by ear", you don't do auditions when programming, other than interviews in the status quo.
I don't want you to barf something onto the whiteboard that you can look up in 10 seconds or what has been done to death in libraries. Basically, the correct answer for "how to do a linked list" is "#include ".
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
What I want to test with my "unreasonable" questions is your ability to think abstractly, and to find a solution to a problem you have not faced before. I'm aware that you cannot solve the problem. I am also not interested in a solution (at least not in the interview). What I want to see is how you tackle an unknown problem. What do you do? How do you approach it? I'm well aware that it's very, very unlikely that you can simply toss a solution at me (and if, all you'd get is a different problem because, again, I don't care for a solution, I care for your approach to an unknown problem).
I also give you absolutely free rein in what you do. I actually had an applicant whip out his cellphone and call someone. Another one mailed me a solution a day after the interview.
In my field we're constantly facing new problems nobody has solved before. So asking you for an existing solution is worse than useless to me. I want to see what you do with a problem you have no ready made solution for.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Least efficient? Try slowsort. Non-polynomial while still guaranteed to terminate.
So true, so true.
I once failed a phone interview because I couldn't use Google to look up some helpful side info, not the answers directly, just clarifying information. I immediately thought "what a bullshit. Unless you're studying for a test, you don't have this detail in your head, you pull it up as you need it."
I look up functions and parameters all the time. Half of the time I kind of remember them, but look them up to make sure - it's faster to spend 30 seconds checking than finding a fixing a mistake later on.
I would flat out refuse to do riddles and bullshit tests today. I would ask them if they want someone who is good at memorising trivia or someone who can actually solve real-world problems and if it involved a few Google searches, what exactly is their problem with that?
When I studied, we were allowed a full formulary during math tests. The professor once said, and I agree for 100%, that unless you understand the math, the formula won't do you any good. The skill is not in memorising the formulas, it's in applying them, and knowing which one to use in which situation.
Assorted stuff I do sometimes: Lemuria.org
No ... agreeing with you
how this is any different than any other Certification Test or Entrance Test.
I just roll my eyes when I come across these types of questions because their pointless. In my opinion, the cert tests should be 100% simulations where you're given a scenario ( just like in reality ) and you get to put your knowledge on display by solving the problem. Alas, this is not usually the case.
Instead, the tests ask some of the most arcane and useless questions that no one really needs to commit to memory because it's irrelevant or outdated information.
Questions like:
In what year was the 802.11g standard adopted ?
a) Who cares, it's a standard
b) Who cares, I can look it up if need be
c) Who cares, we're a couple of generations beyond it now
d) Who cares, did you all run out of useful questions to ask ?
I'm certainly not a programmer, but I do some minor scripting to help semi-automate my job functions and make my life easier. I usually have to refer back to the library of books sitting on my shelf ( or previous code I've written ) to recall what the syntax for certain things are, or how Shell X does things vs Shell Y or Z. I fail to see what the point of reference material is if everyone is expected to memorize the entire thing on demand.
A good programmer doesn't go around knowing everything by heart. He or she knows enough to know where to efficiently start looking when they are given a new task.
Pi is defined as the ratio of the circumference of a circle to its diameter. What is there to prove?
Why does it matter that Pi is transcendental? The approximation we use in any mathematics library isn't even irrational!
Brain neuroplasticity doesn’t allow one to reliably store information over time (our data, regardless how rich at a given point it time, will change and/or degrade with experience/routine). However, we are experts in adaptation and creativity (with a few billion years of experience, give or take). For reliable storage buy hdd/ssd, I would suggest a raid system and search engine on top, way cheaper! Disappointing that big tech companies, who presumably “threatens” the world with their understating of AI hold on such narrow views.
Way back in the 1980s, one of my physics professors told the following joke:
The trustees of the university want to find out if the professors really knew their stuff so they came up with a question: What's 2+2?
They go to the math department and the professors there said, "Oh, that's easy. It's 4."
Then the go to the physics department and the professors there said, "Oh, it's 4.000000000 with an uncertainty of another decimal place."
Then the go to the engineering department and the professors there said, "Just a minute while I get my handbook."
Finally, they go to the accounting department and the professors there look around to see if anyone can hear them and then the whisper, "What do you want to be?"
Code schools aren't the place to go if you want to be a "rock star" at Google or Facebook. These are designed to turn out junior developers, or "apprentices" as they're known at Software Guild, which currently has 16 instructors and 148 students split between in-person and online programs. Students learn just enough to be dropped into teams of more experienced coders and continue their education at a company, even as they draw a competitive full-time salary.
So you can drop them onto a team at "Bob's Software Company" to continue their education... and when they get good enough... "Screw Bob! I'm going to Google!".
What's the incentive to Bob to hire these gits who are just using his company as a free method of not paying DeVry Institute or a similar company for their vocational education? Because if I were Bob, I'd be kind of pissed, since my company was created to create software, not provide vocation education.
Why should I pay someone to attend my (now) vocational education company, again? Because students who are rookies should be paid to be students, while at the same time soaking up cycles from my senior developers, so that they can't produce complex code for me, either?
Someone must thing Bob's a fricking moron... "Here's some students to teach at your vocational institute, while not getting a lot of useful effort out of them. And oh, by the way: the tuition is a negative number".
If you want to be an apprentice some place, become an electrician, a plumber, or an HVAC specialist. Software Engineering doesn't *have* apprentices, because they don't have a *union* to prevent people not in the union from getting jobs as software engineers!
And in case that wasn't clear:
I don't want you turning my software company into a fucking vocational education "feeder school" for Google. Thanks!
Asking you to do a little programming problem isn't a test of "memorization", it's a test of your ability to write basic code without ropes and safety nets. People pick bubble sort because candidates are unlikely to have memorized the solution yet understand the specification pretty well.
Actually, I think whiteboard interviews are a waste of time for the interviewer. Much simpler questions usually tell me what I need to know, like "What is the purpose of whiteboard coding?" and "What's your reaction the statement 'I don't need to know even basic library functions because I can always look them up'?" or even "What questions do you ask during an interview?"
and I haven't written a lick of code since college.
I'm a network/system admin - and the job required a BS in Computer Science - that is probably completely unnecessary to do the job.
People interviewing candidates for tech positions need to ask broader questions about work experience. Asking a candidate about implementation details for a bubble sort or the syntax of Cisco iOS commands doesn't tell you if the candidate is a total psycho that can't work with people and can't solve problems.
So i read this article and a number of the comments yesterday afternoon, and yet this morning i find it presented as a new article in the feed. I still have the old post open in a tab so i can see that the old timestamp was "Wednesday March 01, 2017 @11:44AM" as compared to the current "Thursday March 02, 2017 @01:58AM". The fact that the timestamp on the article is incorrect becomes obvious as soon as you examine the timestamps of most of the comments.
Is this some kind of bug? Or is it a regular practice of Slashdot that i just haven't noticed until now to twiddle the timestamp of popular articles to get them to show up higher in the feed and try to get more hits?
This Space Intentionally Left Blank
It's a funny example, because I have exactly one post-it note with coding info over my desk -- the syntax to find the length of different strings & array types.
We know where leadership by an anti-intellectual "strongman" who scapegoats minorities and likes boisterous rallies goes
I'm not a programmer, but I have had whiteboard interviews. I am a Cisco guy, doing routers/switches/firewalls and networking. I've been in IT in various positions for around 30 years now and working with Cisco and networking for more than 20.
The last few years I've really noticed, what I consider, quite a disturbing trend for the interview process.
I've been asked to troubleshoot a deliberately sabotaged pc.
Deliberately sabotaged virtual network through the use of a virtual router/switch software program.
I've been asked to go home and go through a questionnaire online that also had customer service phone role-play elements that could take anywhere from 2 to 4 hours of my time.
I've been asked to do role-play scenes with executives during the interview.
A number of whiteboard scenarios that were broken and I was expected to fix, most of the time without any additional information.
Technical interviews where I was asked a full range of random and often obscure or not-related to what I was interviewing for questions.
Given a big set of specs and asked to design the network from the ground up, with all the details (a thing that would take...many hours)
More and more it's felt more like a song and dance routine than a job interview...and I absolutely hate it. I have said no thanks on a couple of them and walked out and on another couple I put in an inordinate amount of work to find out, oh we hired someone else...D'OH! boy did I feel robbed and cheated.
So while I may not have had the exact experience a lot of programmers have, I've had an equivalent.
I hope the job I have now sticks, because I am sick of doing interviews and doing the song and dance routine.
I interviewed for a QA position for a large corporation. Even though it was for a manual testing gig, they brought in a group of developers to be part of the "gauntlet" of interviewers. So on top of the normal "tell us about you" and "why here", one of them asked me a programming test question.
After discussing what he wanted, I went to the whiteboard, struggled for a bit, then said, "I'm sorry, I can't figure this out at the moment. Can you show me your solution?"
The smug developer explained (didn't actually write the code) how to tackle it. I paused and considered his answer and said, "That won't work because of X". The other devs in the room thought about it, giggled, and agreed. So they went back to asking relevant questions, and the one dev was silent for the rest of the interview. As we were shaking hands I had an epiphany and explained a working solution.
I ended up getting the job and was assigned to QA a number projects lead by that developer.
“The only world where you would actually need to be able to recall an algorithm would be a post-apocalyptic one, where the hard drives of all the computers connected to the internet were fried, and all copies of foundational academic papers and computer science textbooks had been reduced to ashes,” coding instructor Quincy Larson wrote in a blog post. “Whiteboard interviewing is a discrete skill, much like being able to remember Pi to a thousand decimal places.”
In my experience, every programmer I've come to deeply respect could, at any time, produce a working implementation of a hash map and at least one O(n*log(n)) sorting algorithm using only pencil and paper. I recognize that not every computing position requires deep algorithmic understanding. Maybe web developers don't really benefit that much from knowing what algorithms go into layout engines or how their associative maps work in Javascript, for instance. OTOH, there are plenty of positions that clearly benefit from the ability to think about the skills that whiteboard interviewing tests.
If this metric is so terrible, the market will push it out. The market seems to have done a pretty good job punishing the companies who asked questions that required real inspiration, as I wasn't asked anything like that in my last round of interviews. Questions like, "How do you find a cycle in two linked lists?"
Articles like these induce me to wonder if the "social media using" programmer subset is getting entirely too much representation in trade publications.
The ability to quickly inhale a lot of information, which this article admits is tested by this process, is frequently an essential skill, I find. We may not be testing directly what we state we are testing, yet we might also still have value in the process. I find the entire thing a little scary, too, but I always come away feeling like the questions were relatively straightforward.
The cost of bugs is so high in the industry, regardless of domain, that I feel this analytical ability to think like a compiler that is often tested in interviews yields people who are less likely to write bugs and more likely to find them in code reviews. Tracking this is notoriously hard, so I imagine validating the data on this is similarly difficult and it is trivial to suggest that employees who get good annual reviews, which itself may not be testing productivity, invalidate the metric.
This means companies tend to favor recent computer science grads from top-tier schools who have had time to cram; in other words, it doesn’t help diversify the field with women, older people, and people of color.
We cannot start calling a preference for CS grads, especially those from good schools, bigotry. If there is underrepresentation from those schools, the correct remedy is to fix it at the root, which might mean addressing fundamental inequality at the elementary school level or not jailing parents for non-violent offenses. At the end of the day, a company has to be able to hire what it feels are the best candidates. If the company is wrong to prefer "top-tier" schools, the company will be less competitive and another company should, via market forces, hire on a better metric.
Markets take time to remedy poor metrics, but they tend to do so better than social justice advocates. Complaining that the metric is bad in the middle of the process is what it is. Without changing the incentive systems that govern company behavior, whinging shouldn't achieve much. And, changing the incentive systems is a potentially disastrous thing to try.
“We believe that technical interviewing is a broken process for everyone but that the flaws within the system hit underrepresented groups the hardest.”
The terrible thing about this quote is that the person speaking clearly feels this fact alone is sufficient to compel a remedy at this level. Having to do root caus
Reality is a slackware box running on a 386 tucked away in god's sock drawer.
I have written programs in over 50 (programming) languages, and probably well over 5,000 different products, from local scripts to big team efforts. I have no memory of how the code appears; it's done, I Iorget it...but I don't forget the methods and practices I've honed over the years. Most of my experience is with Procedural languages; throw me the requirement to use one of the Functional languages, or some unique Operating Systems' scripting language, and I'd be lost. On the other hand, CHOOSING the right language for the need (e.g., a real-time transaction-processor versus a Linear-programming solver) is a key part of the job.
In fact, it knowing more about which algorithms are useful, and which are not, for a particular class of application. That's the issue, because choosing the right language is a key part of doing the job most efficiently. And, even more relevant than "writing a sample program" is debugging: A large part of most programmers' jobs is actually trying to decipher somebody ELSE's code, to find the defect(s) and repair it (them).
I don't want you turning my software company into a fucking vocational education "feeder school" for Google.
That's unlikely. I used to work at Google. Their top programming talent is the cream of major universities. Unless you have a genius in the making, they're not interested in your feed school programmers. ;)
Sure that it works ;D ?
Does it stop when it realizes the input is already sorted, or in other words: does it realize it?
Etc.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
...Programmer:
"Do you know how to do (any relevant topic here)?" (Keep doing that until the answer is No.)
Response: "How would you find out?"
Such cases are vanishingly rare in the real world.
No they are not, hence those benefits are often pointed out for Bubble sort. And people usually completely forget about them, because they only have memorized: "bubble sort is bad".
That is actually another reason why asking for such an algorithm in an interview is "strange" as the interviewee probably only "remembers" that fact (probably also one of the topics Knuth refers to).
E.g. you have a table in a kind of excel, you sorted first by column A, then you sort by column B, depending on situation column B will often be partially sorted already. ... or you sort stuff only by first digit or first letter, then you can use short cuts ...
Or simply want to have a "stable" sorting algorithm
Your idea it is only fast for very few as 3 or less is wrong: the upper limit where it is faster than e.g. Quicksort depends on hardware, like cashes, paging etc., much more in our days than it did when the algorithms where "invented". So while they look bad in O calculus they are still very fast for special cases.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
You mix up "algorithms learn in university" with "crafting new algorithms on demand".
The latter is my job, the first I never needed except in the university to pass the gradings.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
I'm James and I get paid to write software. The one actual whiteboard interview I had, I intentionally did not really try to appease the process. I was well-familiarized with it and could have easily prepared. But I decided to use the process to filter unworthy employers. The recruiter asked me to implement some basic things on his whiteboard in C. I gave him pseudo-code and commented that I've written many things, including a compiler. Syntax while technically relevant is not actually relevant. Suffice to say, he didn't seem convinced and I went on to work with another (awesome) company who cared about my attitude most. I figured if that actually mattered to them, then they weren't right for me. Years later I talked to a friend who'd worked at the whiteboard interviewing place, he told me I'd dodged a bullet.
This is _exactly_ why I do not work for Amazon. Because after an all day interview, including being interviewed during lunch so I couldn't actually eat, I was asked to stand at a whiteboard and design a novel algorithm and write accurate Perl code from memory. (I should mention that my job at Disney involved writing great Perl code all day, and I did just fine. No thanks to Bezos and his grist mill.)
I should also mention that one of the first things I saw when I walked in was a young woman standing at her desk, just crying. And everyone walking by acting like that was a perfectly normal thing to see there. And when I went to the lunchroom, not a single person was smiling, or laughing, etc. They all just looked beat down. By the time the whiteboard came up, I had already decided I didn't want to work there.
--- Generation X: The first generation to have SIG lines inferior to their parents... ---
Yes: that minute includes tests, and it's also provable from the code.
"That is nice if they are searching for leaders and if they don't care about the quality, time or cost. Just because you are a leader, doesn't mean that you are a good leader. The difference between bad and good leader in a software project is billions in money and years in time. I've even seen several times when bad leaders shoot down good developers because they bring up the problems.
I have also seen good leaders. Not perfect, but someone who will implement a project with 1/10th of a cost compared to others, simply by asking the correct questions, making the right decisions and demanding certain things. This is actually where software companies should put more effort. If they can get or educate really good architects to their projects, they need 1/10 of the developers to implement those projects and 1/100th of people to maintain them.
Mind you, I'm not a leader nor do I want to be. I also know that I'm a better programmer than the leaders usually are. Without them, I would need to work more, but without me they wouldn't get it working at all. Both are needed."
Very Insightful AC -- Thanks!
A 21st century issue: the irony of technologies of abundance in the hands of those still thinking in terms of scarcity.
"on people who can't tell Javascript from Assembler."
https://en.wikipedia.org/wiki/...
function strlen(ptr) {
ptr = ptr|0;
var curr = 0;
curr = ptr;
while (MEM8[curr]|0 != 0) {
curr = (curr + 1)|0;
}
return (curr - ptr)|0;
}
A 21st century issue: the irony of technologies of abundance in the hands of those still thinking in terms of scarcity.
https://en.wikipedia.org/wiki/...
A supervisor at IBM Research pointed this out to me -- a big challenge the farming villagers face in hiring Samurai is that they do not know what makes a good one...
A deeper issue in your post is discussed in "Have Fun at Work" by W. L. Livingston
https://www.amazon.com/Have-Fu...
"The practical abilities of engineers are buried and ignored by institutions whose sole objective is their own survival. Whereas the individual engineer has a publicly admitted duty of care for his fellow beings, institutions have no such concern, for their aims take no account of the human cost of their activities. This Handbook provides the recipe for the survival of the practical professional. The Handbook is offered to serve the needs of the professional engineer but it demands a much wider readership for it examines the interactions between the responsible individual and the supra-human entities that constrain and control him."
He provides examples of presenting suitable candidates to organizations desperately in need of them who the organizations reject in their ignorance of their true needs.
Bottom line: interviews are a game. They don't have to make sense. You chose (and also demonstrated) you did not want to play the game. So, they effectively screened you out as a non-game-player.
Of course, it is possible those organizations may collapse because of screening out such people -- but that tends to be the nature of most organizations and potentially self-limiting social processes. And those reasons are not all bad -- given that humans evolved in a context of living in cooperative hunter/gather tribes who in a sense were playing a collective game together.
See also: ... One well-known firm that Mats Alvesson and I studied for our book The Stupidity Paradox (2016) said it employed only the best and the brightest. When these smart new recruits arrived in the office, they expected great intellectual challenges. However, they quickly found themselves working long hours on 'boring' and 'pointless' routine work. After a few years of dull tasks, they hoped that they'd move on to more interesting things. But this did not happen. As they rose through the ranks, these ambitious young consultants realised that what was most important was not coming up with a well-thought-through solution. It was keeping clients happy with impressive PowerPoint shows. Those who did insist on carefully thinking through their client's problems often found their ideas unwelcome. If they persisted in using their brains, they were often politely told that the office might not be the place for them. ..."
https://aeon.co/essays/you-don...
"How organisations enshrine collective stupidity and employees are rewarded for checking their brains at the office door
And:
http://disciplinedminds.tripod...
"Who are you going to be? That is the question.
In this riveting book about the world of professional work, Jeff Schmidt demonstrates that the workplace is a battleground for the very identity of the individual, as is graduate school, where professionals are trained. He shows that professional work is inherently political, and that professionals are hired to subordinate their own vision and maintain strict "ideological discipline."
The hidden root of much career dissatisfaction, argues Schmidt, is the professional's lack of control over the political component of his or her creative work. Many professionals set out to make a contribution to society and add meaning to their lives. Yet our system of professional education and employment abusively inculcates an acceptance of politically subordinate roles in which professionals typic
A 21st century issue: the irony of technologies of abundance in the hands of those still thinking in terms of scarcity.
Additional point: in the Seven Samurai movie, even Samurai could not agree on what was the best way to do a certain combat move -- until it was solved by the death of one of them when they did the move for real...
Another difficulty in good programmers recognizing others:
https://en.wikipedia.org/wiki/...
"The Dunning-Kruger effect is a cognitive bias in which low-ability individuals suffer from illusory superiority, mistakenly assessing their ability as much higher than it really is. Dunning and Kruger attributed this bias to a metacognitive incapacity, on the part of those with low ability, to recognize their ineptitude and evaluate their competence accurately. Their research also suggests corollaries: high-ability individuals may underestimate their relative competence and may erroneously assume that tasks which are easy for them are also easy for others. Dunning and Kruger have postulated that the effect is the result of internal illusion in those of low ability, and external misperception in those of high ability: "The miscalibration of the incompetent stems from an error about the self, whereas the miscalibration of the highly competent stems from an error about others.""
Further, a good programming team in most situations may benefit from diversity. The same characteristics that make some people good at some programming tasks may make it more challenging for them to see some of this diversity.
"The Difference: How the Power of Diversity Creates Better Groups, Firms, Schools, and Societies" by
Scott E. Page
http://press.princeton.edu/tit...
"The Difference reveals that progress and innovation may depend less on lone thinkers with enormous IQs than on diverse people working together and capitalizing on their individuality. Page shows how groups that display a range of perspectives outperform groups of like-minded experts. "
An old African proverb says, "If you want to go fast, go alone. If you want to go far, go together."
So, there remain no easy answers.
Google is trying Big Data as rutabagaman linked to, which led to this conclusion:
http://www.nytimes.com/2013/06...
"A. On the hiring side, we found that brainteasers are a complete waste of time. How many golf balls can you fit into an airplane? How many gas stations in Manhattan? A complete waste of time. They don't predict anything. They serve primarily to make the interviewer feel smart.
Instead, what works well are structured behavioral interviews, where you have a consistent rubric for how you assess people, rather than having each interviewer just make stuff up.
Behavioral interviewing also works -- where you're not giving someone a hypothetical, but you're starting with a question like, "Give me an example of a time when you solved an analytically difficult problem." The interesting thing about the behavioral interview is that when you ask somebody to speak to their own experience, and you drill into that, you get two kinds of information. One is you get to see how they actually interacted in a real-world situation, and the valuable "meta" information you get about the candidate is a sense of what they consider to be difficult."
But when you think about that, if you are not hiring programmers for their ability to hire other programmers by asking such questions and evaluating such answers, and you are not coaching them on that either, why would you expect they could do a good job of it?
Having *really* good HR people specializing in evaluating developers for a role in a team might in theory be an answer... But then the question is, how do you hire really good HR people? :-)
A 21st century issue: the irony of technologies of abundance in the hands of those still thinking in terms of scarcity.
The Chicago Fire Department -in order to avoid allegations of racism- instituted a written test to determine hiring for the position of Fire Chief. Double blind and all that.
The applicants who passed the test were less likely to be of certain ethnicities so the entire test was ruled to be discriminatory.