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.
'cause I like humping your mommy,
and getting caught by your dad.
If you're not into poota,
and you have half a nad.
If you like humping butts at midnight,
in the smooth anal gape.
Then I'm the one that you searched for,
come to me and assrape!
- Helen Gurley Brown
I like C#
If these companies expect the equivalent of genius AI to be working for them, then it behooves them to WRITE that kind of AI themselves. Otherwise, f-off with your unrealistic demands and expectations.
CAPTCHA: "infidels"
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.
The only better metric I can think of is if you have published a lot of programs, and
you can say, "see look at my work - it's successful..."
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?
landing a top SWE job is harder (sometimes much harder) than actually doing it. So is getting into MIT harder than studying there. Why is this a problem? The process is not broken, stop whining and go brush up on your O-notation.
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.
Programmers are asked to program in a job interview - what a ridiculous idea. Perhaps when I hire programmers I should ask them to paint or dance? And then there's the racial/gender/age bias nonsense on top of it. We've been asking programmers to write code in all job interviews, and: about half the team is women (including 2 of the 3 team leads), and about 20% are white (rest are Russians, Indians, Asian, Israelis). Why would asking to code be a bias against anyone except people who can't code? Interviews are never an exact process, and I agree that riddles ("a chicken and a half lays a egg and a half in an interview and a half") and knowledge questions ("what is NP complete") are a waste of time. But if you can't code a sorting algorithm without a reference, or if you can't come up with a simple client server algorithm, or if you can't devise a locking scheme to have multiple threads cooperate on a resource, then you don't have the skills I need. I might be missing people who'd be great on the job if I just gave them a chance, but I can't just hire someone and fire them 2 weeks later if it turned out they can't do the job. A free trial would be ideal, yes, but it's not realistic in our job environment. BTW, I always ask interviewees to write code at home and email it to me - this can count as another way for people who struggle in front of a whiteboard to get a second chance. But I've never seen someone who was great in the email and awful in front of the white board.
"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.
"Hello my name is Mike, I'm a GDE and lead at NY Times, I don't know what np complete means. Should I?"
1. Since he works at the NYT, nothing he does matters. The newspaper's output is harmful or nonsensical, so in a way it is better if it isn't published.
2. Thanks to the wonder of Google, he could find out what "NP complete" means in about one minute. So the question is: does he think finding out would be worth one minute of his time? Further, if not, how good a programmer can be become?
3. If you think about it, he can't really judge whether he should know what "NP complete" means until he knows what it means.
I am sure that there are many other solipsists out there.
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?
Yea because everyday we write bubble sort algorithms. I kind of agree with the P and NP. That is kind of important. But writing algorithms on a whiteboard? Come on that's just not realistic.
When I get asked this question I'm tempted to ask back "can I use the bubble sort function in the standard library?"
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.
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.
Hi, I get paid $95+ per hour to fling shit at walls in a top-tier company but I don't want to actually be tested about my knowledge or capabilities. I would fail the test, so the test must be wrong. Yea, that's it.
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.
Having no life is a requirement for my job. The hours are bad. If you don't have time to cram for the interview you don't have time to do this job. It's really that simple. That's why they want you to cram for the interview. It not only shows dedication and ability but it shows you have no freakin life which is as important as dedication and ability. Verbal assurances of "dedication" (cramming for the interview is of course also the only way they have to measure your dedication) and actual skill are both irrelevant if you cant actually do 80 hours a week when your employer needs you to do 80 hours a week. If this isn't fair to poor people who have to work 2 jobs or take care of kids while looking for a tech job -- the industry doesn't care and they shouldn't be expected too.
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.
(Personally, I wouldn't ask a candidate about bubble sort because that's so trivial as to be insulting.)
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...
But can he determine if it is useful or not in polynomial time? That is the question we should be asking.
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.
I don't know what np complete means. Should I?
Hell yes.
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.
I interviewed with amazon recently, 4-hour interview, 4 different sessions, and I got an SDEIII job offer, woohoo. They do expect you to know well-known algorithms, including algorithms for sorting and searching, along with knowing which data structure to use when, and how those structures work internally.
But I can say without any hesitation, that the interview was more about how your thought process and approach to problem-solving works as opposed to just jotting down a depth first search that you've memorised.
Those things, along with things like object-oriented design and Big-O notation, as examples, are the very basics of computer science. If you can't answer questions about those and use that knowledge in solving the problem they present you in the interview, then what should they ask you?
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?
Ok, the first one is kinda meh. Remembering all of those sorts is a pain, and proving that you know a bucket sort from a quicksort isn't very useful.
But those other two are inexcusable.
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.
And NP-completeness? I don't expect a programmer to to be able to do a proof of NP-completeness, but if they are to touch ANY programming AT ALL, they should AT LEAST have an inkling of what NP completeness means for their line of business, along with other fundamental concepts (big O, etc).
Otherwise they aren't "programmers", they are code monkeys. They type a lot of code that some times works, be it by sheer luck (just don't pass any strings with more than 128 characters, and make sure every string starts with an '*') or by brute forcing the problem. That is, they write a lot, but produce very little. And then you end up with another openssl, a clusterfuck of epic proportions.
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.
Please retitle this article.
The correct title should be:
Someone who 'graduated' from a 'coding academy' butt-hurt about not being able to land a job at Google; and something something: Diversity.
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.
...or can't figure out how to get a length of a string in Python, you shouldn't be hired.
Computer Science is learning how computers work, algorithms, operating systems basics, networking, theory, data structures, and other topics.
Depending on your program, you may implement those ideas and concepts in the language of choice. When I went to school, it was Turbo Pascal. When you got a job, many employers at the time had a training program where part of it was learning the language they used. COBOL in the case of the big Hartford Insurers.
Anyway, a language is just syntax. If you need the "right tool" for the "right job" to implement an algorithm, then you are a code monkey.
Now, what you would be looking for is a code monkey. Someone who knows a language and it's libraries and gets the job done. There are plenty of folks out there like that - they are a dime a dozen and if anyone has a hard time finding qualified people like that, there is something horribly wrong with one's recruitment process.
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?
I have seen this used very effectively. When used effectively, it is not to see if someone can remember some algorithm that they may have heard about or even seen used sometime. It is about them writing a simple function to do something like convert an asciii string to an integer.
It is an exercise in seeing how they think. Do they check for errors? Do they handle error conditions? If so, how? What assumptions do they make? Is the code reasonably efficient? Is it readable? Do they do test cases for themselves? Do they ask questions of the interviewer to make certain of the requirement?
It is not about remembering some algorithm, it is very useful in seeing the thought process and mindset they use in answering a question and providing an answer. Showing attention to detail. Something they will have to do everyday on the job.
How anyone thinks it has anything to do with gender, race or age is beyond me. But then again I am on the higher end of average programmer age these days.
Soooo. We are supposed to hire now based on age,sex or race. Not on who can do the job best? Sorry but if the 22 year old out of college who may be white can do the job better than the 55 year old black guy in a quarter of the time saving the company money and doing a better job, I'm going to hire him. We need to quit trying to base things on stats like age or sex.The person that does the job the best and the fastest is best for the company. While it makes us feel good and want to sing kumbaya by the campfire to hire the older person of a certain race, it doesnt do anything for the company's bottom line.
No the fucking job is writing code to accomplish business processes in a efficient manner. The best code is not the goal of the business units you work for, maybe your dev team mates have that as a goal, but it is really a dream.
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.
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.
Relax, kiddo. There can be more than one problem with something. Recognizing Problem #2 isn't a denial that Problem #1 exists.
Classic example of box checking by the Interviewer and not understanding the content or context of the problem. Actual supervisors who use this method fail to see they are blindsiding themselves through recent personal experience and not actually looking at the skills of the person at the blackboard. Its holding a mirror up to the person conducting the interview... as in the Interviewer "fails" if they actually ask another person to step up to the blackboard/whiteboard.. they are not paying attention to the person in front of them.. they are navel gazing.
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."
The issue really is can you figure out how to do these things when necessary, not that you have all this knowledge stuffed into your brain. I want to know how you deal with stuff you don't now off the top of your head, because nobody knows everything.
BTW... Who on earth implements a bubble sort these days anyway? What a waste of programming time. Most of these "common" algorithms already exist in libraries where the implementation is better than most programmers can produce and take a LOT less time to use.
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...
I don't know proper variable naming rules. (_, Ucase, camel?). I have a tool for that. I don't remember how to spell the names of properties, fields, or functions I use. I have a tool for that. I don't know how to write elegant linq queries. ... I have a tool for that! I don't code without checking example code for how to do things. (I don't have the time to learn off of my mistakes, I'll use yours). I have tools for that. Blogs, Stack, Vendor Documentation. Stop! Hassling me with your insipid questions that only serve as a demonstration of memorization of facts that are easily accessed in real time.
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.
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"
Unless you're submitting papers to journals and obtaining patents daily, then no, you're not coming up with new algorithms. You're mashing together existing algorithms to do stuff.
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.
But I have no problem keeping track of a matrix of quadruple pointers."
"I'm sorry, we were looking for someone who can actually code and don't speak mumbo jumbo."
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.
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.
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.
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?
I'm a 42 year old who never finished college and none of those three questions were anything I needed to look up and I have a total of 3 hours Python coding experience.
None of those questioned needed preparation or cramming. I might google the answers in a work environment to double check my memory or facts, but bubble sort is something you learned by playing with Microsoft QBasic demos back in the late 80's as well as insert, quick sort and others. NP complete is something you learned by watching piles of TV shows that are obsessed with P=NP such as N3mbers and then performing a brief Google and reading a while. Finding the length of a string in Python shows up in pretty much even code sample for Python ever written.
Honestly, while I wouldn't bother asking such silly questions as they are all kinda lame, I might instead present an algorithm and ask for an optimized version with possible Big-O justification as a bonus, all of those questions were perfectly reasonable.
I would expect pretty much anyone worth their salt to consider those relatively trivial questions to identify whether the person has any education or experience.
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
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.
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.
"in other words, it doesn't help diversify the field with women, older people, and people of color."
I'm sorry. This is just a lie. How does being a recent college grade make it detrimental to women? Women make up something like 66% of all college graduates. I would say that favors them SIGNIFICANTLY.
I can write bubble sort, binary recursive sort and more and I couldn't get an entry level job so I work as a stock boy.
That is just Racist, why can't we have any Blackboard questions?
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.
As a retired programmer / manager, I've seen the best and worst of the interview process. After taking an internal class, I learned one simple rule for good interviewing: only ask job-relevant questions. This may sound obvious, but it really isn't to a lot of people. Not only does it help you avoid legal trouble, it helps you hire great people by focusing on what matters most and treating the interview seriously. For example: if you need somebody to work on your custom sorting logic, then great, ask about how to implement a sorting algorithm. Otherwise, don't ask about sorting and find a more job-relevant question.
From the perspective of "only job-relevant questions", then a lot of the tech industry's favorite questions/puzzles/riddles are laughably bad because the only purpose of the question is to make the interviewer look smart (and therefore are a complete waste of time for all involved).
As an interviewee, you can and should keep the "only job-relevant questions" test in your head too. It lets you quickly assess during the interview process how well or how poorly the hiring company is run.
If you're coding as an employee, you're going to be subject to this and worse in the future. Salaries do not scale commensurate with ability or effort, and once you've got the grey hair, you're done. I'm 40, and am happy I exited; I easily have more than a million lines of code in production still, much of it decades old at this point.
If you don't want to be abused, if you're a good programmer, you're probablquite intelligent.
#1: Do something else. If you're smart, other things pay very well. Once you have substantial savings, your options increase.
#2: Start a company. If you're as good as you think you are, bang out the code and see what happens. Computers are cheap and AWS makes scaling trivial.
#3: Contract. If you can deliver on time, this is the best option if you're actually good and don't want to run a business.
Otherwise, enjoy the outcomes of the golden rule.
I opted for #1 - formerly an EE, moved to finance, can move back to engineering if I want after a decade of working in finance, having accumulated enough fuck you money to not worry.
Stop being a victim.
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.
So you are saying america is not a democracy but a stupid totalitarian slavery. Was there a point of immigrating from a better social model into more inferior?
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...
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. ;)
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.
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?
I have interviewed a lot of people. I have a range of questions from the trivial to the impossible. This lets me see where the person is on the range. It also lets me see if they will try to BS their way through or if they will give an honest "IDK". Being honest makes up for a lot. I will take an honest hard worker over a genius BS artist EVERY DAY. I also do not have hours to spend talking to each candidate or a spare machine to leave them for hours with a problem.
There is a large group of people who want a programmer's salary, but don't actually have a programmer's skills. They can do basic scripting and can google for answers, and as such they can easily glue together third-party components and solve the simple problems. They think that is what it means to be a programmer. So when you hit them with something that requires actual programming, they get all miffed and insist that such skills are not needed in order to be successful.
I don't hire people like that.
Does anyone here see a pattern? "I contributed to ... I built ... I have a github which is used by ... and now I can't get hired ..." I've noticed in my career that the minute I put actual products, that people could see, on my CV, the level of hostility I got in these types of interviews ratcheted up.
Karla Monterroso, VP of programs for Code2040, an organization for black and Latino techies,
In other words, a racist organization. What outrage there would be if I ran a similar organization for white programmers. But this is apparently not only OK, I expect that I'll also get modded down for even mentioning it.
I'm an American. I love this country and the freedoms that we used to have.
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.
Lol. You've been drinking the coolaid. You know what you sound like? Someone who got thier first job.
The reality. Business doesn't trust you. If you even know what trust means. You are a risk to get the job done or not done. You're just a lower risk then somebody else. If soon as you don't meet the deadlines you are fired. They're not your friends that trust you and love you and hold your hand they do not give a fuck about you
As far is you see the best code and then you say good code because you realize that the passcode is a matter of efficiency. If you know anything reaching 90% efficiency is pretty easy but getting that last 10% is so expense or impossible. So good code yes that's a requirement the best code means that you were the best programmer and most of us have a never met a best programmer.
All that other crap about being the fastest running time and most efficient and using the least amount of memory. It's clear you don't understand the technical requirements from the business requirements.
You just sound like I'm a naÃve little child that got their first job and think they're going to work there forever and everybody loves you.
When you find your next job, you'll barely or not at all talk to your former workers and they will not give a shit about you because they have to be concerned about their own lives. You must be one of those millennial's or something because you're not living in reality.
Don't worry, you'll get your dose of reality soon enough. Whether you decide to move onto another company and see how much the last company really cares which is not at all it is a company it is a legal entity it is not a person that cares about you.
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 work at a research center in one of the big companies in the bay area and many people in my company have left for google research. They usually spend a year learning the same tired old coding questions because that is what google asks regardless of what position you are applying for! My colleagues are not going for engineering positions and they are not engineers! We all have PhDs from top schools in the country and our job is research and coming up with new algorithms, yet we have to do bubble sort in the interview. It blows my mind. What the hek is wrong with google!
No it vastly more than just a big hard drive. There are 3 main computational theory about parallelism and AWS introduces specific complexities. This is not an easy topic.
The point isn't if you can read the book. The point is how much you already know. I can read French with a dictionary I can read English without one.
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.
Even though I've semi-retired from IT, I browse crap I get from recruiters in my email just to see if there is something that might strike me as interesting enough to look into. I've 'retired' twice and my ADHD keeps me from sitting on my ass more than a few weeks before I get bored doing nothing.
Anyway, I saw a Systems Analyst/Engineer position that seemed interesting, did the phone interview and they were impressed enough to want an in-person interview and mentioned to the recruiter that I'm so qualified 'they were afraid I'd get bored with the job'. So far so good. Now, a suit was required for the interview, which is unusual in my experience (I live in the South and it's usually too damn hot for a suit, even a light one.), but I need a new suit anyway.
I go to the interview and trampled all over the technical and 'how would you handle blah blah blah' personality/communication skills questions. Then I'm asked to look at the white board behind me. On it was drawn was looked like a game of hangman, and a large square with a + in the middle to break into 4 smaller squares. They asked me that if the lines of the box were matchsticks, how could I move 2 and double the larger square.
The 'hangman' drawing (which wasn't hangman, it was a very badly drawn scale) was 'if you have 8 widgets and one is heavier than others, how would you find the heavy widget in the fewest number of weighings'. Both of these are straight off MENSA tests (at least variants thereof). I've never done anything more than just suck at the matchsticks puzzle, and even though I got the 'heavy widget' one 'correct' I wasn't offered the position. Why? Because they didn't like how I thought my way through the puzzles. (The matchsticks one, I flat out told them that I'm no good at those type puzzles as I don't think the right way to come up with an answer for it.
In neither case were those questions relevant to the position, or my ability to do the job. Being able to answer MENSA puzzle questions doesn't make you qualified to do the job, just that you can answer puzzles from the back of the evening paper. Needless to say, I let the recruiter AND the company doing the hiring a very long (but polite) ass-chewing email after I was not offered the position. Not that I would have taken the job had I been offered it. I wasn't angry about not being offered the job, since I am independently wealthy and work just because I want to and feel I can still contribute to the right organization, most times at lower compensation than others would. I was pissed because shit questions like that are MEANINGLESS as to whether you can do the job.
Of course, you can thank Google for this type of bullshit nonsense. Their interview questions are notorious for silly shit like this and others think its cool to do the same. Actually, they just look ridiculous and will almost always turn down the best candidate because of puzzle questions like that.
I shake my head every time I see crap like that going on.
Pax Vobiscum
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
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.
Would you hire a surgeon based on how he talks about the surgery, or actually performs it?
>> 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?
These interviewing techniques are the product of (Multiple Answers Accepted!):
1). Lazy interviewers;
2). Fad-driven evaluation processes;
3). Major, and usually invalid assumptions about "what programmers/analysts/whatever MUST know, or else they just aren't real, authentic, competent programmers/analysts/whatever";
My major programming skills are:
1). Being able to imagine, then design and build, the end state solution;
2). Workflow analysis;
3). Making users comfortable that I know what I'm doing and they can trust me;
4). Simplifying as much as possible, and then knowing to stop right there. There are both necessary and unnecessary complications and you need to know the difference;
5). What kind of problem am I working on, what kind of organization is this, and what are their expectations in relation to these attributes? A bank or hospital is very conservative. A rock band or MIT Media Lab might be more adventurous;
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.
I've been developing software for 20 years. I had an interview for a contracting position at Microsoft and had a white board interview. The interviewer kept asking me to implement a queue with a few variations. I didn't do too well. All throughout the interview, I thought the whiteboard exercise was so pointless. Most of these algorithms are just a search away. No one needs to memorize this anymore. It's a complete waste of brainpower. Additionally, the interviewer was so focused on the whiteboard he didn't ask me about the many other skills I brought to the table. Not one question about unit testing, agile, dependency injection, accessing databases, etc. He didn't even ask about my previous experience very much. After the interview, I decided that Microsoft was not a place for me. As Danny Glover said in Lethal Weapon: I'm too old for this shit.
Hello, my name is T and have been coding for 20 years, I can write code without internet in notepad. This used to be the norm.
These days a lot of people who are very skilled in copy pasting other people's work, they are very good in trying 20 solutions from stackoverflow without really understanding what they do. Although these people deliver, they don't deliver quality. These people aren't coders, they are scriptkiddies, no matter what their professional title says.
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)
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
Typically, I would implement a quick sort down to groups of 16 recursively, then perform a merge sort on the small groups.
> 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.
So you're telling me that women and people of color cannot be young CS grads from top-tier schools who have had time to cram?
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.
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.
I agree with them (posted quotes). I still look up examples / syntax online when I encounter issues as well, even after 10 years in the field.
It's not the syntax or language that matters, it's the mindset. I know what I want to do, I know or believe that the language can do it, I just don't have the syntax or structure I need to achieve it. From schooling, I understand the algorithms and their general implementation, which ones will accomplish what I need them to do and I can pseudo code on paper down to a level low enough where I can search online and identify the code / functions / etc. I need in order to accomplish the development task.
The correct answer is not always the literal answer to the question.
Absolutely. Been job hunting the last 8 months in the Bay Area and every company/recruiter haphazardly sends out "coding tests or homework". It basically turns you into a metric and less of a person. These tech questions and coding exercises can take hours. One recent homework assignment was to code a whole project using Youtube's API from start to finish. I spent 4 days on it. Then after 3 weeks I get a standard rejection letter. I tried to get any feedback on my work, but nothing. I'm done taking these tests.
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"?
I doubt you have come up with a new algo in the last year, much less every day. Maybe you THINK you invented lots, but your ignorance doesn't make it so.
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?
That is creimer the troll's best post to date. He thinks that if a language shares 45% of root word origins, that you can speak it. Apparently we all speak Spanish, French, Italian, and Latin as well as English.
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!
Dur dur dur
The business side is interested in outcomes not how you got there or if it took a few more cpu cycles to get there. This is not the time of servers with only MBs of memory. Well their trust in you I am guessing is because they have no basis on how to make such a choice. They are just hoping you choose wisely. I have meet a few developers that really knew everything, but they seem to lack the ability to get things done by deadline. After all, deadline is all that matters to the business side of things.
They way I see my work is, I am usually like most of the programmers on here, hired to do client server applications. That require me to either do back end server and/or frontend client work. The skills needed that I think are most often missing even from CS majors are client/server issues. The ability to setup a server, debug a network issue, and understand tcp communications.
And even then you can't tell if they'll be any good because a lack of common sense can trump any skill level.
Makeup of college CS programs.
I point interested parties at my (online) resume, which in turn has links to the applications and documentation I've written (many, at this point.) I tell them both directly and at the very top of the resume that I only do remote, and that I will not be visiting their campus, but they can visit me any time.
I haven't had a break between contracts in four years.
You don't have to tolerate the kind of bullshit HR drones are cobbling up if you have real chops. What you need to do is get some real high quality work done, make it public, and that puts you in the position of setting terms. Google won't hire you? Congratulations, you don't have to live in an area where the cost of living will chew your income down to McFryCook level.
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.
Even knowing about P and NP can help you avoid trying to find solutions that may not exist. Or at least help you know when to solve a restricted subset of a problem instead of looking for a general solution.
The other day, my ClickOnce deployments stopped working. Sadly, neither bubble sort nor the length of a string in Python fixed the problem.
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.
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 company I was interested in sent me a pdf with instructions to solve a problem if I could or do as much as possible in the course of a couple hours and email it back.
I think that's a legitimate method of testing for coding ability.
If it's perfect and complete then something is fishy assuming the problem is hard enough it can't be completed in the time allowed.
I got some parts of it done and I did get a call for an interview, unfortunately they took a long time to call me and I had already accepted someone else's offer.
(on a side note.. the thing that really makes me angry is I'd done exactly what they had wanted about 5 years before but didn't recognize the problem until too late and my old code was pre-college and a mess)
So how many of you supposed interviewers own a new house? When you bought it did you have the builder create a Lego House in front of you using no references before committing? (Apologies to Ed Sheran) Or how about having that builder make a birds nest with an unrealistic time constraint? did you ask him to play some perverted version of the kids game 'Battleship' where you lob random questions at him to _guess_ what his/her skillset covers? Or did you just ask "What have you built and how did you do it -- i.e. show me?" "Can you connect me with your satisfied customers?"
I'm currently on the receiving end of this kind of crap as a senior developer. It's completely and utterly inexcusable as a selection process, and obviously based on flawed assumptions (doing atypical things in atypical settings doesn't tell you anything useful about day-to-day behavior.) But does seem to fulfill certain individual's need to feel self-important: "Ohhh, I'm so smart that you couldn't answer my puzzle and so are unworthy of working with me".
You gotta be kidding ...
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
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.
Is actually very reliable.
It's been attacked as racist because it reveals differences between races.
But they tested it in many different ways and it's totally accurate.
It would say much more about your ability than theoretical questions.
Another way government reducing freedom is bad.
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.
negative account balances are a fundamental concept of banking going bank hundreds of years.
let us all be glad this company does not exist anymore, god knows what they would have done to their customers.
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.
I like telling recruiters to go fuck themselves with a dictionary and sharpie pen.
If you get 10 applications for a position, it's enough test if they can do their actual job well. But what if you get 1000s, which I presume is the case with the likes of Google? If the position is something like "Python developer", how else do you filter applicants?
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
I'd probably laugh if I was in a job interview for something that was about engineering / applications and not about fundamental research and the question about NP completeness came up. Asymptotic complexity are useful to know, but if you want to apply your knowledge in the form of efficient code that does a particular job well and doesn't solve the most general case of the problem at hand, you will have to know a lot more than, say, a definition of the classes PTIME or NPTIME. There are NP-complete problems that can be solved very efficiently in practice because the really bad instances never come up or rarely enough that it doesn't matter (here, it's more about precisely knowing the kind of problem you're solving and also knowing your inputs and their encoding in detail), SAT and its many applications being a prime example. And there are PTIME algorithms that perform worse in practice than their NPTIME counterparts (take linear programming or primality checking as examples). If you want to know the performence of an algorithm it is not sufficient to consider its asympotic time or space complexity and in some cases (probably the ones that are interesting in day to day operations) it can be actively misleading. Often, these types of theoretical considerations can only provide the same level of information as the gut feeling of any reasonably competent programmer can (e.g. multiple nested loops that on average all iterate over at least half the input can be bad). There is one exception that might be useful in practice as well as theory: If you have an algorithm that claims to solve problem X with complexity C and you know that the lower-bound for problem X is actually C' > C, then you can automatically declare the algorithm faulty without further inspection. Probably not the kind of application of theory that most people readily come up with. I think it would be much better to ask the candidate a question like "How do you make sure that your code is optimal for your problem?" And then see if they begin to methodically address the question by first defining what they think optimal means and when a certain kind of optimality matters or not, what theortical and practical tools they know and use, when and why they use them, give some concrete experiences with their own or someone else's code, etc. That it, unless you are looking for a theoretician and have a certain task in mind that requires deep knowledge about complexity theory (not just the stuff that's taught in some intro level algorithms course).
Recruiters and HR people generally don't know the details of what it means to be a software developer. I think the issue lies there. To a certain extend, as a software developer, you are interviewed by computer illiterates that cherry pick stuff on the internet, expecting you to know it all because they surely don't understand.
So can we have "an organization for white techies"?
Oh, I see... "black and latino techies" aren't as intelligent as white ones, so they are failing to get jobs... this is just another shakedown.
Nobody is stopping you from setting up your own software companies. Nobody is stopping you from moving AWAY from white people, who apparently are ruining your lives. Why aren't you moving?
Oh, and you get to KEEP your own races' countries, while white people have to GIVE UP ours, to the rest of the world...
Why are you here? Why don't you want to live around your own kind? If you don't want to live around your own kind, why should white people?
Why are you 'good' when you try to move AWAY from your own race and into white people's countries, but white people are 'bad' when we merely suggest that we want to get away from your race too?
From the article: "“Whiteboard” interviews are widely hated. They also discriminate against people who are already underrepresented in the field."
The magic word "discriminate", which means "choose".
So "don't discriminate" means, quite literally, "don't CHOOSE".
So don't CHOOSE who you have to live around, or work with, or go to school with, or that would be "discrimination".
But freedom of NON-association is the most fundamental of ALL human rights - the right to NOT live around people whom you don't want to.
But apparently, their right to FORCE themselves into your living space is more important than your right to simply have nothing to do with them. And if you want nothing to do with them, they call you "racist", because they can't stand the thought of you simply GETTING AWAY FROM THEM, and having no effect on their lives ever again.
This entire article is about the usual suspects - non-white parasites who can't compete in a white country, moaning and whining so they can be given jobs that they are UNQUALIFIED to do, thus bringing the host (white) country even further down.
Or would anybody care to tell me why I'm wrong? Because very soon YOU'LL be affected directly by the plague of non-whites who are destroying your country from within.
Because back in the 1980s, when the ZX80, ZX81, Spectrum and C64 came out, teenage boys (WHITE boys, by the way), in their bedrooms, were teaching themselves MACHINE CODE, and writing games in MACHINE CODE. This article is plain evidence that we are surrounded by idiots who can't even fucking code without looking everything up.
"Karla Monterroso, VP of programs for Code2040, an organization for black and Latino techies, wrote in a critique of the whiteboard interview. “An individual can spend thousands of dollars learning the cultural norms necessary to get themselves into a desk at a technology firm.”
Get that? "learning the cultural norms necessary" Which translates into: "Waaahhh!! Racist!!! White people too intelligent for me to get a job!!! But waaahhh! I don't want to live around my own race, in my own country, because I know how useless they are!!!"
Anybody got a better explanation?
The next article is about Twitter, it says: "And if you’re creating a small army of accounts to harass, say, a female game developer, it saves time not to have to pick out photos"
Yes, that would be it... female developers are being "harrassed", and we must silence EVERYBODY who isn't 'politically correct', or who uses "hate" speech (LOL), which means "anything the Jew doesn't want you to hear"...
The denial of free speech is the first act of tyranny.
What happens when white people become minorities IN OUR OWN COUNTRIES? Will these whining non-white parasites give up their demands for 'special treatment' and free jobs that they aren't qualified for? Hell no, they will ramp up their endless demands. They hate us because we're white.
My first interview with this testing mentality was with MonkeyWards (for those of you youngsters that was what Montgomery Wards was called!). I was 19 at the time, graduated from the U of Chicago and was asked to write a program. I got up and told them to go to hell and walked out. That was 1969.
Because of my experience in starting 6 companies and building complex real-time systems I was asked to interview with Google, Amazon and Facebook. I walked away from them all because they have stupid interview requirements like mentioned in the article. I walk away because they don't really understand but are more concerned about process! As some one that has been on both sides of the table I found it wasn't being able to write programs that mattered but how well you could solve problems that was important.
As an first year college student I had to take a class on how to use the library. I asked 'Why?' and was told you were being thought how to find the answer. That is how I think about programming and programmers. Does one think clearly enough to understand how to find a solution to the problem at hand. That is the important point.
Personally I think this "testing" mentality was put together by HR people because they don't get it. One good programmer can recognize another good one.
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.
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.
We (I, well I am returning to HQ so this project isn't mine anymore) follow
http://tiny.cc/trivagoU
pre-assessment, no interview, job given if you finish the pre-assessment.
probation period is more like a long interview, where we go through all parts of expectation (for both employee and team mates).
We have a very high acceptance rate and scalable growth!
That sounds worse honestly. When I go to an interview I'd like to discuss my subject matter expertise with another subject matter expert. I can talk about projects I've done and problems I've solved. If by the end of that discussion you aren't convinced, simply pass. I don't want to spend hours working on some contrived test.
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?"
I'm not going to solve your fucking riddles. If you want riddles, go watch an old episode of batman.
My little brother graduated from U of C, his first job back home was overnight operator. They were transitioning from a PDP-11 to a S/32, and everyone else involved explained the prob,ems converting charsets and how it would require rekeying data. He wrote the routines to move the data in his slack time and showed his supervisor in the morning. Promptly fired.
He got a call mid-morning from the business owner, asking if he would have lunch with him. Yeah, the boss apologized that his IT director was so hasty and offered a job as entry level programmer on the S/32 (which at UofC he studied RPG) which my sharp little brother accepted, despite having to work with a prick of a supervisor. He had that job in 3 years.
This is the little brother who was overnight operator at UofC when the flood came. On the phone to his boss giving minute by minute updates on the water under the machine room floor, they survived without cutting power. He's had fun in the industry and still works with RPG despite IBM's insistence that it's obsolete. He hires programmers who have a portfolio and can explain their code, can identify the gotchas in the platforms he uses, and can explain their high-level solution to a hypothetical, usually a payroll problem, because, as he puts it, the three great lies are 'the check's in the mail', 'you're the most beautiful...', and ' I can write a payroll system for less than 30 employees that is better and cheaper than anything you can buy'.
My good friend who interviewed for a web services job at a very well known company here in Phoenix where he was sat in front of a workstation and asked to create a basic business web page in an hour. He apologized that the page lacked a bunch of stuff he couldn't quite figure out having just their internal dev tools which he was learning on the fly. Hired on the spot. Most applicants never got anything to load in a browser, but the point was just to see if they could rationally organize their work. He worked around a Javascript flaw their tools induced. Winning.
And I am once again glad I am not a working programmer.
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 conducted a lot of whiteboard interviews, but I never cared about arcane topics or classic tests like string reversal, Fibonacci, etc.
In my eyes, it is interesting to see the thought process of the person and I'd set up a complex problem and ask them how they would solve it; at the end of the session, we'd end up with a bunch of graffiti and pseudo-code.
You can see that some people are very creative and come up with smart ideas, at the opposite some just give up right away and tell you they don't know and no matter how much you actually try to solve the problem step by step with them, you can see they don't have it.
Since this is highly interactive, as we chat together possible approaches, etc, you get to know the person as well, laugh with them, etc which is very important since I always tell them they're going to spend more time with me than with their girlfriend.
I've been programming since 1984, worked on quite a few top game franchises and I'm still googling things every day and I'm using stack overflow all the time.
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).
Sounds like you wouldn't make it anyway. There are enough egotistical programmers in the market. ;)
...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?"
if you're waiting to see what fails at execution you need a better editor / IDE. It's not 1980 anymore, use something better than a basic text editor. ... Real Programmers don't use IDEs, right? well you keep being a "real" programmer, I'll keep being productive (and I won't have to google the name of object methods or the order of arguments, or even the various overloads)
Oh, wait
What the fuck has gone wrong here?
If a programmer doesn't understand recursion, pointers, architecture, data structures, algorithms etc they are not a programmer, they are an API monkey at best.
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.
duh, women and ppl of color can't go to school and therfor won't have graduate level knowledge of anything except cooking and cotton.
not to be insensitive, just agreeing that that part of the summary was absurd
"that relies heavily on technical questions." - like a computer science graduate should know. Look at the last sentence referencing black and latino techs (you notice it does not state programmers). There area many "universities" and "colleges" and they simply are not the same quality, so firms want to weed out the useful from the certificate holders. A Harvard CS grad will of written these algorithms by hand at some point, programmed them individually and had to use their first year implementations as the library for their third year project. The San Diego junior cheap college graduate will have heard the word in a lecture and told where to press a button in the program. Which one can handle it when something goes wrong?
Best programmer wins, period.
Whether that is a white guy, or some woman of color is immaterial.
If you can't problem solve, you are not a programmer.
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... ---
"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.