Really good interviewers and really bad interviewers both have idiosyncratic candidate judging methods.
Startups, when they start to hire at scale, try to standardize a methodology to compare apples to apples -- to avoid really bad (arbitrary) interview experiences in favor of predictable experiences even if those experiences are not excellent.
They look for interviewer formulae they can plug a random company developer, who would probably rather be working on something else, into.
My opinion of why creativity doesn't matter in tech recruiting (even in small start ups) is because the person making the decision to hire someone is going to have to defend why they hired that person to someone else (who likely is a business-minded person who does not have a tech background). If the hiring person can't have concrete documentation of why they hired someone, then it is the hiring persons problem.
We cannot ignore the social / political reality that underlies most of the decision making within a business. Having some sort of pass/fail mechanism is a way of insulating the decision maker from full responsibility of that decision
The problem identified in this discussion is that the criteria for hiring are rigid and too narrow in scope, not that they are ill-defined. You could defend why you hired aomeone even if you measured things besides algorithms, and used a dynamic interview process.
And, like it or not, this is one of the main reasons that certifications matter at some job positions. If I have two candidates that are equal in every way except candidate A is more creative but candidate B has the XYZ certification, which one am I going to be better prepared to defend when pushed?
I'm no grade A programmer. Yes, I know all the sorting algorithms and graph theory and all that. I can work effectively in a continuous development scrum based environment. I know .net and all the popular browser stacks. I can engineer dimensional ETL warehouses. Yada yada... Everyone can at this point.
What made me really famous in my little circle was my ability to do really fast problem mitigation. While all the other hardcore devs were freaking out due to all the stress of having to work and communicate directly with management while dealing with rapidfire requirement changes, I took it all in stride and just got it done. My reputation was this: if I was on the case, it got done on time and with a smile... period.
No one in any interview I've ever had was interested in that skill set. They only wanted to know about old school algorithm skills and how fluent I was with popular frameworks. It's as if upper management actually believes that my project management skills are irrelevant because hey! they've got project managers and staff for those. Why would a dev need it!
Oh, and I don't have a college degree. So, good bye... NEXT CANDIDATE!
The bar for "grade A" is REALLY freakin high. I'm not talking about applying for low level dev positions. I only apply for senior or higher positions. Autodidacts like me are no longer interesting to companies.
Not all companies. There are definitely places that are looking for your talents and that know how to appreciate them. Getting the job done in time and with a smile is a very large asset and should lead to some really good references.
I'd avoid applying for positions directly but concentrate on leveraging your network of past employers who will always know more people in the position of needing someone to simply deliver the goods. Applying for positions directly will work against you because you are setting yourself up for comparison in a way that does not show off your most valuable skills.
Last time I checked, most of their programming job postings had something along the lines of "Minimum: Tertiary Qualification/Degree ; Preferred: PHD/Masters".
Unfortunately I think the industry has to many in it that are just doing it for the $$ and learned their skils by rote and hence are recruiting people like them.
I think you're dramatically over-estimating the competence of the average programmer.
"No one in any interview I've ever had was interested in that skill set. They only wanted to know about old school algorithm skills and how fluent I was with popular frameworks."
What kind of companies have you been interviewing at? My guess is that companies with established products that customers are paying for would be very interested in someone who can quickly address customers' problems.
Used to. Not anymore. I feel like I'm the last of the old school waterfall experts. Everyone wants lockstep scrum only continuous development. I can do that, but then I have to get past the lack of a formal education and ultimately I'm only offered mid level positions.
I am also not a “rock star” developer and I would have no chance of answering all the language trivia questions in an interview, but despite this I have managed to solve complex problems that nobody else seemed to be able to.
On the topic of language trivia is there anyone out there that can keep it all in their head? I only spend about 25% of my time writing code and I need to work in 5 languages (C, Java, JavaScript, PHP and ObjC) on 5 different platforms (Linux, Windows, MacOS, iOS and Android). I find it impossible to keep more than a limited amount of all the detail in my brain at any time. How do you geniuses do it?
I work on a daily basis in javascript (server side jscript and node, and client side browser/extensions), vbscript, php and t-sql (and occasionally golang and ruby).
I mostly handle it by trying to stay in one "mode" for as long as possible. For example, I'll try to get all of my vbscript code done first, then the j(ava)script interop code, which are both server side, then I'll write the needed database code, then move to working in the browser once I have a stable api to work with. I try not to mix them unless I'm doing maintenance that requires slicing through all the layers.
I keep the documentation for all of the systems open so that I can quickly reference the stuff I forget. I just try to keep the major stuff "in cache", and then I remember the broad strokes and look that stuff up when needed. In addition to the official documentation, I have a directory of old code examples that I can lean on when I have to remember how to do some uncommon or rare things.
Even then, I still often use brackets in my vbscript and "end functions" in my javascript/php code. It's just a hazard of working in multiple languages environments that I've learned to live with.
This is pretty much the way I work too, but I find it hard to block in a good amount of time just in one language.
One thing I have found is that having separate monitors and keyboards for the different languages help me. I have a bank of them set up on a long bench and I slide from one to the other as needed. When I use this approach I am able to get back into the swing much faster than switching desktops on the one monitor/keyboard setup. There is something about changing the physical set up that helps me switch mentally.
I wonder the same thing. My code snippet database and the Google references have nearly everything I would need. But that doesn't work in an interview. They want to see you code on the spot with no backup resources including Google. They are looking for savants but they aren't paying the salaries to match the skills.
I dealt with it by specializing on the C#-Windows platform. Allows me to hold 5x the language trivia I would able to hold if I worked on 5 different languages and platforms :P.
It's easier in the .NET world because a lot of shops for better or worse go pure Microsoft so there is a standard set of technologies and accompanying trivia you can learn. Unfortunately you won't get to work with best of breed products, but the upside is you'll get to familiarize yourself with enough technologies that you can get up and running fairly quickly.
Language : C#
Database : Sql Server
ORM : Entity Framework
IDE : Visual Studio + Resharper
Client Side UI : WPF
Web Server : IIS
Web : Asp.net MVC/Classic etc...
Client OS : Windows
Server OS : Windows
Development OS : Windows
Cloud : Azure
Logging : NLog or Log4Net
Code Generation : T4
Source Control : TFS
Build Server : TFS
Unit Testing : MSTest
Build language : MSBuild
Deployment : Wix or ClickOnce
Mocking Framework : Moq or Fakes
etc...
(This list is ignoring many of the different technologies that have been discarded by Microsoft such as winforms, COM, VB6, etc..)
Yes I am sure specialisation helps, but as you have rightly pointed out the amount of stuff you need to know even with one language/one platform is enormous.
It's insane. At one point I was fully fluent in C#, Silverlight, all the HTML/CSS/Javascript necessary to successfully embed Silverlight, MVC/MVVM, SQL implementation and design, etc etc etc etc... Being a full stack .NET programmer is just as crazy as being a full stack Javascript.
I was a VB6/winforms expert at one point. Remember ADO? How about RDO? And when I say 'expert' I mean I made VB6 stand up and beg. Full error trapping, NT services, multi-tasking. I've forgotten more than many people know. Never mind all the other languages that have led me up to this point like Pascal and assembly.
If that's true then you shouldn't be hiring people to begin with. After all, if you already know that your problems are too difficult then there is no hope whatsoever that your hire will be able to contribute.
OTOH if you feel that the problems you are dealing with are solvable (and they had better be) then working together with your new prospective hire on some aspect of them will quickly give you insight into how they would go about this and whether or not they have something to contribute.
I have to humbly disagree with you here. Estimation problems are quite important in science. When dealing with computers and algorithms, a quick back-of-the-envelope calculation can illuminate a lot of things. Maybe your algorithm is running slowly but a quick calculation shows it needs to be orders of magnitude faster. Etc.
It's by no means a super necessary skill to have though. And certainly it makes for a rather silly interview question. I would guess it takes no more than half an hour to an hour to train yourself to do estimation problems.
Of course they are important in science. But that's not the kind of problem that you're likely to be hiring this particular (presumably a programmer) for. And if it is then estimation problems are exactly what you should be doing but if they are not then it would be a lot better to pick something related to the work at hand.
Yeah, I dislike "isolated demands for rigor" as much as the next guy, but... no. Just no. There are tons of peer reviewed studies on interviewing. In particular, there are tons of studies on measuring IQ, which is the best known predictor of job performance for a wide variety of jobs. (Yes, better than work sample tests or anything else you might name in five minutes.) See Schmidt & Hunter 1998 for a pretty good meta-analysis. That's the standard I'd like to see when we talk about measuring creativity.
While the question of creativity vs programming skills is interesting, I think it's not even good to assume that people inverting binary trees on a whiteboard are good at coding.
I know several people that are great at algorithms but write garbage code (unmaintainable, unreadable, untestable, etc). Or they can't take business requirements and turn them into low-level details in a useful way.
The number of times a product manager has gone to an engineering team and said that they need a product that inverts binary trees is about equal to the number of working quantum computers.
When I do interviews I always have the candidate show me some of their own projects and walk me through the interesting parts. Sometimes I'm curious about a certain feature and will have them explain the code to me. I feel like this is the a great way to know their skill, personality and how they solve problems. It's actually interesting for me as well. Brain teasers are good for seeing whether the candidate can memorize algorithms. Since our work involves very little, if any algorithm writing, that's not something we look for.
I do something similar during DD, I usually ask the technical people to show me the parts of their code that they are most proud of and the parts that horrify them and/or that are least maintainable.
This gives great insight in their ability to deal with extraordinary needs and the teams potential to hack their way out of a problem and is a good predictor for their long term survival.
Creativity is next to impossible to measure during an interview. So all these proxies for creativity are invented and we use weird memes ('thinking out of the box') to describe some aspects of it without fully nailing it in a way that would make it a measurable quantity.
I think creativity is hard to measure by definition because if you could measure it it would have some other name. It's a bit like 'AI', by the time something gets done it is no longer AI.
Programmers are - by non programmers - in general not considered to be creative people, they are seen along the lines of engineers, whereas architects generally are seen as creative people.
For me good programming is like writing poetry (definitely a creative art), only now all of the poem has to be internally consistent and the computer will mercilessly reject any prose you wrote that isn't.
So it's a very constrained and formalized kind of poetry, an arena where beauty is not only not apparent to non-programmers but largely irrelevant. As if painters produced nothing but white canvases that only they could see with special glasses.
If you want creativity to matter in tech recruiting then stop using proxies for creativity during the recruiting process and throw a new recruit a real life problem and work with them to solve it. That will give you a measure of someone's creativity.
These tests measure how many different ideas you can come up with and how detailed and original they are. These seem quite easy to measure during an interview. It doesn't really have anything to do with the formal or aesthetic qualities of what is being created.
Interviews which have you rebalancing trees and what not are really just legally safe IQ tests. They purport to be testing skills, but nobody really cares if you can implement a search algorithm - 99.9% of the time you're going to make a library call to do that. They do care to hire the kind of people that are smart enough to do that kind of thing, though.
Yeah, something that took years for others to come up with. It's completely pointless on an interview. It's like asking to invent something on the spot.
Define "search algorithm" ... simple breadth- or depth-first set membership queries are easily doable in under 30 minutes.
Edit: I don't want to defend such questions in interviews ... it's just that almost everybody has done something like this at some point. It should be easily doable.
Yes, I've implemented several search algorithms in the past, but that was over 20 years ago, in school. I've used libraries ever since for doing mundane things like this. While I know the general idea around search algorithms, and given some Google time I could tell you which one to use in a certain scenerio and probably even whiteboard one, it's not currently "easily doable" for me to pop one out on the spot. Does that disqualify me?
What about the fact that I wrote an image processing army to churn through 4.5MM images in a weekend? I didn't write the thumbnailing algorithm (yea, GraphicsMagick) but I did write a GraphicsMagick Ruby gem to work with data in-memory instead of writing to disk.
Could I do it again, in an interview, on a whiteboard. Probably not, but I didn't do like that in my real job either.
Part of the problem is that the bigger the company the less creativity they want out of their programmers. Programmers are supposed to do whatever task they were assigned by their managers. Creativity is reserved for the product team.
This comment seems really broad, I've worked in big and small companies and the size of the company had nothing to do with whether or not I was given the ownership and freedom to be creative. On what basis are you judging that this is the case?
I agree with you, I've had good and bad experiences at big and small companies.
One thing - I think that if someone is hiring a programmer, that's already an indication that they are looking more for someone to execute a vision than to be "creative". This isn't always the case, but it leans that way. People have an idea, or a need, and they realize they need a programmer to implement it, so they set out to hire one.
There are some highly coveted R&Dish programming jobs out there at big companies (such as the old Sun Labs) - smaller companies may have trouble supporting something like this. But if you want to really be creative, you may have to strike out on your own, launch side projects, and so forth. It's tough, because it's hard to get this and a stable salary at the same time.
I am sorry, but I can't agree with this statement. It is too broad. I have worked in small and large companies. I have had small companies that just wanted someone to do exactly as they're told and worked for massive multi-national corporations where the level of development and creativity was a incredible. Its not the size of the company - its the "culture" that is the determining factor.
I challenge ANYBODY to actually define in any sort of concrete terms what a great programmer is.
And without a clear definition, how can any interview process ever work out if someone is a great programmer? It is absolutely not possible and in fact meaningless to try.
Everyone - every company, every interviewer, every recruiter has a different opinion.
Recruiting is, in the end, nothing more than a matter of opinion. Everyone keeps trying to "solve" recruiting. It's not a solvable problem. All recruiting comes down to "Hey what do you think of how this guy interviewed? Yes or No?"
> I challenge ANYBODY to actually define in any sort of concrete terms what a great programmer is.
Definition:
A great programmer is one who can define/identify the problem which needs to be solved as put forth by people who have a vested interest (stakeholders), contributes to or delivers a software solution to said problem definition, within time constraints allowed for by their stakeholders, and does so to the acceptance of the same stakeholders.
In software engineering terms, specify the requirements that make a great programmer and if there is science to it then you should also be able to define concrete test cases that tell you if someone meets each requirement.
A definition needs to be qualitative, but it doesn't need to be quantitative. How do you measure "melancholy" or "a thumpin' beat"?
> if there is science to it then you should also be able to define concrete test cases
This is a misapplication of "science". Science is robust observation, not the algorithm behind something. And there certainly doesn't have to be concrete test cases for something to be "science" - a classic example is case studies and low n studies in medicine. Another is everything we've learned from brain injuries. Science isn't limited to just finding against the null hypothesis.
> ... actually define in any sort of concrete terms what a great programmer is.
And I did. The concrete terms are in measurable aspects of a person who is (or is expected to be) performing the role of programmer. These characteristics are congruent with both tangible metrics (such as time) as well as empirically observable metrics (such as solving the problem at hand and doing so to the satisfaction of other people involved).
Using software engineering terms to identify a person's ability is invalid. Attempting to do so restricts the ability to define, measure, and verify with minimal subjectivity whether or not a person meets the expectations of whatever subjective classification ("great", "bad", "OK", "senior", "rookie") being considered.
You presented a challenge for providing a definition for the subjective categorization of a "great programmer." It was my assumption that you did not have a satisfactory one, based on how you presented this challenge.
Perhaps the problem domain which you presented is not immediately recognizable. In defining a concept relating to people, a plausible one will include terms/metrics/observations relevant to people. This implies a continuous domain (as opposed to a discrete one) much like what exists in analog systems.
Attempting to apply binary "yes/no" requirements and/or tests when faced with a partially observable universe doesn't work. Which is why AI agents use heuristics such as "confidence factors." And a person with which an organization has little to no history with presents a partially observable universe often limited to their CV. Now, a computer program has to do approximations such as confidence factors because _it_ is a digital entity (assuming a Von Neumann machine[1]).
But we, as human beings, are not Von Neumann machines. We are analog. Which implies continuous domain metrics (IOW: a "spectrum"). Hence the fruitless effort of attempting to apply software engineering best practices onto people.
However, addressing the problem defined as being "evaluate whether or not this multi-dimensional analog system can be of value to a collaborating set of multi-dimensional analog systems, for some equally nebulous definition of value" may reveal that collecting measurements within the observable outputs of said analog systems has a higher probability of success than one which attempts to apply measurements/practices for an entirely different problem domain.
I think in mobile development creativity matters. An app is a program but also (and very important) is the UX. Mobile portfolios with good interface are an advantage.
I got asked once "what are the four uses of static in C++". I couldn't recall one (can't remember which one), though I'd shipped a lot of code with all four in more than a decade of C++. He wasn't impressed with my so-called-C++ skills.
I wish I'd asked him what three common words in the english language begin with D and then W, or any three words with just the five vowels in the correct order. I think the chances are good that I could have mocked his so-called-English skills.
These questions, and comp-sci trivia tests, don't test developer ability. I've employed a whole bunch of programmers. The best have been the most agile, creative and curious.
I was thinking that it was a trick question and there was a corollary to <code>extern "C" { ... }</code>. I out thunk myself on that one.
Which leaves translation unit variables, class variables (which I had erroneously included in translation unit variables initially), class methods, and translation unit functions.
If I remember rightly (many many years ago) that's what he was looking for, and to me I struggled because I thought of the two orthogonal effects it conflates: that of lifetime and visibility. From that I had to re-engineer his four, but put (iirc) translation unit variables and functions together. Anyway, the question was 'tell me what I'm thinking', not 'do you understand C++'. But I think between the two of you you might pass :) I remember he was insufferably smug about how good a question it was for sorting out real C++ programmers from wannabes like me :D I knew then I couldn't work with him.
I would ask the candidate how they would solve a particular problem we saw in production. It could be simplified, but i'd like to leave it realistic and un-simplified, and give the candidate clarification when they ask for it (demonstrating that they can think of things to ask without needing to be told). I find experienced candidates tend to do better in these situations, where as candidates that are mostly talk won't be able to.
I think those are the best type of questions. I read about an interview process here some weeks ago about when the interviewer asked a question like that which could be made both easier and harder depending on the person interviewing. It had to do with parallell threads and things like that for a network application
So, how do we find employers that want to hire the most agile, creative, and curious engineers? I've long given up on trying to locate those companies, they are unicorns to me after more than 10 years in this industry.
When I switch jobs (for the record, that is > 10 years in and on my 3rd employer), I, too, need to reach for my trusty, old algorithms and data structures books and brush up for whiteboard-style examinations and a few rounds of framework/language trivia.
They are unicorns. Mostly it seems to be a people game. I'm fortunate that I've never needed to work so badly that I couldn't be picky about who I work with, so I treat it as a two way interview. All else fails, I can find something to do myself.
But condolences on being in the 'real world' described by the OP. Must be both infuriating and demoralising.
The problem with "the most agile, creative, and curious engineers", is it is like "above average intelligence" or "good sense of humour". Almost everyone thinks they are agile, creative and curious, because - hey - who doesn't want to be those things? So trying to interview for that is like inviting people to show you their bullshit circuits.
People who are genuinely agile, creative and curious are as much unicorns as the people who want to hire them. People who think they are among the most agile, creative and curious engineers are more numerous than sparrows.
While the original question may not have been asked with the following intention, when I ask a question like that in an interview, I'm not looking for a textbook thorough answer or to comb the minutia. I want a demonstration that you can communicate ideas that you know (even how you communicate in the moment that you've worked with them but cannot recall the fine details on the spot). If you don't know, then I'm looking to see how you communicate that. Saying 'I don't know' is not easy for some people, especially in an interview, but bullshit is pretty obvious. I'm not looking to hire bullshitters. Within all of that, there's plenty of room for agile, creative, and curious responses.
Questions like that are like testing if somebody can touch type by asking questions like "which sequence of finger presses would you use to type qWaMvz%e3("? It's not how we normally access the information. I could type that in a second, but it would be a struggle to tell you how to type that. I'd have to put my hands under the desk and simulate typing it to tell you.
I'm not against talking about such things in an interview; a suprising number of people that claim expertise in a language have apparently never used it, but the interviewer has to understand what their question is actually measuring. With question like that you are often measuring if their brain can recall information in unconventional ways, or if they read an interview book in the last few days. The old standby that was popular awhile ag: "define OO" - if you haven't memorized the book definition it can be hard to rattle off. Doesn't mean you couldn't have a multi hour discussion about OO, functional, and procedural programming, and more importantly make reasonable and sophisticated design decisions based on your understanding of these things.
And yet I've had people literally laugh on interviews when asked to merely describe binary search (if 10 yr olds can figure it out, it seems fair to ask a pro). Even if they have a masters in CS.
As someone who graduated from a good CS program 19 years ago, and has been in a wide variety of positions over the years, I haven't had to do anything on your list but two or three times. While there are types of work that are algorithm heavy, most are not. Many people with 10 years of experience or more may be great software engineers but don't remember the details from their first year in CS.
This is something I always liked about the IMVU hiring process. I wish I understood all the ingredients of the recipe, but somehow we managed to hire a diverse engineering team. Creative folks who just got stuff done, people who could find bugs deep in third-party dependencies, people who could design and build high-performance technology at scale.
I no longer work at IMVU, but the lessons I'd take away are:
- Hire based on passion and innate problem solving ability, not which specific technologies they know. (Except when you need to bring in specific expertise.)
- Have a fuzzy hiring process where people don't necessarily need to quantify a candidate.
- Take risks on people. We've had candidates who were a "no" but one person stuck their neck out and said "You know, I saw something special that none of you did, and I'd like to take a chance." Many times the candidates ended up being amazing, and it took that one person to see it.
> Take risks on people. We've had candidates who were a "no" but one person stuck their neck out and said "You know, I saw something special that none of you did, and I'd like to take a chance." Many times the candidates ended up being amazing, and it took that one person to see it.
But don't forget the inverse. We had a candidate come on board recently who passed the interview with flying colors... Except for 1 person who essentially said the same thing. "You know, I saw something horrible that none of you did, and I don't think we should take the chance." And here we are, with a bad hire in a company where letting people go in general is a non-starter (which is another problem onto itself).
People say this all the time, but I've never seen any explanation for it besides the quite shallow "bad people make bad code which someone has to fix" .. well yeah, and good people make good code which offsets bad code, so .. why should the cost of a bad hire (who you can fire in the first few month without any problems thanks to probation periods) be higher than the cost of missing a good hire who can - potentially - work for many years for your company and produce good solutions for a long time?
Spot on. Bad hires fall into basically 3 categories:
1) A bit worse than average, maybe 10-20% worse than their coworkers. They still add plenty of value and with good management and time can be improved. Just not quite the "gem" hire.
2) Clearly unqualified/unsuitable for the role. Easy to spot and you can let them go with a couple of months serverence. Everyone is happy. Total cost maybe 3-4 months wages.
3) Qualified but toxic. Has negative value and can destroy a team. Problem is these people can get through tough interviews anyway. Having higher testing standards does nothing to stop these people.
On the other hand a good software engineer, working within a company and framework that supports them can easily add $1,000,000/year to the bottom line.
I think the worse that can happen is the 3rd options, although I agree that we have no information about "How much bad is hiring a bad engineer"
When I'm asked about how I'd hire I always look for adaptability, creativity, communication, taste.
Unless our goal is to find something really skilled on alghorithims or a specific language, it's just ok if they are curious, passionate, and communicate.
That said, I still wonder why we put that much emphasis on the language or the algorithmic skills when what we really care about is culture, passion, and helpful communication.
Maybe it's just me but I feel like searching for a more human skillset seems worthwile in the long term
Given the choice of getting either both an equivalent of John Carmack and a completely overconfident, unskilled CS dropout on my team or getting neither, I know which I'd prefer. A great hire is worth far more than the cost of accepting a bad hire.
Even in the case the bad hire were completely untrainable and never managed to get anything past a code review, paying two salaries for the output of one Carmack-like outlier is still a bargain.
> a bad hire in a company where letting people go in general is a non-starter
This is your chance to institute good on-the-job training facilities.
"Bad hire" is a "hire" who requires more training than others (in whatever area they may lack, including human interaction). If you can manage to provide that person with effective training that salvages their status, then you had effectively created a training program that everyone else in the company can now take advantage of.
If you can't, well, it will turn out that the company lacks a vision vis-a-vis training. That is what makes a "bad hire" an "omg unsalvageable bad hire, run for the hills!" (i.e. it's a mark against the company, ot against the hire.)
I used to think this - then I worked with a coworker who just couldn't get it. He'd ask the same question 5-10 times. When the candidate just doesn't care, no amount of training can make up for it.
Sometimes the best training is to fire them, and hope they realize the consequences of not caring.
I think this herd mentality in recruiting is great. The more companies chase the same 0.1% of developers the easier (and cheaper) it becomes for semi-thoughful companies to recruit those developers who don’t fit in the box, but who can get stuff done.
Rank and file developers should not be creative. We must follow the rules and do what we're asked to do. Creativity is distractive and destructive. Filtering out too creative candidates is one of the main purposes of an interview in most companies. You can hate this fact, but you won't change it.
I don't think I believe you. It might be a side effect, but if so I don't believe it's intended. Why would anyone want to filter out people like the person who wrote that blog post?
If that's true, then the people creating the orders for these programmers should simply write code and automate the whole process. We can't do that in other jobs, like coffee servers, because vision and speech recognition, along with robotics, are too weak.
But for writing code, we've got all the tools. If "rank and file" just need to follow rules and do as asked, the asker is far better off asking a computer.
I disagree, programming is inherently creative, you start with an empty editor window and if you have done your job it is full of code by the end of the day.
Mechanical transformation from requirements into a code is not "creative" and should never be "creative". Programmer is merely a compiler from English to whatever programming language he's using.
Totally relate to this. As soon as you're put into a programming role, all of a sudden it doesn't matter if you have domain knowledge, lateral thinking that can lead to improved processes, personable skills etc All that matters during the interview process is whether you can remember some obscure construct in a language, or what the Big O notation of Quicksort is - something that you'll very rarely even have to think about while making web pages...
I guess the problem stems from people hiring others who are like themselves ignoring the fact that diversity isn't whether you are black or white, male or female, but actually stems from the experiences you've had, and the ways in which you think.
Anytime I'm interviewing, these days for contracts as an independent consultant, I try to mention early on that my B.A. was in Philosophy, with a minor in Music History.
I try to avoid (or spend as little time as possible) with companies who are only looking for pure-bred CS majors. It's refreshing when you encounter a medium to large corporation who tell you that most of their best engineers / programmers were originally art students.
"I'd spend a month or two immersing myself in the technical, in the algorithms, in the memorization, and in the process push aside my creative and experimental tendencies."
Memorization is certainly not the way to learn how to solve math/cs/logic problems. There's a lot of thinking and (creative) experimentation involved when trying to solve a problem.
A lot of problems are classic problems in disguise. You'd be amazed to find out how many problems are just sorting + one traversal: reducing the average wait time in a queue, convex hull, counting duplicate elements (no extra space), interval scheduling, maximum number of overlapping intervals and a ton more. Can you memorize all of these problems individually? No, but you can ask yourself "how about if I sort my data first, what then?". If that doesn't work then try another question: "I have this brute force algorithm, if I use some other data structure will it get better?" - that question alone solves half of the problems I've ever seen. Follow up questions would be "does my problem look fractal-y?, maybe I can divide it repeatedly" or "can I incrementally build the solution?"
Even more interesting is that problems usually have more than one optimal solution: Prim's algorithms and Kruskal's solve the same problem in opposite-ish ways and use different data structs. How about substring searching: Boyer- Moore searches backwards, Rabin Karp computes hashes while others simulate automata. With self-adjusting binary trees it's the same story: a lot of very diverse solutions to the same problem.
Solving problems implies doing a lot of permutations and experimenting with data structures and classic approaches if you ask me - it's certainly not about memorising more than "sorting sorts and hash tables have constant-ish access time"
Is this process any different than changing colors, fonts and layout on a website until you get a good-looking enough whole? All you have to know are some principles about contrast, alignment, spacing and what not, and the rest is experimentation.
This is still methodical thinking, and is not really lateral or creative in the sense that we understand it. Yes, a real mathematician thinks a lot, we can even say they are creative, but one using standard math to solve standard problems just has to practice solving problems in that class to become proficient.
A designer does not just change colors, fonts, and layouts until a website looks good, but that is a completely different kettle of fish (creativity and design are not equivalent, but programmers barely understand what designers really do).
"A lot of problems are classic problems in disguise. You'd be amazed to find out how many problems are just sorting + one traversal: reducing the average wait time in a queue, convex hull, counting duplicate elements (no extra space), interval scheduling, maximum number of overlapping intervals and a ton more. Can you memorize all of these problems individually? No, but you can ask yourself "how about if I sort my data first, what then?"
Amusingly, that's much of what an SQL query optimizer does. It has tables, indices, sorts, searches, and temporary files available, and automatically constructs an algorithm to do the query.
We need more technology like that, where you ask, and it figures out how.
The author's point was that memorization is how you pass these silly interviews.
There's a wonderful paragraph in Skienna's algorithm book, where he states that if you can reduce your problem to a graph problem you should do so, and that you should never invent your own graph algorithm - the standard ones will solve whatever problem you have. Perhaps a bit overstated, but by and large true. There is definitely value in having all of that information at hand so you can fairly quickly perform the mental gymnastics to find a good solution.
I think most people complaining about interviews would agree with that. The thing is that so many people don't work in areas where they need at at the front of their brains, but they do work in areas where similar levels of ability are needed. Product design, finding difficult bugs, working with customers, leading teams, and so on. Bad interviews test memorization.
I'm doing almost all linear algebra these days. I can talk to you about matrix computations, round off errors of various implementations, and so on. You probably can't. But only because you are not doing it, and I am. I TA'ed a graduate level Algorithms class. At the time I could do whatever graph algorithm you wanted, now I can't because it is not what I work on now and most of the details have fled my brain. Doesn't mean I can't do it, just like you not being able to implement a Cholesky decomposition on a whiteboard means that you couldn't do linear algebra programming if it became your job.
Because developing new stuff - although advertisement and PRopangda will tell you the exact oppposite- are bloody dangerous. If you are the first to do a thing, you are the first to craft the tools for it, the first to experiment, the first to find errors in the equations, the first to be delayed and then to be overtaken by a spying competitor learning from your mistakes.
The first to be put out of buisness by somebody who realizes your advances put them into danger- with all the force of a currently working buisness.
Prototypes might make good tv-clips. What they do not show, is how often those endavours end pathetic - Rocket explodes, Cars crash, Robots fall and the guys working on them get laughed at by there collagues who stuck to more incremental research. Getting a steampowered nuclear reactor going- fast- getting a fusion plant going - not so much.
The word creativity has many different meanings, depending on who is speaking.
For "packers" it is an umbrella term they use when they are unable to grasp how, say, Rich Hickey came out with Clojure all alone (a few fundamental ideas put together plus ripping out CL) or how Igor Sysoev wrote nginx (after studying Apache's internals and coming up with a better model) or what is so special about Arc language.
For other people it is just the set of habits of thinking which is natural to them, so they literally cannot see what is that people are talking about.
There are the majority, who think that creativity is something which is related to [visual] arts, some kind of mindset. They use this word to justify an inability of a kid to sit down and do the homework as being a creative nature. No wonder packer managers want none of these.)
There is no "creativity" which can be boosted aside from habitual analytical thinking and hard work. Insights could appear only after extensive training of ones mental maps.
It is the dehumanizing effect of division of labor in action - programmers are not supposed to have ideas about product features, product people are. Programmers are supposed to execute and this is what is tested in these interviews.
119 comments
[ 22.0 ms ] story [ 1078 ms ] threadStartups, when they start to hire at scale, try to standardize a methodology to compare apples to apples -- to avoid really bad (arbitrary) interview experiences in favor of predictable experiences even if those experiences are not excellent.
They look for interviewer formulae they can plug a random company developer, who would probably rather be working on something else, into.
My opinion of why creativity doesn't matter in tech recruiting (even in small start ups) is because the person making the decision to hire someone is going to have to defend why they hired that person to someone else (who likely is a business-minded person who does not have a tech background). If the hiring person can't have concrete documentation of why they hired someone, then it is the hiring persons problem.
We cannot ignore the social / political reality that underlies most of the decision making within a business. Having some sort of pass/fail mechanism is a way of insulating the decision maker from full responsibility of that decision
What made me really famous in my little circle was my ability to do really fast problem mitigation. While all the other hardcore devs were freaking out due to all the stress of having to work and communicate directly with management while dealing with rapidfire requirement changes, I took it all in stride and just got it done. My reputation was this: if I was on the case, it got done on time and with a smile... period.
No one in any interview I've ever had was interested in that skill set. They only wanted to know about old school algorithm skills and how fluent I was with popular frameworks. It's as if upper management actually believes that my project management skills are irrelevant because hey! they've got project managers and staff for those. Why would a dev need it!
Oh, and I don't have a college degree. So, good bye... NEXT CANDIDATE!
Sorry...I ranted.
I'd avoid applying for positions directly but concentrate on leveraging your network of past employers who will always know more people in the position of needing someone to simply deliver the goods. Applying for positions directly will work against you because you are setting yourself up for comparison in a way that does not show off your most valuable skills.
I think you're dramatically over-estimating the competence of the average programmer.
"No one in any interview I've ever had was interested in that skill set. They only wanted to know about old school algorithm skills and how fluent I was with popular frameworks."
What kind of companies have you been interviewing at? My guess is that companies with established products that customers are paying for would be very interested in someone who can quickly address customers' problems.
On the topic of language trivia is there anyone out there that can keep it all in their head? I only spend about 25% of my time writing code and I need to work in 5 languages (C, Java, JavaScript, PHP and ObjC) on 5 different platforms (Linux, Windows, MacOS, iOS and Android). I find it impossible to keep more than a limited amount of all the detail in my brain at any time. How do you geniuses do it?
I mostly handle it by trying to stay in one "mode" for as long as possible. For example, I'll try to get all of my vbscript code done first, then the j(ava)script interop code, which are both server side, then I'll write the needed database code, then move to working in the browser once I have a stable api to work with. I try not to mix them unless I'm doing maintenance that requires slicing through all the layers.
I keep the documentation for all of the systems open so that I can quickly reference the stuff I forget. I just try to keep the major stuff "in cache", and then I remember the broad strokes and look that stuff up when needed. In addition to the official documentation, I have a directory of old code examples that I can lean on when I have to remember how to do some uncommon or rare things.
Even then, I still often use brackets in my vbscript and "end functions" in my javascript/php code. It's just a hazard of working in multiple languages environments that I've learned to live with.
One thing I have found is that having separate monitors and keyboards for the different languages help me. I have a bank of them set up on a long bench and I slide from one to the other as needed. When I use this approach I am able to get back into the swing much faster than switching desktops on the one monitor/keyboard setup. There is something about changing the physical set up that helps me switch mentally.
It's easier in the .NET world because a lot of shops for better or worse go pure Microsoft so there is a standard set of technologies and accompanying trivia you can learn. Unfortunately you won't get to work with best of breed products, but the upside is you'll get to familiarize yourself with enough technologies that you can get up and running fairly quickly.
(This list is ignoring many of the different technologies that have been discarded by Microsoft such as winforms, COM, VB6, etc..)How would you go about testing creativity?
Solve actual problems to which you currently do not have a solution and observe the process, not the solution.
http://www.deathandtaxesmag.com/200732/google-admits-its-fam...
I mean actual as in 'problem that you actually have and that needs solving'.
OTOH if you feel that the problems you are dealing with are solvable (and they had better be) then working together with your new prospective hire on some aspect of them will quickly give you insight into how they would go about this and whether or not they have something to contribute.
It's by no means a super necessary skill to have though. And certainly it makes for a rather silly interview question. I would guess it takes no more than half an hour to an hour to train yourself to do estimation problems.
What are the exact instructions for "observing the process"?
Does it measure some underlying factor that's independent of the examiner?
How do we disentangle the influence of youth, good looks, and verbal skills?
I suspect the answers won't be flattering to those who think they can measure creativity today.
Essentially you are saying that there is no such thing as a fair interview process (and I'd agree with that).
I know several people that are great at algorithms but write garbage code (unmaintainable, unreadable, untestable, etc). Or they can't take business requirements and turn them into low-level details in a useful way.
The number of times a product manager has gone to an engineering team and said that they need a product that inverts binary trees is about equal to the number of working quantum computers.
This gives great insight in their ability to deal with extraordinary needs and the teams potential to hack their way out of a problem and is a good predictor for their long term survival.
I think creativity is hard to measure by definition because if you could measure it it would have some other name. It's a bit like 'AI', by the time something gets done it is no longer AI.
Programmers are - by non programmers - in general not considered to be creative people, they are seen along the lines of engineers, whereas architects generally are seen as creative people.
For me good programming is like writing poetry (definitely a creative art), only now all of the poem has to be internally consistent and the computer will mercilessly reject any prose you wrote that isn't.
So it's a very constrained and formalized kind of poetry, an arena where beauty is not only not apparent to non-programmers but largely irrelevant. As if painters produced nothing but white canvases that only they could see with special glasses.
If you want creativity to matter in tech recruiting then stop using proxies for creativity during the recruiting process and throw a new recruit a real life problem and work with them to solve it. That will give you a measure of someone's creativity.
Great analogy.
Torrance Tests of Creative Thinking: https://en.wikipedia.org/wiki/Torrance_Tests_of_Creative_Thi...
These tests measure how many different ideas you can come up with and how detailed and original they are. These seem quite easy to measure during an interview. It doesn't really have anything to do with the formal or aesthetic qualities of what is being created.
Edit: I don't want to defend such questions in interviews ... it's just that almost everybody has done something like this at some point. It should be easily doable.
What about the fact that I wrote an image processing army to churn through 4.5MM images in a weekend? I didn't write the thumbnailing algorithm (yea, GraphicsMagick) but I did write a GraphicsMagick Ruby gem to work with data in-memory instead of writing to disk.
Could I do it again, in an interview, on a whiteboard. Probably not, but I didn't do like that in my real job either.
One thing - I think that if someone is hiring a programmer, that's already an indication that they are looking more for someone to execute a vision than to be "creative". This isn't always the case, but it leans that way. People have an idea, or a need, and they realize they need a programmer to implement it, so they set out to hire one.
There are some highly coveted R&Dish programming jobs out there at big companies (such as the old Sun Labs) - smaller companies may have trouble supporting something like this. But if you want to really be creative, you may have to strike out on your own, launch side projects, and so forth. It's tough, because it's hard to get this and a stable salary at the same time.
And without a clear definition, how can any interview process ever work out if someone is a great programmer? It is absolutely not possible and in fact meaningless to try.
Everyone - every company, every interviewer, every recruiter has a different opinion.
Recruiting is, in the end, nothing more than a matter of opinion. Everyone keeps trying to "solve" recruiting. It's not a solvable problem. All recruiting comes down to "Hey what do you think of how this guy interviewed? Yes or No?"
Definition:
A great programmer is one who can define/identify the problem which needs to be solved as put forth by people who have a vested interest (stakeholders), contributes to or delivers a software solution to said problem definition, within time constraints allowed for by their stakeholders, and does so to the acceptance of the same stakeholders.
Q.E.D.
I tried to define it here: 50 characteristics of a great software developer http://www.supercoders.com.au/blog/50characteristicsofagreat...
In software engineering terms, specify the requirements that make a great programmer and if there is science to it then you should also be able to define concrete test cases that tell you if someone meets each requirement.
It can't be done, doesn't work in real life.
> if there is science to it then you should also be able to define concrete test cases
This is a misapplication of "science". Science is robust observation, not the algorithm behind something. And there certainly doesn't have to be concrete test cases for something to be "science" - a classic example is case studies and low n studies in medicine. Another is everything we've learned from brain injuries. Science isn't limited to just finding against the null hypothesis.
> ... actually define in any sort of concrete terms what a great programmer is.
And I did. The concrete terms are in measurable aspects of a person who is (or is expected to be) performing the role of programmer. These characteristics are congruent with both tangible metrics (such as time) as well as empirically observable metrics (such as solving the problem at hand and doing so to the satisfaction of other people involved).
Using software engineering terms to identify a person's ability is invalid. Attempting to do so restricts the ability to define, measure, and verify with minimal subjectivity whether or not a person meets the expectations of whatever subjective classification ("great", "bad", "OK", "senior", "rookie") being considered.
You presented a challenge for providing a definition for the subjective categorization of a "great programmer." It was my assumption that you did not have a satisfactory one, based on how you presented this challenge.
Perhaps the problem domain which you presented is not immediately recognizable. In defining a concept relating to people, a plausible one will include terms/metrics/observations relevant to people. This implies a continuous domain (as opposed to a discrete one) much like what exists in analog systems.
Attempting to apply binary "yes/no" requirements and/or tests when faced with a partially observable universe doesn't work. Which is why AI agents use heuristics such as "confidence factors." And a person with which an organization has little to no history with presents a partially observable universe often limited to their CV. Now, a computer program has to do approximations such as confidence factors because _it_ is a digital entity (assuming a Von Neumann machine[1]).
But we, as human beings, are not Von Neumann machines. We are analog. Which implies continuous domain metrics (IOW: a "spectrum"). Hence the fruitless effort of attempting to apply software engineering best practices onto people.
However, addressing the problem defined as being "evaluate whether or not this multi-dimensional analog system can be of value to a collaborating set of multi-dimensional analog systems, for some equally nebulous definition of value" may reveal that collecting measurements within the observable outputs of said analog systems has a higher probability of success than one which attempts to apply measurements/practices for an entirely different problem domain.
YMMV.
1- https://en.wikipedia.org/wiki/Von_Neumann_architecture
I wish I'd asked him what three common words in the english language begin with D and then W, or any three words with just the five vowels in the correct order. I think the chances are good that I could have mocked his so-called-English skills.
These questions, and comp-sci trivia tests, don't test developer ability. I've employed a whole bunch of programmers. The best have been the most agile, creative and curious.
But the fifth, and most important of all, is race conditions...
1) static variables outlive function scope
2) static methods don't get a 'this'.
3&4) static functions have no linkage??
I like your fifth though :)
I was thinking that it was a trick question and there was a corollary to <code>extern "C" { ... }</code>. I out thunk myself on that one.
Which leaves translation unit variables, class variables (which I had erroneously included in translation unit variables initially), class methods, and translation unit functions.
When I switch jobs (for the record, that is > 10 years in and on my 3rd employer), I, too, need to reach for my trusty, old algorithms and data structures books and brush up for whiteboard-style examinations and a few rounds of framework/language trivia.
But condolences on being in the 'real world' described by the OP. Must be both infuriating and demoralising.
The problem with "the most agile, creative, and curious engineers", is it is like "above average intelligence" or "good sense of humour". Almost everyone thinks they are agile, creative and curious, because - hey - who doesn't want to be those things? So trying to interview for that is like inviting people to show you their bullshit circuits.
People who are genuinely agile, creative and curious are as much unicorns as the people who want to hire them. People who think they are among the most agile, creative and curious engineers are more numerous than sparrows.
I'm not against talking about such things in an interview; a suprising number of people that claim expertise in a language have apparently never used it, but the interviewer has to understand what their question is actually measuring. With question like that you are often measuring if their brain can recall information in unconventional ways, or if they read an interview book in the last few days. The old standby that was popular awhile ag: "define OO" - if you haven't memorized the book definition it can be hard to rattle off. Doesn't mean you couldn't have a multi hour discussion about OO, functional, and procedural programming, and more importantly make reasonable and sophisticated design decisions based on your understanding of these things.
> tricky graph searches
> finding eigenvectors
> building heaps
> balancing trees
> non-recursive quicksorts
All these 'scary' 'hardcore' things are covered in the first year of most good CS programs.
I no longer work at IMVU, but the lessons I'd take away are:
- Hire based on passion and innate problem solving ability, not which specific technologies they know. (Except when you need to bring in specific expertise.)
- Have a fuzzy hiring process where people don't necessarily need to quantify a candidate.
- Take risks on people. We've had candidates who were a "no" but one person stuck their neck out and said "You know, I saw something special that none of you did, and I'd like to take a chance." Many times the candidates ended up being amazing, and it took that one person to see it.
Taking risks on people is something that carries visible downside for the one advocating the risky step and that's why it happens very rarely.
But don't forget the inverse. We had a candidate come on board recently who passed the interview with flying colors... Except for 1 person who essentially said the same thing. "You know, I saw something horrible that none of you did, and I don't think we should take the chance." And here we are, with a bad hire in a company where letting people go in general is a non-starter (which is another problem onto itself).
1) A bit worse than average, maybe 10-20% worse than their coworkers. They still add plenty of value and with good management and time can be improved. Just not quite the "gem" hire.
2) Clearly unqualified/unsuitable for the role. Easy to spot and you can let them go with a couple of months serverence. Everyone is happy. Total cost maybe 3-4 months wages.
3) Qualified but toxic. Has negative value and can destroy a team. Problem is these people can get through tough interviews anyway. Having higher testing standards does nothing to stop these people.
On the other hand a good software engineer, working within a company and framework that supports them can easily add $1,000,000/year to the bottom line.
When I'm asked about how I'd hire I always look for adaptability, creativity, communication, taste. Unless our goal is to find something really skilled on alghorithims or a specific language, it's just ok if they are curious, passionate, and communicate.
That said, I still wonder why we put that much emphasis on the language or the algorithmic skills when what we really care about is culture, passion, and helpful communication.
Maybe it's just me but I feel like searching for a more human skillset seems worthwile in the long term
Even in the case the bad hire were completely untrainable and never managed to get anything past a code review, paying two salaries for the output of one Carmack-like outlier is still a bargain.
This is your chance to institute good on-the-job training facilities.
"Bad hire" is a "hire" who requires more training than others (in whatever area they may lack, including human interaction). If you can manage to provide that person with effective training that salvages their status, then you had effectively created a training program that everyone else in the company can now take advantage of.
If you can't, well, it will turn out that the company lacks a vision vis-a-vis training. That is what makes a "bad hire" an "omg unsalvageable bad hire, run for the hills!" (i.e. it's a mark against the company, ot against the hire.)
Sometimes the best training is to fire them, and hope they realize the consequences of not caring.
But for writing code, we've got all the tools. If "rank and file" just need to follow rules and do as asked, the asker is far better off asking a computer.
But they don't. Why?
I guess the problem stems from people hiring others who are like themselves ignoring the fact that diversity isn't whether you are black or white, male or female, but actually stems from the experiences you've had, and the ways in which you think.
I try to avoid (or spend as little time as possible) with companies who are only looking for pure-bred CS majors. It's refreshing when you encounter a medium to large corporation who tell you that most of their best engineers / programmers were originally art students.
Memorization is certainly not the way to learn how to solve math/cs/logic problems. There's a lot of thinking and (creative) experimentation involved when trying to solve a problem.
A lot of problems are classic problems in disguise. You'd be amazed to find out how many problems are just sorting + one traversal: reducing the average wait time in a queue, convex hull, counting duplicate elements (no extra space), interval scheduling, maximum number of overlapping intervals and a ton more. Can you memorize all of these problems individually? No, but you can ask yourself "how about if I sort my data first, what then?". If that doesn't work then try another question: "I have this brute force algorithm, if I use some other data structure will it get better?" - that question alone solves half of the problems I've ever seen. Follow up questions would be "does my problem look fractal-y?, maybe I can divide it repeatedly" or "can I incrementally build the solution?"
Even more interesting is that problems usually have more than one optimal solution: Prim's algorithms and Kruskal's solve the same problem in opposite-ish ways and use different data structs. How about substring searching: Boyer- Moore searches backwards, Rabin Karp computes hashes while others simulate automata. With self-adjusting binary trees it's the same story: a lot of very diverse solutions to the same problem.
Solving problems implies doing a lot of permutations and experimenting with data structures and classic approaches if you ask me - it's certainly not about memorising more than "sorting sorts and hash tables have constant-ish access time"
Is this process any different than changing colors, fonts and layout on a website until you get a good-looking enough whole? All you have to know are some principles about contrast, alignment, spacing and what not, and the rest is experimentation.
A designer does not just change colors, fonts, and layouts until a website looks good, but that is a completely different kettle of fish (creativity and design are not equivalent, but programmers barely understand what designers really do).
Amusingly, that's much of what an SQL query optimizer does. It has tables, indices, sorts, searches, and temporary files available, and automatically constructs an algorithm to do the query.
We need more technology like that, where you ask, and it figures out how.
There's a wonderful paragraph in Skienna's algorithm book, where he states that if you can reduce your problem to a graph problem you should do so, and that you should never invent your own graph algorithm - the standard ones will solve whatever problem you have. Perhaps a bit overstated, but by and large true. There is definitely value in having all of that information at hand so you can fairly quickly perform the mental gymnastics to find a good solution.
I think most people complaining about interviews would agree with that. The thing is that so many people don't work in areas where they need at at the front of their brains, but they do work in areas where similar levels of ability are needed. Product design, finding difficult bugs, working with customers, leading teams, and so on. Bad interviews test memorization.
I'm doing almost all linear algebra these days. I can talk to you about matrix computations, round off errors of various implementations, and so on. You probably can't. But only because you are not doing it, and I am. I TA'ed a graduate level Algorithms class. At the time I could do whatever graph algorithm you wanted, now I can't because it is not what I work on now and most of the details have fled my brain. Doesn't mean I can't do it, just like you not being able to implement a Cholesky decomposition on a whiteboard means that you couldn't do linear algebra programming if it became your job.
The first to be put out of buisness by somebody who realizes your advances put them into danger- with all the force of a currently working buisness.
Prototypes might make good tv-clips. What they do not show, is how often those endavours end pathetic - Rocket explodes, Cars crash, Robots fall and the guys working on them get laughed at by there collagues who stuck to more incremental research. Getting a steampowered nuclear reactor going- fast- getting a fusion plant going - not so much.
I suspect that mech engineers don't have to memorize steam tables for interviews.
For "packers" it is an umbrella term they use when they are unable to grasp how, say, Rich Hickey came out with Clojure all alone (a few fundamental ideas put together plus ripping out CL) or how Igor Sysoev wrote nginx (after studying Apache's internals and coming up with a better model) or what is so special about Arc language.
For other people it is just the set of habits of thinking which is natural to them, so they literally cannot see what is that people are talking about.
There are the majority, who think that creativity is something which is related to [visual] arts, some kind of mindset. They use this word to justify an inability of a kid to sit down and do the homework as being a creative nature. No wonder packer managers want none of these.)
There is no "creativity" which can be boosted aside from habitual analytical thinking and hard work. Insights could appear only after extensive training of ones mental maps.
This is called engineering
While "creativity" is, most often, an "over-engineering"