The rise of never-ending job interviews
bbc.com
bbc.com
My experience ended when an interviewer in round 3 or 4 asked me an obviously scripted question. I answered sarcastically, he got peeved, and I never heard from them again.
I'm not claiming I'm Google caliber, whatever that means. Obviously I'm not because I don't have the patience for their interview questions.
To be clear, the entire question was: What's not in a Linux inode?
My answer was: Lots of things...dinosaurs, the moon...
The interviewer told me very matter of factly that it was in fact, the filename.
I honestly lost all respect for the process, sorry Googlers.
They do it because they know they can get away with it, but I do wonder if they have a backup plan if the lustre of working for Google ever fades, because it's an open secret that their interview process is a fucking nightmare for no reason.
Darn the wheel of the world! Why must it continually turn over?
He was hired by FAANG less than a month later.
Absolutely! To add, the amount of nit-picking that happens is staggering. I was downgraded from strong-hire to lean-hire because:
1. I did not use classes in Python. That problem could easily be solved using simple functions. The feedback I got was "candidate does not know idiomatic use of modules & classes"
2. I did not use one of python's standard lib functions and instead I coded it myself (I could not remember it at that instant)
3. I could not spot a scenario in the first 5-7 min of interview. I eventually spotted it and coded it well within the time limit.
Somehow I felt that I am supposed to feel grateful for lean-hire
Apparently they missed this classic HN discussion:
Many googlers probably haven't read this blog-post from some time ago [1]: "Python Is Not Java". I mentioned that at my first interview for a Python programmer job ~15 years ago, i got hired (truth be told the interview was for a small-ish startup, not for a behemoth like Google).
Sometimes this works well, sometimes it really backfires on them. Coding is one of key rubrics on which we assess software engineering candidates, and if the only signal I have is that they don't know know their chosen language very well, it's hard to justify scoring that rubric highly.
And this was misinterpreted by the interviewer as not knowing the language.
An effective interviewer would have asked "Why are you doing it this way?" instead of assuming - wrongly - it was all the candidate knew.
This actually matters. Before you even get to coding skill you want people who can parse reality accurately, and not make incorrect assumptions about what's happening in front of them - either out of narcissism and arrogance, or because of poor communication skills, or because they're following a set process which is bureaucratic and inflexible and operates with a poor signal to noise ratio. (Among other possible reasons.)
But I get what you are saying though.
This is endemic and part of a much wider malignancy in the tech interviews. Cram two medium-to-high difficulty questions in the span of 45 minutes and require the candidates to solve them both on the spot. In other words, you have at most 20 minutes to work out a complete solution to any given problem.
In practice that means that you need to come up with the correct base solution in the first 2-3 minutes, because there is no time to actually work through the problem.
I call these types of interviews Epiphany Lottery.
Or which ones are young and single with no responsibilities outside of work. Which is likely a feature, not a bug.
Not only correct solution but also generate alternatives to showcase what other things you know to get strong-hire.
Example:
This problem was asked in Google: https://leetcode.com/problems/cat-and-mouse/
It is actually based on a paper [1]. Plus it seems it is expected that one needs to know about 'alpha-beta' pruning algos for such problems.
If you solve this using dfs ... its basically gtfo
[1] https://www.semanticscholar.org/paper/Undirected-Cat-and-Mou...
This one, for instance is expected to be completed in 30 minutes. I spent 2 hours on it yesterday and failed most test cases. I'm a failure.
Its true on some degree, that you need some intelligence, but I have a few close friends who are FAANG, they are definitely not the best developers I've ever worked with, only difference is they really really cared about getting into FAANG. Getting into FAANG was basically their life ambitions, so they dedicated literally all there spare time to it.
I feel the smartass part of my brain eternally dooms me...
I had no interest in ever "explaining" stuff to non-technical people at that time, all I cared about was the code. So I also trolled one of the guys interviewing me since I happened to be stuck with his legacy "code", which made me judge him and take him with absolutely no seriousness: he was one of those "cfa" people who learnt how to "code" a line of VBA and think they're Linus.
I also remember the face of the HR person who was like wtf the whole time and politely told me they had "chosen" another person for the job, I laughed inside and politely answered that I understood.
I recommend against this behaviour to past me anyways ;)
We all have to feel our oats at some point … and then realize later how childish it was / how poorly we treated others … so we can be forgiving of those who come after us …
Your goal when interviewing people should be to find things out about them — with gotcha questions you don't find out anything about them, but they find out something negative about you.
https://longnow.org/essays/richard-feynman-connection-machin...
I'm guessing Feynman would've had a much better chance getting hired at old Microsoft, than through the current FAANG/wannabe interview process.
Mold for sand casting is easily done in lathe (turning a wood on lathe for precise shape is faster and more accurate than sawing).
So as one of the parent comment mentions - it is round because of production reasons.
So, most probably the shape of the cast iron cover (circular), drove the shape of mouth of the hole.
[Edit in response to a question]
Some people have attempted to steal manhole covers in order to sell them for scrap metal. China Daily notes that there has also been a problem with taxi drivers removing manhole covers to "steal water and clean their vehicles". https://www.bbc.com/news/blogs-news-from-elsewhere-52400235
On the other hand, copper is $3/lb, brass $2/lb, aluminum is $0.50/lb
The manhole cover question, is more of a check to test whether the candidate belongs to the math-circle people where this is well known.
Even if they don't it's then an opportunity to test if the candidate can see the question behind the question.
With these sort of open-question in an interview context you have to roll with it, otherwise it's seen as an unwillingness to play (sphericon) ball.
http://lh4.ggpht.com/_LWPSf1_ugFI/TA4tx-22QRI/AAAAAAAAFx0/T1...
There are triangular[1] and even more exotic-shaped[2] covers.
[1] https://www.reddit.com/r/mildlyinteresting/comments/g826ve/m...
Holy crap, I never thought a website dedicated to manholes pictures was a thing. I love the human species :)
asked that question I would have answered: "that's a trick question! they are not round!"
http://www.theromanpost.com/wp-content/uploads/2019/11/cropp...
Are there any other reasons the cover would be round? It gives you an insight into their thought process as they come up with more ideas and explanations.
A more human anecdote for example I have movies I know I have seen dozens of times. Yet my recall of what happened in them is not as good as it used to be as the last time I watched them was a few years ago.
Every year, Google receives over one million resumes and applications. Only 4,000-6000 applicants will actually be hired — that's less than a 1% hiring rate.
Given those odds it's not worth it.
$$$
For what it's worth I probably wouldn't want to move to SF and take a FAANG job either, but I can see why many people would
you are aware of the saying that the lottery is a tax on stupidity?
I guess that is perhaps a little harsh, but only a little.
First off, I don't think I would want to work at any place where getting in there is represented as winning a lottery ticket. Think of the poor oompa-loompas enslaved in Willy Wonka's factory.
Second off, perhaps it's just my vantage as a consultant in Denmark but everything I've read about working in Google has made me think it doesn't seem very enticing.
Third off, even when I was not married with kids I would not have wanted to spend so much time twice a year! How many unpaid hours a year are people willing to work for a lottery ticket that essentially pays out a top-paying job?
Almost everything in life is "lottery ticket" with some odds.
So those numbers are accurate and not misleading.
I've read about Linux inodes. I know what they do. In fact I even have had Linux systems where I get inode related error messages because the partition had too many small files on it.
But given that question, in that situation, I would likely not know what they even meant with that question. Am i supposed to have all the inode details memoried forever in my mind? It's fucking ridiculous.
The problem here is that what could be an invitation to showcase knowledge is reduced to a vague, one-dimensional and non-obvious trivia question. There are a ton of valid answers to this question, like:
* The file data
* Extended attributes (ACLs, etc)
The topic is fine, but the framing of the question is terrible.
If I wanted to test a candidate's knowledge in this area I would probably ask: "Why isn't the filename stored in the inode?" -- this initiates an architectural discussion, rather than a poorly designed guessing game.
Guessing games in general are a red flag for the employer. They tend to indicate the interviewer isn't competent freely discussing the subjects at hand.
I had a teacher once who constantly asked questions like these in such an imprecise fashion there was no way anybody could have guessed how the question was even meant to be answered. I still cringe when I think about it, because the only purpose of these questions was to show us that he is really clever and we don't know shit — and it didn't work at all.
Personally, I have always approached interviews as an opportunity to either teach or learn. I pick a subject and drill down until either the interviewee reaches their limit of knowledge, or I do. Why is it like that? How does that work?
Then, we have a discussion. One (or both) of us is learning and we work out the whys and hows together. If I'm the one learning, and I hope that I am, I fact check the discussion after the interview. If not, I get a strong indicator not just for the technical level of the candidate but also how they operate at the edge of their comfort zone. I've found this can be a strong predictor of future growth.
Ding ding ding.
Even the question, as asked, was OK. The interaction with the interviewee wasn't.
OP's joke was clearly just asking the interviewer to be more specific. Instead of exploring the question with the interviewee (e.g. "well, can you think of something that one might naively assume to be in the inode, but that is not"), they get pissed? lolwat?
Except on some filesystems really small files can actually be stored directly within the inode, so even that's not always true.
Discussion of these whys and hows and whens is the most valuable part of an interview and will more accurately illustrate depth and breadth than any number of fixed questions.
I’ve also failed job interviews where I was told there was no coding expected in the face to face and then got given a piece of paper and asked to solve 3 theoretical problems in SQL on paper while 3 interviewers watched. 10 years prior I’d worked for several years on Oracle middleware so I knew SQL inside and and out but I still lost my nerve at that interview and was told I wasn’t experienced enough.
There was another telephone interview where I was asked all sorts of command line questions, the problem there is they spelt out the command line flags differently to how I normally talk and read then (eg “what’s see hatech em ohh Dee seven hundred and seventy seven”, had i seen it written down I’d have been like “oh you mean see hatech mod seven seven seven” (chmod 777) but they way they read it out sounded cryptic has hell.
So there’s a valuable lesson I’ve learned for interviewing: putting pressure on interviewees is just as likely to filter out good candidates as it is bad ones. So you’re better off making them comfortable during the process. Good but nervous candidates will perform better. The interviewing process shouldn’t be about who can hold their nerve the longest.
A frustrating way to find out though
I've never heard 'h' pronounced like that.
"Charlie Hotel Mike Oscar Delta Seven Seven Seven".
The reason to cram into people a standard spelling alphabet is that it minimizes confusion over the usual "see as in $random-first-name". The reason to standardize on the NATO one is that it's already an international standard, and a subset of the population that goes to work with anything resembling a radio transceiver will have to learn it anyway.
The point was the interviewer read a written command differently to how I’d typically hear it. It’s a little like the S-Q-L vs Sequal debate and how that can sometimes throw people.
I was asked to do a task that eventually boiled down to a topological sort, and I thought the question consisted of recognizing that the answer was a topological sort and moving on because it was over the phone.
However, that was not the case. The interviewer wanted me to code it all out over Google Docs, but I didn't remember the exact algorithm so I basically had to re-figure it out on the fly, which took most of the interview (I even similarly mention "in any real situation I would just look this up", but that didn't help). At the end, I had a bunch of pseudo-C++-code that should do it correctly.
I thought I was done, then the interviewer said she would go go copy my code and compile it after the interview to see if I was right, which blew my mind. It was never mentioned previously that the code would actually be compiled and run, and with no syntax highlighting or ability to compile and test the code myself there is zero chance it was ever going to work.
I never heard back, so I'm assuming my code failed and they left it at that. Anyway, I'm much happier now that I think I would have been at Google.
HR wished I had gotten a different interviewer.
But I kept being approached by Google recruiters, kept recounting what had happened last time and asked if I could expect better this time. None could promise things had improved, and a few did express that kind of frustration.
This was years ago now. Could have changed of course. But I started telling them to go away.
Now I'm getting an email every month from FB, and about ready to do the same with them.
The last time I passed the first and second rounds and Google let me languish on the third round for a month. I still probably would not have made it through, but it was surprising that my candidacy was dropped like that.
Yet, you could expect one of those in almost any interview process. Seemingly smart people are ready to jump on bandwagons, too.
Microsoft started doing this, realized it was a bad idea, and stopped before Google even really started this practice. So Google is as guilty of bandwagon jumping as everybody else here.
Whatever metrics that google is using in their interviews have probably become worthless in the past decade as people game the system.
And the NDK clearly is anything but modern C or C++.
I’ve heard it referred to as “C+-“.
Apple mostly cares about LLVM based tooling in the context of Objective-C and Swift, Metal is C++14 dialect, and IO/Driver Kit require only a subset similar in goals to Embedded C++, so that leaves the remaing of the clang community to actually provide the efforts for ISO C++20 compliancy.
Which one is best for open source is debatable.
Permissive licenses make it easier for companies to make proprietary software, or even a closed source version of the original project.
Copyleft licenses (like GPL) are intended to promote free/open source software but they can be a legal headache, which can make users favor proprietary solutions.
On HN, I think that people tend to prefer permissive licenses (but complain when large companies "steal" their work, go figure...).
"Data-oriented programming" (to distinguish from object-oriented) is largely C-style C++ that is written for performance rather than reusablility/abstractness/whatever. In the embedded programming world where performance is paramount, a lot of people have low opinions of many C++ features. One could also never completely trust compilers to implement everything correctly.
I come from an embedded background, and understand that.
Aren't they the company that pretty much requires an Ivy-League sheepskin to be a janitor?
My pet theory is that HR minions feel compelled to portray their role in the process as something that adds a lot of value and outputs candidates which meet a high hiring bar, even though in practice they just repeat meaningless rituals which only have a cursory relationship with aptitude and the engineering dept's needs.
This is the first time I've been involved in coming up with the process, but from what I've observed, it's a similar situation in other organizations.
That is simply not how things are. The hiring bar is designed and upheld by people on the same software engineering job ladder as a candidate. The role of recruiters is primarily coordination. The role of HR is compliance with local employment laws.
"The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt. – Rob Pike 1"
"It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical. – Rob Pike 2"
Sources:
https://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Pa...
The candidate hated the interview, claiming it was discouraging. Coding is erratic, talent is strange, it really is a craft and we still don’t know how to reliably raise someone to competency.
1. The candidate was a complete and utter fraud and their previous (and apparently well-regarded) employers were too stupid or negligent to notice this, wasting literally millions of dollars (48-21 * $100,000+).
2. Something about the interview failed to let this person demonstrate the skills that had kept them employed for two decades. Maybe their mind went blank under pressure, or at the end of a long day. Maybe they got hung up on something trivial (that a quick search—-or nudge from the interviewer—-would have resolved), or the question was unclear.
Fizz buzz was a great question in that it had pretty much a Boolean success criteria.
If the interviewer only says "Write String.contains that passes these test cases" goes back to playing with their phone, several things may happen. One person will take that absolutely literally ("It's a test; better do as I'm told"), and you'll dismiss that apparent garbage or move onto the "real" assessment where they're hoping to shine.
Another will get bogged down in something the interviewer regards as a distraction, and "waste" a bunch of time on something the interviewer regards as a distraction. "He handled unicode, but not substring matching (KMP or Booyer-Moore) or vice versa." Maybe someone will goldilocks it and hit the right (not-explicitly-specified) balance of (also unspecified) features and time, but...
If you structure it as "Please, do the dumbest possible thing and we'll iterate"--and don't hold that initial pass against them--I could see it working well.
That would tell you if their workflow would fit your company much more than knowing how to run a coding challenge would.
It is still a very useful test.
Personally I am a much bigger fan of using FizzBuzz as a gate than an algorithm question. I think algorithm questions optimize for the kind of developer who doesn't mind memorizing algorithms to get a job, which might be a useful skill, but you can test that same skill of memorization using FizzBuzz, and then you don't end up also filtering out people who can code but don't care about memorizing algorithms.
In any case, I always think it's worth using their solution as a jumping-off point to ask other, more language-specific questions. Things like: how would you change this if it was intended for use in a FizzBuzz library, how would you annotate this if you needed it to be injected as a Spring dependency, why did you use a for loop instead of a Java 8 stream (or vice versa), what are the implications of declaring this thing as final or static, can you write a unit test for this, and so on. That's when you can get past the point of memorization into figuring out if they actually understand what they typed, which is helpful to ascertain their level.
well, I mean, you get to ask what you like... but this is how you determine if someone understands what they've typed on a conceptual level?
For me there are basically two questions to answer when I am interviewing someone. The first is if they have any real programming ability at all, which hopefully FizzBuzz should answer. (Many people do not pass that threshold.) After that I'm looking to figure out where they could fit into the team, or the company. That means seeing if they are already familiar with the frameworks they will be working with in the position (usually, but not always the case for junior applicants who have held at least one job before), but then also if they can speak critically about some of concepts used in those frameworks, and perhaps compare different approaches that have been taken to solving similar problems over the years (if they are more senior).
It's not a wrong answer if they don't know the framework or the concepts behind it at all, since they might be switching specializations, but that's important to know at the interview stage because they might be better suited for a different role than someone who is deep in the framework and more likely to be able to hit the ground running.
My question is: what happens after people pass fizz buzz? Failing fizz buzz is how you filter people out, but it's unlikely that coding up fizz buzz passes the technical screen. What kind of questions do you use to establish this, once you're past fizz buzz?
I've failed far more tech screenings than I've passed. I could easily do fizz buzz, and when I've prepped for an interview, I could some tree and set permutation stuff. But the questions get so much more difficult than this. Since difficulty varies, an example of a difficult question for me is "find all matching subtrees in a binary tree" (at the whiteboard, in 45 minutes). When I got feedback about the no-hire, the explanation was that I had a good grasp of algorithms and made some progress, I didn't solve enough of the problem in code (tight pseudocode would have been ok) in time allotted (again, this was ~45 min at the whiteboard, one in a series of 5 one-hour technical exam style interviews during a day of interviewing).
I can't claim to be a great coder. I have understood how to code merge sort and quick sort and more complicated tree structures, and I could do them again if I studied and loaded it all back into short term working memory, but I'm content to know how the algorithms work generally and get back into the details when I need... but when anyone mentioned "Fizz buzz", I do insist on stating that my impression, based on quite a few interviews, is that fizz buzz isn't what is screening out software engineers. Lots and lots of people who can write fizz buzz (and build and print a binary tree pre order and post order, and do dfs and bfs, and solve problems with them) are still frequently screened out.
I'm at the point where I just won't do tech interviews anymore (or take home tests). I won't study for exams or do mini capstone projects for an interview that may or may not work out. I would do these things for a degree or licensing exam, but not for a job interviews. It's just too much of a time sink.
I accept that this may cost me good opportunities (in fact, it has), though of course I don't know if the interview would have gone anywhere, other than costing me another long prep session with "cracking the coding interview".
I'll finish the way I usually do, by 1) acknowledging that you are free to interview how you like, and that nobody owes me a job, and 2) mentioning that many companies complain incessantly about hiring difficulties without realizing that their own interview processes may be filtering out talented people and that nobody owes them an employee either.
We tune up a little bit the difficulty. The point is to start a conversation and see what the candidate knows about, ¿does he knows about time complexity?¿differences between passing by reference/value?. Afterwards we talk about the technology that they use, what they like, and what they will like to use in the future. Just to see if they read about their field and are able to talk without saying something egregious.
And if they do fine we bit the bullet and hire them.
> nobody owes them an employee either
Now that I am "in the other side", I can see a lot of things that will definitively would improve the problem at micro/team level, like posting salary or increasing the WFH days. But ¿would they improve at macro/company level? The things is, companies, including tech companies, from small startups to big corps, usually have much more problems than the quality or quantity of their software.
(signed, someone that has been rejected, and will be rejected, to more interviews that he has passed)
There are certainly a few. The job market, being a combination of people who want new jobs and those that can’t keep their old ones, is undoubtedly enriched for them.
Even so, it seems unlikely to me that there are anywhere near as many as most people say. You certainly don’t have to hire someone who flubs your interview, but you also don’t have to assume they are frauds.
I’ll estimate zero to 10% wildly incompetent. Many of the folks who aren’t able to program find other ways to be useful: Testing, requirements, prod support, sys admin, config. It’s not even clear they couldn’t program, but maybe came to prefer the other work at some point.
What’s your wildly incompetent estimate?
> The job market, …, is undoubtedly enriched for them.
30%, minimum. I was hired alongside a guy with a fantastic resume. He pushed zero lines of usable code in 4 months. When he left I purged about 20 files which were tests that were just completely commented out (but I guess those count for LOC according to github's crude measure). I would say that not only was he incompetent, he was worth negative (thankfully, nothing critical) - Maybe in order to cover his tracks? he had moved certain classes of tagged tests (e.g. skip, broken) to "ignore" status instead of 'yellow star'/red dot, I now, months after his departure, have a pr reverting those changes months after because I didn't notice he had done that. Thankfully it had not covered up any major defect in our codebase (someone could have left a corner case test as "broken" with the intent to fix it later and wound up forgetting to and sending it to prod).
But hey. Programming isn't that bad. In the physical sciences it was 60-70%.
How was this not uncovered during code reviews?
I think the reason why every developer tends to have a story about these sorts of incompetent colleagues is not necessarily because 50% of their colleages are incompetent, but because even if just 2% (one person in the department) or 5% (one person in your larger project team) is incompetent, that can be enough to cause a seriously negative impact.
I'm sure I'm on somone's list of incompetent bozos for an interview that went like this: "Please, describe Python programming language." That's it. I had no idea what I was supposed to be doing, and the two fellows interviewing me would not elaborate.
I talked about what I had done with Python. Stony stares. Do I talked about the nature of Python itself (interpreted, multi-paradigm, lexical/LEGB scope, the GIL). Stony stares. I wrote some trivial programs on the board. Stony stares. Had I brought an actual snake, I might have tried to charm it.
At the end, the CEO told me they weren't overwhelmingly sold on me, but would think about it. Never heard from them again.
There are so many "developers" just faking it, I can certainly understand using a test that would reject 90% of the good candidates if it could reject 99% of the bad ones.
This was the introductory question before launching 200 threads and asking him to solve the deadlocks/inefficiencies, which was the real question supposed to let him show off his skills in front of my employees, specifically crafted for him because I wanted to persuade my employees he was an excellent hire. So he had a taylored chance to show off his skills but failed at the introductory question.
But on the other hand, how can you be asked “Here’s a substring, return true or false if it contains the substring, this is the introduction of 5 questions so don’t sweat it” and not just write two nested loops and an if? I’d pass on UTF8 problems, but when you’ve been working with Java for CRUD apps, you still should have your UTF8 correct. This is how you end up with passwords that must be ASCII because the programmer is bad.
People's brains just occasionally lock up.
And if the candidate was able to do this in 6 minutes, what would you have thought? "Great, let's hire"?
In my humble opinion, the question is a waste of time either way. You'll get much further trying to probe what the candidate does know rather than randomly creating an exercise that you think they "should be able to do if woken up in the middle of the night". People forget how stressful interviews are and how easy it is to assume shared context.
The fact that your employee was able to do the test might be indicative of the fact that you share context with the employee that you did not share with the candidate, thus confirming your bias.
This! When giving interviews last I really worried if the questions I asked where just indicative of my own Dunning-Kruger effect.
i.e. Do I only ask questions I already know the answer to and not questions I don't know the answer to?
If I do then am I just filtering for people with the same background and knowledge and missing out on people with other skills I don't know, because they're in my blind spot, I need yet?
I've been advocating for a "coding interview" where both the interviewer _and_ interviewee draw some random question from leetcode or other problem bank, and try to work at it together.
This would show collaboration skills, and you can tell pretty easily how helpful the candidate is with his/her contributions, and whether you find there is an impedance mismatch somewhere.
It probably also maps more closely to the kinds of interactions you'd have after the person's been hired.
I think it would also help calibrate: if you can't figure it out, is it fair to expect the candidate to figure it out? Maybe it's just a hard problem!
Multi-lingual support seems really really hard, especially in six minutes. I would think most people would need to look at technical (i.e., unicode) and linguistic references to get it right.
Should does the ligature f l match itself, or the ASCII constituents 'f' and 'l'? How about combining vs. pre-composed characters? Some Chinese characters show up in other languages (Japanese, Korean) and are sometimes split between Hong Kong/Taiwan/Mainland language tags too. In fact, there's a mess of work devoted to this ("Unihan" https://www.unicode.org/versions/Unicode13.0.0/ch18.pdf). Having figured out what you can do, you then need to decide what you ought to do. Not being a Chinese-speaker, I have no idea which options would seem natural....
In fact, having written this all out, there's no way someone "solved" it from scratch in six minutes. It would be a great discussion question though....
for (int i = 0 to text.length() - substring.length()) {
boolean found = true;
for (int j = 0 to substring.length()) {
if (text.charAt(i) != substring.charAt(j)) {
found = false; break;
}
if (found) return true;
}
> What was the goal of the question?
This is the introductory question before solving concurrency problems, because it’s much easier to understand what a thread does when you’ve coded the body yourself.
> Why did you want the person to implement a contains method?
The job is CRUD + integrating with Confluence + parsing search queries from the user, so finding “<XML” in a page and answering “Yes! This is totally xml, I’m positive!” is a gross simplification of realistic tasks in the real job (and in fact in most webapps), with characters instead of XML or JSON.
I have the feeling that you think this question is entirely abstract, but I both tailored the exercise because he touted being good at improving app performance on his resume (including using JProfiler) and I took care of using a realistic on-the-job example.
> Did you really want to verify they understood String implementation in Java?
Well, what consumer product can you work on if you trip into all UTF-8 traps? Telling customers “Just write English because we can’t be bothered to learn the easy thing in Java that handles UTF-8 properly” is… is acceptable unless he also fails the fuzzbizz test. And once UTF8 is mastered, it’s good for life! I wouldn’t mind teaching him if he didn’t fail the rest, but as a senior you should really know the difference between .getBytes() and .codePointAt(i).
> If the candidate was able to do it in 6 minutes, what would you have thought? “Great, let’s hire”?
The 4 other questions were classic gross concurrency errors, tailored because he touted it in his resume and I wanted him to shine. A senior should be able to guess them blindfolded as soon as I tell them “There are concurrency problems”, without even looking at the code ;) Volatile, atomic, ArrayList non-synchronized, 200 threads for a connection pool of 10, a DB accepting 7 cnx (note the prime numbers make it easy to spot which multiple is causing the issue), and strings of 10MB each with Xmx=100m, if he finds any 3 of the 12 problems, and 2 more with help, I’d hire him. If he ditched the code and postes tasks into an ExecutorService (as they teach in the Java certification level 1), I’d hire immediately.
1) We want to test concurrency but start with implementing String#contains.
2) You have to know how to implement String#contains because you might use contains in our environment (not really, but theoretically, so you better know how to implement it).
3) You must absolutely avoid basic UTF-8 traps because users use UTF-8.
Neither of the above tells me what would you gain if the candidate nailed the question. It just tells me that:
- Your team might or might not use contains to verify something is XML (I truly hope not).
- Your team uses UTF-8 strings (which is one piece of the shared context that the candidate probably does not have).
- You tested candidate abilities of performing under pressure rather than testing their knowledge or skill.
- You are trying to hire the exactly same senior developer as if you promoted someone on your team with your codebase.
You come to the interview full with assumptions and biases about what a senior candidate absolutely must know instead of seeking what they bring to the table and why they call themselves senior. Let me tell you there are lvl 4 and 5 Java candidates that have never touched UTF-8.
Finally, and let me blow your mind here, there are senior developers that haven't really used String#contains in the last X years of their career either.
I don't know what was the quality of the candidate, but I feel, from my limited PoV and lacking all the info, that your interview process is deeply flawed.
I also completely fail to see what a CRUD app (i.e. java + db) + shooting REST requests to confluence has to do with your concurrency questions, as in interview != job fit, but that might have to do with some missing context.
My then-co-workers liked to ask harder algorithmic questions but I wanted to give the candidates a little bit of a break with something easier.
It didn't always work, but at least I tried.
What were you trying to tease out from the problem statement?
I am not a Java programmer but it took me 30 seconds to find the contains() method.
I took a different offer in the end, but the recruiters reach out every few months for a chat.
Makes a lot of sense, you could solve all these questions without knowing specific algorithms as long as you are good at problem solving - which is, I assume, the intent of the process.
Obviously it doesn't always work like that.
While it's probably not what an interviewer is looking for, having the most common solutions memorised gives you an advantage of time. A coding interview usually consists of two challenges. If you get stuck on the first one and take too much time to answer it, you won't have enough time to go through the second one.
To avoid the code printer perception you can always go through an explanation what alternative solutions could be applied to the given problem, what their complexities would be and why the one presented is the best.
And yet, they routinely do pass these interviews.
You could solve all these questions as long as you are good at problem solving, *given enough time*.
However, with tight time constraints and perfomance pressure, the only way you could solve all these questions is memorizing and practicing all these algorithms.
Apparently the correct answer is to use "Robert W. Floyd's tortoise and hare algorithm", which is trivial to explain and code.
The catch?
It took a decade of computer science research between the original statement of the problem and Floyd discovering the solution.
So... no worries, you have an hour, a marker, and a whiteboard. Your time starts: now.
The tortoise and hare algorithm is not the foundational skill required to make software work the way an understanding of motion is for building structures. That's why it's often omitted from educational material yet these people are able to produce usable software after even something like a bootcamp (which I guarantee basically no bootcamps ever touched this algorithm).
I'm not sure I approve of asking even more well known algorithms like Djikstra's algorithm or A* in a job interview, unless the role was something that specifically required that area of knowledge like building pathfinders for video games or robots or something.
You’re expecting the mechanical engineer to recall something they learned about kinematics, not derive it on the spot. It’s a test of knowledge, rather than cleverness. The equations of motion are also more central to physics and engineering.
A decent programmer should know that linked lists exist, their general properties, pros and cons, etc. However, cycle detection is not a particularly common operation, so not knowing Floyd’s algorithm tells you very little—-and their failure to do years of research in 45 minutes even less.
Also, it took around 13.8 billion years for Newton to do what he did.
If they actually aren't looking for people who just cram CTCI or leetcode, coming to this answer from first principles is demonstrably far more difficult than you'd expect achieved in an interview.
These sort of questions have an incredible recency bias, and have zero relevance to engineering competence.
Of course; how else do you do back-door age discrimination?
"So we specifically asked for linear time."
"Uh, yeah, I did it in log(n). That's better."
"It doesn't match what's on this paper they gave me. Thanks for your time. We'll be in touch."
No such avail. In fact, unless these algorithms and problem solving methodologies are baked into your memory there's no way you are white boarding a Leetcode hard level problem in an interview.
What I was impressed at an Uber interview was their system design interview process - which basically boiled down to 'how do I abstract retrying a 429 - rate limit exceeded.
What I take is that - the interviewer is expecting a very specific solution even in an open ended system design question. It's like throwing a needle in a haystack at you and expect you to get to the needle in like an hour :).
They're probably looking for some sort of variable refilling leaky bucket implementation, which is funny because I believe this is exactly what they do internally. It was probably the task the interview had in front of them in their day-to-day and wanted you to do it for them!
This is a fair design question for a senior role (which this sounds like) that promotes disccussion, but expecting a specific solution is really only testing "does this person match my preconceived ideal for what a <dev> is?" which is really dangerous and has very little value.
I thought it was exactly those who Google wants to pass. Anecdote: ex-colleague of mine who is not specially bright studied 3 months how to "crack the coding interview" and got a job at Google. His knowledge about algorithms and data structures was like mine: I know what a tree is, I know there exists operations one can perform on them and some of them are more performant/efficient than others... but I would need to Google how to "reverse a binary tree" if I had to do it in less than 1h.
Plenty of times where I've used trees because they're the logical representation of the problem (ever had a field called "children" in your code? HN comments are a tree. Etc.)
Sounds bright to me.
I think your weights are way off.
The biggest difficulty for most seems to be that they don't know what "reverse a binary tree" actually means. It sounds kind of mathy and opaque, so I get it, but candidates should be able to have a dialog to figure out what the requirements mean. And on the flipside interviewers should be ready to have that dialog and not count not knowing the term by heart against the candidate.
This problem to me feels qualitatively different than the "rabbit and hare" algorithm for finding a loop in a linked list mentioned by another poster. That one needs a non-trivial algorithmic insight that just might not come to you during an interview. The solution to "reverse a binary tree" flows out of the structure of the problem statement as long as you have the fundamental skills for walking and manipulating data structures and the conversational skills to understand the problem, both of which seem fair to test for.
That's just absurd. If someone with no "algorithm" experience who was a good problem solver had to work out an answer from scratch for the interview its almost certain they're going to find the brute force answer and FAANGs pretty universally want the most efficient one so these people would routinely fail.
Its totally clear that what FAANG hiring optimizes for is recent CS graduates who passed tough Algorithm weed out courses at well known colleges in the past 18-24 months. They are young with no families or obligations and are happy to work 12 hour days at Google because they have hip open offices and ping pong tables.
This might actually be part of the retention strategy. If everyone who works at FAANG knows that they're somewhat lucky to get in, regardless of ability, it means they are less likely to jump ship. What's the point in applying for another job when you're already paid well and it's unlikely to end in anything but lost time? You're unlikely to win a 10% lottery twice, given the amount of time you'd bother investing.
The 'FA.N.' part of it maybe: https://en.wikipedia.org/wiki/High-Tech_Employee_Antitrust_L...
If I change jobs, and find myself in a good situation, and need more head-count, I'm going to reach out to people I like that I've worked with before, see if they might be interested in a job change. I know I can work with them, know we'll build good stuff.
There's a constant drive in FAANG to hire more people, most teams have open headcounts. To the degree that it's extremely hard to build up that funnel of candidates. If my team has a head-count of 5, that realistically means I've got to find a bare minimum of 30-40 candidates to enter in to the pipeline from somewhere, to maybe get close to that target. That's a slightly optimistic conversion rate. Now scale that up across a company with thousands of teams that are hiring. Getting that pipeline filled on that scale is crazy. It's just one of many reasons why FAANG go all in on college hiring events.
I can almost 100% guarantee to get someone I've worked with in a FAANG co-worker through the interview pipeline and in to a job. They know their shit, they know what they're doing, and they know what the process is like.
[1] https://en.wikipedia.org/wiki/High-Tech_Employee_Antitrust_L...
I am not looking externally until I'm sure I'm done at AWS. I've done 80+ interviews here, and I'm consistently amazed by what drives people to say "The candidate wasn't up to the coding bar". As far as I can tell, you are almost never up to the coding bar. I think we interview so many people just to remind ourselves that if we leave, we aren't getting back in.
Just to head off the "So why don't I argue for change?" questions, I'd rather work on self improvement than fight tooth and nail to make the hiring process a little bit better. I'll let somebody else add that to their promo doc.
I never interviewed for the AWS side of the house since I knew I wanted free time, and a life.
It's the bar raiser's job to make sure that the hiring manager doesn't just hire people to fill seats. More than once, I've seen bar raisers override hiring managers when there was compelling evidence from the technical interviewers.
At least in my org, you don't get the job if you don't raise the bar. Period.
I had plenty of times where an entire hiring pod would incline on a candidate because they had the soft skills we were looking for in that role and we knew we could sharpen their technical skillset in house. You don't have to be a rocket scientist to work at a FAANG... you just have to be interviewed by a team that is hungry and likes you.
You're evaluated against people in the same role, not the entire team. But, yeah, the idea is that the hiring standard (the 'bar' in Amazon terms) is always getting higher.
Same as there is no amount of money you could give me to end my life, a position which I assume is shared by a vast majority of humans.
Time is not money. It’s not even close as an exchange rate. I would never put myself through these types of interview processes (not to mention that I would assume that sort of thing to be indicative of the job itself and company as a whole) because I value my actual life and dignity far and above what I value as an upper middle class income.
That always works out well.
Pretty sure a lot of older parents would take a deal with lethal injection + $1M for their kids to inherit.
I am at least 90% sure that part of these interviews is to filter out people who these sorts of views. These employer would much rather have someone who wants to work 100 hour weeks and be the 'hero' over someone who works exactly 8-4 monday-friday and then goes home.
I've updated the profile to include "No FAANG companies" because I'm pretty sure I would not be a good fit for them but that didn't stop their recruiters from pestering me.
For my LinkedIn I listed minimum requirements and it saves me 100+ inquiries per week but I still get a ton of irrelevant jobs.
NOBODY HAS "FIGURED OUT" HIRING !
Not Google, not Apple, no one. Sure, some places (and individual interviewers) are better at it than others. But at the end of the day, hiring is a deeply subjective process with lots of error and uncertainty built into it's nature. The subjectivity is intrinsic.
Places like Google can afford to be nonsensically picky and not suffer drastic consequences from it. They have a thick, never-ending stream of highly qualified candidates. At their volume of hiring, it doesn't matter to them if they screen out some folks that would have been brilliant hires, nor does it matter if they hire some promising but ultimately disappointing duds. All of that is OK.
Sadly, however, it seems that small shops are trying to cargo-cult Google's hiring practices. That IS harmful to the company and the candidates, IMHO. I think folks in these non-FAANG companies should get trained on how to conduct interviews, especially if they're interviewing non-senior candidates. Interviewing is a skill in itself. It's not something that comes automatically with expertise nor is it something that can be left entirely to HR drones.
The good news is, it's a very open network. We have a highly active Meetup scene, pretty regular public hackathons, annual small software conferences and un-conferences, and coworking spaces are (well were) packed.
For the most part this has worked, people new to the community are able to find jobs and the people hiring them know what hey are getting. But also like you say, this doesn't really scale to larger operations.
I'll accept the statement. But I will say that hiring from a network is at least a very different thing from hiring through a grueling set of often artificial interview hoops. It requires a potential candidate to have genuinely interacted at a higher than superficial level with a lot of people in a professional capacity. Which may not be harder than "leet code" but is certainly very different.
And yes, all the big companies have referral programs but that's mostly just a very rough first pass as a lot of referrals are basically I'm connected with this candidate on linked in. Referral bonus please.
Let's say Google would like candidates with PQ>130 with 95% confidence. Google has an error with std. div. of 15 points in measurement of PQ in jobs interviews. Google then needs to set the hiring bar at 160 PQ in order to get those candidates. This:
- screens most qualified candidates out; but
- most candidates who do screen in are qualified
Statistics would suggest this leaves you with 95% qualified candidates. A more precise Bayesian analysis will show you don't end up with 95% qualified employees, but the basic idea works -- it's still a majority. You set an impossibly high bar, so that candidates hired need to be qualified AND lucky. You discount unlucky candidates, but you don't hire (many) unqualified ones.
The problem, of course, is that all Googlers are convinced they all have a PQ>160, and are superior to everyone else. That's where you get the obnoxious Google incompetent arrogance.
And likewise, other employers looking to hire ex-Googlers are convinced of the same.
Someone just released a product that offloads Chrome to the cloud. Gmail has a very long loading screen. Hangouts was replaced by something like 4 incompatible apps. Android phones are significantly less power efficient than iPhones. YouTube copyright notices are trivial to game. Etc
Most of what makes big companies succeed or fail is in the overall culture, organizational design, incentive structure, and corporate structure -- properties of a network of individuals rather than of those individuals themselves. I think most of Google's success and failings can be explained that way, much more so than the success or fault of employee quality.
Organizational design is really hard to get right. A senior manager described it like a herd of cats. If you get them all mostly moving in a beneficial direction, you're doing okay.
That's why they pay executives the big bucks. Executives fake understanding how to manage this stuff. Most don't, but they do a good job of convincing boards that they do.
I wouldn't care about some company's code quality but in these cases Google's clout (due partly from their maladaptive hiring practices) causes these bad libraries to get grandfathered into many projects that I have to deal with.
I've worked in companies where great programmers produced horrible code, due to cultures of optimizing to productivity metrics / features shipped, rushed timelines, and interrupted work schedules with meetings, requirements changes, and people multitasking projects.
I'm not arguing one of those is better than the other. Running a business is about tradeoffs. I am not particularly impressed with anything Google has engineered in the past decade or more. The original search, gmail, Google Docs, Android, Maps, and a few others were brilliant, but those are a long time passing.
On the other hand, I'm not ready to condemn anyone working on those over that. Competence is situational and context-dependent. I also don't have insight into Google business decisions. Google revenues are growing exponentially, so they're clearly doing something right.
Makes me curious about if you have thoughts about how to find people who are good at that stuff for real (not just faking)
Place the bar high enough and you will get more and more people far into the tail, and less and less people that actually fit your bar.
A lot of really good people are discouraged by repeated rejection. However, high levels of rejection of very qualified people are built into this (and many similar) systems. You have to be qualified AND get a lucky die roll to get in the front door. Once people stop taking rejection personally, they can start acting more rationally, and there's less emotional harm. People feel really bad about themselves otherwise.
There are back doors with less luck involved.
Corporate arrogance isn't a property of individual personalities. Most Googlers are perfectly nice people. The Google corporate culture is a whole is rooted in a deep superiority complex and dripping with arrogance. Google believes it knows better than its users, and that translates to all aspects of product design. If you moved those same engineers to a different company, you wouldn't have the same behavior.
I'll also mention that each organizational design has upsides and downsides.
This culture seems to work well in Google's early markets (e.g. search) where users are statistics, and where most problems are hard algorithmic problems, and users are secondary. It has upsides in B2C markets like Google Docs or Android. It crashes-and-burns in a lot of B2B markets, like Workspace or GCP, where customers have a high degree of expertise which ought to be respected.
I'll mention a lot of fintech companies, as well as elite universities, have a similar culture. Those are domains where it leads to success as well.
Instead, you should try to find lots of correlates of PQ and measure them regularly.
Because of this, I often hire people I've already worked with. I'm also often hired by people who've already worked with me. I hate that this leads to a very homogeneous experience... or even what might seem like gatekeeping. I've just found that the best indicator of how a person will perform, is already being familiar with their work.
In my, admittedly not super extensive experience, I tend to believe that about 1 in 10 companies actually knows how to run a hiring process. I'm not sure precisely what kind of error bounds I'd put on that, but I doubt I'm off by more than a factor of 2 either way.
(This is a massive oversimplification, of course, but you get the idea.)
No one knew who they were interviewing or what was on the resume until they glanced at it while walking to the interview room. I suspect all interviews and the process are just made up as folks go along, and half the time you get a gig or not mostly based on if one of the people you talk to is in a good mood or not.
This is in contrast to tailoring each interview to a candidate's background.
With that, I think looking at a candidate's resume 15 minutes before an interview is not that unreasonable.
What am I missing?
(edit: this is meant for IC roles rather than management)
Part of the problem is the sheer scale of hiring, but I think most of the problem comes down to the lack of feedback or evaluation mechanisms on the interviewing side.
They train you up, half a days worth, training tells you not to be an arsehole, not to ask stupid questions, not to have unreasonable demands of candidates, not to be biased. They don't train you in valuable skills like active listening.
Next thing you know, you've done training, and you're interviewing candidates every week or two (or more often), and there is zero feedback mechanism. No one evaluates your interview questions, no one asks candidates to provide feedback on the interviewers. No one looks to see if you've got unreasonable expectations as an interviewer, or have your expectations set too low.
You do have to do a post-interview group discussion with the other interviewers to make a yay/nay decision, but it's super easy to present what you did/asked in a positive light.
The whole system is designed around the interviewer being right and infallible. Is it any wonder the process is so completely and utterly broken?
edit: > or have your expectations set too low
This is where I bias towards in worrying, imposter syndrome and all that jazz. I've made a conscious choice to not raise that bar higher. I think the questions I ask are good, I think they're set up well enough to encourage candidates to go as deep as they feel comfortable with. I try to design them with no one true answer but have a few in mind so I can go where the candidate goes.
Are you saying each interviewer just makes up their own questions?! That's ludicrous if so. Where I work, we have a standardized pool, with standardized evaluation criteria.
Obviously the drawback for FAANG is that standardised questions would rather rapidly leak. Very quickly you'll just end up with candidates that know how to answer your questions.
Where I work now, it's a mix of pool questions ("soft" skills) and interviewer-made questions (technical skills), but it's not a hard and fast rule to use the pool questions. I rarely use the precise wording for the pool questions, and instead adapt them to match the conversation with the candidate.
1. We trained 4-5 times on each type of question. The first few were shadows, and then we did reverse shadows where someone watched us give the interview and gave feedback later. In one category I asked for and was allowed to reverse shadow an extra 1-2 interviews.
2. There was auditing. In debriefs where you discussed the candidate and reviewed notes, the debrief lead was supposed to closely examine what questions you asked and how you conducted the interview, with the explicit goal of making sure that the interview was conducted within spec and your recommendation made sense given performance. Shortly after I was certified to do interviews, a debrief leader (correctly) identified a major issue in an interview that I had conducted. That candidate was given another interview in the same category. Although I didn't face any official sanctions, it was definitely an embarrassing experience and made me handle future interviews more thoughtfully.
Overall, I was fairly comfortable with the rigor of the process that I saw. I'm certainly not saying the process is perfect but my experience did not align with yours.
(the "lizard brain" is a myth by the way; I think you're confusing it with unconscious bias of heuristics, which is not what the triune brain theory was about)
But I'm curious what position would this question make sense?
I was once asked a similar but better posed question: I was given some code and asked what I'd point out if asked to do a code review on it.
And the code had loads of things wrong with it, from bad variable names and incorrect comments, through unit tests that didn't have any assertions and loops that weren't actually loops, all the way to choosing a non-secure random number generator in an application that needed a secure one*
In other words, it was a test of my ability to code review, with some glaring issues to give me some easy marks and set me at ease, and some subtle issues where talented people could really set themselves apart. It was fair and relevant to the job because I was presenting myself as a senior programmer with lots of experience doing code reviews and coaching junior developers.
It's possible trinovantes's interviewer intended to give the same sort of test - but either didn't explain the question clearly enough, or trinovantes misheard or misremembered.
* A bug right out of puzzle 94 in 'Java Puzzlers'
At a different interview, this one with Microsoft, the lead engineer showed me a page of actual code from their app and asked me what I thought. Luckily the bug instantly leaped off the page to me, although many people would not see it. That was a good way of proving that I have a useful ability, and a better use of time than whiteboard coding or quizzes. I got the job and they were glad they hired me.
Coding is a mostly solitary activity that you probably don’t want candidates spending more than ~60 minutes on, ideally on something that resembles the actual day-to-day instead of sucking all the Leetcode possible out of them. Even just quickly pair programming on something nets you more data points in the same time.
IDE tools are great performance enhancers, but they can also be crutches.
I would always expect a professional software developer to be able to parse some code on a page and point out its syntax errors (as well as suggest edits).
edit; here I am thinking about something more substancial then just a missing ';' or a lack of a closing "
bool x = false;
x ||= something();
How many do remember exact operator precedence rules for all those languages, when in practice you may need just the basic ones and use () to work around the lack of exact knowledge.
Also which version? Something not working in PHP 7.3 may be ok in PHP 8, but company wants you to code in PHP 7.3, or ES5. In practice you get quickly acclimatized to any of the languages you know after working with them for a few days or a week, but good luck remembering exact rules of any of them at any given time when asked.
And yes, I work in multiple languages.
Performance issues, on the other hand, I can see accidentally arising.
Where you want to make sure a pointer you've been given isn't null before you try to dereference it. Without short-circuit, this becomes a segfault.
I've never seen someone use an "or" pattern in a non-confusing way.
That is, I've seen "and" patterns that act as a safety/early out. I fail to see the use of an "or" pattern where you want to stop executing if the first value is true (ignoring using nots to invert the logic of an and pattern, and I would criticize that).
They do exist in other languages. ES has it in exactly that form. Java has it in the |= form, not to be confused with the bitwise OR of the same form.
Whether or not these short-circuit is not all that interesting for most boolean logic. (Though it can be useful to know if these are used as hacky error-handling and default-setting. It depends on how you read "something" whether or not that's going on here.)
Where and when? Because I was the only person alluding to it, and the replies to my post.
> Whether or not C++ has them (it doesn't) is exactly the point of that code snippet.
C++ has boolean assignment operators that operate the way that the code is clearly meant to operate. That code does not have have a valid one. Where do you think Java got them from?
https://www.w3schools.com/cpp/trycpp.asp?filename=demo_oper_...
||= will not assign anything unless the LHS variable is falsy. It will not even evaluate the right side unless LHS is falsy.
|= will work the same in C++ and ES mostly (depending on types)
The fact that the ||= operator short circuits makes sense from an optimization point of view. I will maintain that there is no good use for the correctness (as opposed to optimization) of the code to depend on that feature.
The words "boolean assignment operator" are in the first sentence after the code snippet in megous' post.
> C++ has boolean assignment operators that operate the way that the code is clearly meant to operate. That code does not have have a valid one. Where do you think Java got them from?
As far as I can tell the |= operator in C++ is the same as in C, i.e. a bitwise OR operator. It works for booleans due to their bit pattern, but it's not the same. My C++ knowledge is extremely limited, so I looked it up and I may be misinformed though.
Java's |= is different for ints and boolean. There are no bitwise operators for booleans: bool1 | bool2 is a strict logical operation (that doesn't short-circuit). bool1 |= bool2 is a logical operation that will fail when other types are mixed in. int1 |= int2 is a bitwise operation. Java does not have a short-circuiting ||= operation (but ES does).
For the most part these differences aren't that important, but they do trip people up when switching between languages.
This is true.
> It works for booleans due to their bit pattern, but it's not the same.
This makes less sense. A bool in c++ is just an integer value with few inputs. It is, as far as I can tell, the exact same.
> Java's |= is different for ints and boolean.
Java has bool and int as different types. There were versions of C++ compilers that just straight out had bool as a typedef of int.
Modern development requires juggling too many technologies for most people to specialize in a single language unless their career goal is to niche themselves to that language.
So at least 4. If you combine webdev with something low level/embedded, you need at least one systems language, so you're at 5 languages you need to be proficient in.
Add one hobby language or a second web backend or systems language, and you're at 6 major languages.
7 is a lot. But 5 is plausible to be proficient in for someone who switches between webdev and lowlevel stuff to not burn out, or has a FOSS hobby.
Also proficient != expert. I met enough developers that were brilliant in their work to be convinced that 5x developers are not a myth, but they are real, while rare, occurrences. For me a senior developer in X knows the ins and outs of that X to the level that his code is an order of magnitude better in term of efficiency, performance, productivity and security. A regular developer can be just proficient, but it is not what I wrote about.
For skilled, experienced programmers, most mainstream languages become an implementation detail. You have to spend time learning idioms, footguns, and generally the way the language manages memory, but you absolutely can be great at 7 languages because they fundamentally do many of the same things.
I haven't hired people based on "their stack" in a long time, and it's been completely fine. Someone with skills can quickly learn your stack and be productive in it. I personally jumped on a project as a coder a few years ago having never written C# before, and I was productive in about a day. All the concepts were familiar, and the stuff I had to learn was mostly syntax.
> All the concepts were familiar, and the stuff
> I had to learn was mostly syntax.
If you can be productive in about a day, please explain why a pilot gets ATPL (airline transportation pilot license) after a minimum of 1500 hours of flight. Also please tell if you would board a plane where the pilot has 100 hours - that's an awful more than a day or even a week.
99% of the pain in a new language usually ends up being the (often god-awful) tools, platform/SDK bullshit, and learning where the clearest path is incorrect (no no no, the official docs and tutorials say to do it this way, but everyone who knows what's what actually replaces that entire part of the language/first-party libraries with this other library developed & open-sourced by some other company, since the official way is obviously so terrible, and you just have to know that, or notice by reading other people's projects—ahem, looking at you, Android). The language itself is typically nothing.
This has worked out fine for me. It does mean I've gradually grown to hate languages that lack static typing. I don't want to remember or look up things when I can make a quick note and then let the computer remember or look it up for me. I thought that was kind of our whole thing, no? Having computers do stuff for us, when they're able?
Yes, they are absolutely crutches. All great tools, libraries, and abstractions are crutches. I want programming to be easier for myself and my employees.
The only problem with a crutch is that you might end up not having it when you need it. That's not an issue in this case.
> here I am thinking about something more substancial then just a missing ';' or a lack of a closing "
The original example that I was responded to was about an interviewer who expected their code to compile. That would include incredibly pedantic things.
For example, if you're the kind of person who uses single quotes in JavaScript and then you're suddenly writing a different language where '' is different from "" and `` and $"" and whatever, you could easily make an unimportant mistake that prevents compiling.
Last time I saw one of those test-ish pieces of code, though, an IDE+static analysis would have caught about 1/2 of the problems; the other half required actual thinking (not statistical pattern matching, aka AI): "don't trust user data, that should not go there even though the call signature matches, you're holding it backwards."
Good type systems do this, although it's beside the point.
The point I was making is that the IDE remembers unimportant things so that my only concern is the actual thinking part. It abstracts away the minor and sometimes very important syntax differences.
Having said that, if someone came up with an interview test which used especially esoteric parts of the language in unconventional ways and then asked to spot the errors, the could be a dubious question.
When did I claim that the IDE absolves you of needing to know the syntax?
It doesn't. But between autocomplete, hinting, linting, and any other static analysis, it makes it close to painless to switch between languages without making horrifying mistakes. The top-tier JetBrains IDEs (IntelliJ and Rider come to mind) will even tell you ways to make your code more efficient or modern, like changing a bunch of if/else to pattern matching.
Why should I have to remember the full truthiness table of JavaScript? Why should I have to remember what all the different string delimiters do in every language? It's not important. My IDE can (and does) know that I'm trying to do some kind of string interpolation and will just fix it for me.
That doesn't mean you can't debug. You can step through the code step by step in the debugger, or add more and more logging around the bug, until you figure out which expression has a meaning unintended by its author. But that means that, if we're working in a language someone knows well, you're likely to spend hours debugging a problem that they can just see immediately when they're reviewing a merge request. That's an orders-of-magnitude difference in productivity when it's important for code to be correct, precisely due to what you call "precise syntax memorization".
Most of programming isn't writing code. It's reading code.
It's possible to go overboard with this. There are other skills that are more important than being able to look at some code and immediately see what it means. There are excellent programmers with severe dyslexia who will just never be able to do this. But it's foolish to think that gaining this skill is "a waste of time" for those who can.
There are languages I've used where I don't know the syntax that well. PHP, Ruby, x86 assembly, OCaml. There are languages where I know the common syntax well, but there are plenty of obscure corners of the syntax that I don't: C++, Perl, bash. But I regularly switch between C, Python, and JS, and I'm pretty confident that I know their syntax, as well as numerous other languages like Tcl, Lua, Prolog, PostScript, and arguably Scheme and Elisp, which I don't use regularly but still wouldn't have any trouble spotting syntax errors.
Luckily I never fucking ever have to do that in my actual job. If I did, I might well get good at it. Since I don't, I... don't. I also haven't gotten much better at driving semi trucks or framing a wall, in my over-a-decade career writing software. Go figure.
In contrast, I've been stuck in a giant multi-language integration-fest, and... well, there are definitely languages on my resume that I would not be comfortable being pop-quizzed on, simply because I've been using others for the past two years.
_Can_ I make sure the code is 100% correct before even compiling? Sure, but I'll spend an hour checking every detail, while intellisense does it while I type.
Let's turn this around: if I were interviewed by someone who flagged down my code for missing a #include or lambda capture (both very easy mistakes to make), I'd know that the people I'm interviewing with are idiots with no understanding of the thing they claim to be testing me on. Would I want to work there? Nope.
There is a difference between "find the errors in this provided code" and "write code on a whiteboard with no errors". At no point was I talking about code you wrote.
Also, it's an aside, but I find people who can program well write excellent documentation for the users, if what they are writing is an API. Of course, they are not the best at explaining the steps in a GUI, but that probably has less to do with communication skills in general and more to do with the difficulty understanding how they perceive the problem.
I remember thinking what you're writing about there, that there's a lot of people to be filtered out, and that good candidates wouldn't be offended.
So we had this simple two-part quiz question for people, starting with "what is the expectation of a dice roll?". Amazingly a lot of people can't figure this out.
But also a lot of people know the answer immediately and will wonder WTF you are asking such a simple question for. I remember this one lady who interviewed with my firm, the look on her face when she realized we weren't asking anything complicated. You could just tell she thought we were a bunch of amateurs, and she'd better be on her way to see some other proper hedge funds.
But I think the point in this thread is the Google question about Linux inodes was actually part of a pre-screen interview done by an outside agency.
But yeah, I think I've seen questions like that for an intern positions. It's basically a "have you ever seen this language?" to weed out people quickly.
It's not that. People who constantly use multiple languages in an IDE will not be able to point out most syntax errors outside the IDE. So it's not a "have you ever seen this language" filter.
The questions go like,
What is the output of the expression below?
int i = 10;
****++&&*+p;
Not sure how this measures language proficiency.
> int i = 10;
> **++&&*+p;
> Followed by a myriad of options. Including things like Syntax error.
I consider myself fluent in C and to a lesser extent C++ -- that's a Syntax Error in C, at least.
This isn't a particularly difficult one to spot, but I can understand how it would be if you weren't very familiar the language.
Eventually your eyes will give being a lexical analyser.
(/me runs away)
In this interview, I would have liked to receive two code examples (that might contain errors) and discuss benefits according various objectives.
If the interviewer makes it clear that pointing out syntax mistake is not rude, I could mention them in passing. This demonstrates not only attention to details but also decorum.
That’s true whether I’m an author writing in German, a newscaster reporting in Italian, or a programmer coding in C++.
What you say applies if you're hiring people for their first position at that task (e.g. the author writing their first book in German or a newscaster who has never done reporting in Italian professionally). If you're hiring people at some hypothetical "level 10" then your interview needs to discriminate between "level 9 or less" people and "level 10 or more" people, but asking them to assert that they meet "level 1" implies that they might not, and that implication is literally insulting.
Switching part of the interview to be in Italian or German would not be seen as disrespectful, right?
It’s interesting that some find the coding equivalent insulting rather than merely a bar pointlessly laid on the ground to be stepped over.
A bar pointlessly laid on the ground to be stepped over is reasonable iff it's you can just quickly to step over it - but if they ask the candidate to waste half an hour to prove their capacity for stepping over bars laying on the ground, that is disrespectful of their time.
For programming, a trivial short task (e.g. fizzbuzz) is appropriate but a trivial long task is appropriate only for junior positions but disrespectful for senior ones - ask something that tests whether they're capable of something serious, because passing the trivial task can't be sufficient anyway.
Recruiters need to understand that these kinds of processes will often filter out the wrong people, such as those skilled enough to be able to pick and choose.
If OP was a dick about it, then yeah, it serves to filter out an arrogant assbag.
But if OP simply explained that the interview led them to believe the position was a more junior/entry level than they were expecting, that seems fine. Further, to even explain that the interview process seems to just be a checkbox process seems fine; if you work in a critical thinking/creative role, checkbox culture is an absolute brain drain.
Getting that out in the open, in honest and respectful terms, is a fine thing to do. Why wouldn't it be?
Further, any hiring institution that feels the need to build in 'tricks' to filter people out of the interview process is toxic. Even if the people they're filtering are arrogant assbags.
Candidates often have to call out nonsense otherwise it may never be called out. Processes need feedback to adjust and adapt, otherwise they'll typically continue with momentum alone.
With that said you can give feedback in a polite and professional way, you don't have to be arrogant about it. "Based on the questions, it appears you're searching for these specific abilities which are often attributed to a junior role, so I believe I may be a mismatch for this specific role. I'm going to politely withdraw my continued involvement in this process. I appreciate your time and interest and hope you will contact me if a more senior role is available." Or something to that effect. You don't have to be arrogant to give feedback.
If you were like "what, this is ridiculous, what am I am an intern? Good luck filling this trash position!" And then walk out then sure, that person clearly had some anger management issues.
Interviewer: How would you reverse a string? Me: boggle Any language I want to use? Interviewer: Yes. Me: Okay, Ruby. "somestring".reverse! Interviewer: boggle Me: I don't think we're aligned on what this role is. says thank you and leaves
Interviewers need to understand what they are interviewing for.
If you I consider that arrogance, then so be it. I consider it not taking jobs that'd make me miserable, because I don't need to.
A prospective employer doesn't have a right to have me bend over for whatever process they'd like.
It very much depends on the code - but I was genuinely surprised how many applicants, claiming to be fluent and applying for a senior developer position, had problems just grokking what the code did (a while loop reading from database).
If there is an error, I can quickly figure out what that is and what I should do to fix it. I would know why the error occurred.
Beyond that deliberate interview practice is the only way to get a lot of interview questions right.
(Admittedly if the PR doesn't build why are you reviewing it but whatever)
And you are having a CI build and unit tests in place. If it doesn't compile or a lot of tests are failing, a sane person won't even bother to review a pull request.
If you check out the branch in your IDE, is there a way to have it highlight the changes in the branch you're reviewing? Or do you need to reference the output from `git diff` or the github PR view?
1. Open Source control window
2. Checkout the PR branch
3. Open the branches listing panel in the sidebar.
4. Mouseover the target branch of the PR
5. There's an icon that looks like two nodes with arrows pointing between them. Mouseover text "Compare with ...". Click it.
6. The search and compare panel in the sidebar has a listing of files changed, you can click a file to get a diff view.
There are gitlab [1] and github [2] extensions which streamline this workflow if your code is hosted on one of those services, and let you leave comments in editor which show up in the web UI.
IntelliJ has support for display a diff for a branch or github PR built in [3] but I hate their diff modal view.
[1]: https://marketplace.visualstudio.com/items?itemName=GitLab.g...
[2]: https://marketplace.visualstudio.com/items?itemName=GitHub.v...
[3]: https://www.jetbrains.com/help/idea/contribute-to-projects.h...
There were two - I pointed out both and they didn't seem super happy about it. To this day I'm still not sure if one of them was an unintentional error.
Any time I’ve interviewed people I’ve made it a point to emphasize that none of my questions are trick questions and if anything is unclear, they should ask clarifying questions. The result? Interviewees are more comfortable and are far more honest about what they know, what they don’t know, and you get to see a glimpse of what they’re really like.
It is fine to say 'I do not know'. It is fine to guess, but if you do, I would prefer that you tell me it is a guess.
If you want any clarification, I will try to provide it. If you don't recall the exact signature of a library function, ask me. I will note down what I said and not hold incorrect nformation I give against you.
Any questions before we start?"
You know, if I had to do that for every PR I reviewed, I'd be burned out in no time.
It was a shame, but if I didn't flunk that interview then I wouldn't be where I am now.
This is, I think, the closest thing there is to a universal experience in this field.
Followed closely by "how did I miss that single-character error?"
"What does this code do?"
That was a pretty easy one to figure out, it pulled coordinates from a database table, and then it stepped along all the lines trying to find the longest one (they were a metal shop).
"Do you see any evidence that this code has been optimized?"
That was the dumb question.
Seeking out problems and errors can be a good conversation piece. Hopefully you get to hear some anecdotes, prod the taste in style and how well that that taste might play with others. The interview situation isn't easy for anyone, and anything that can if something is even remotely qualified helps.
I had 10+ years experience in C++, I thought it was completely reasonable. Especially compared to their later questions around something along the lines of finding a shortest path in a tree. I interviewed there a bit before their process was so well known to be game-able, I went in with zero study time on obscure algorithms outside knowing the O(N) of the most widely used, and certainly did not practice actually writing or interacting with trees and such.
There was a function with a syntax error, that also returned a pointer to stack memory, and made some logic error where it assumed a class with no vtable would be polymorphic.
Or they can run it, asking the real arbiter of truth whether it works or not.
Of course, "whether it works" is merely one (very important) metric of quality.
Can you work with this person? Can you collaborate to write code, or will it be a daily struggle?
Whether the code actually builds and runs after the hour is up does not help answer these questions; it is arguably the least interesting part of the whole process. The time limit is artificial; if all the other things align but you didn't happen to get it working in one hour, you'll likely have got it in two. If they don't align, you'd likely never have got it.
This is like writing code in notepad and creating a PR without building or running it to test once. What is this testing? There is no real world scenario where you are expected to work like this and for a good reason.
In my view, if the answer involves a topological sort the interviewer should know how to solve it and be able to follow and find errors in the candidates code. If the interviewer, knowing the answer, cannot find any issues then surely the code is fine (for code written in an interview)
Actually hang on, I'm editing this to be slightly meaner. Your whole take that doing this is a sign that she's either an idiot or on a power trip is a very familiar thing that people say about women in tech and I'm honestly tired of it, because I can see myself doing exactly what she did and I don't like it when people say those things about me. Please don't do that.
You just can't tell someone to type code into google docs and expect it to just work and worst off all judge a persons skill on this basis. It takes minimal experience of programming to learn this. Hence all the jokes that people are surprised/suspicious when their code runs after first compile.
If you disagree with this you could have provided any sort of counterargument. Instead you took this weird "women in tech" angle. Wrong is wrong, interview here was wrong, gender did not play a role.
If the interviewer cannot do this, how is he going to judge the result? Does he know how to run a compiler? Does he know how to run the code? Does he have the skill to judge the output? Is it really a good policy for a company to discard a possibly excellent candidate that just missed something silly that would normally be checked by a tool while you type?
And if you fail to communicate the requirement for one or the other then you're certainly not a competent interviewer.
You also have to ask what exactly is being tested here? Is it the ability to remember syntax? To remember an algorithm? To improvise an algorithm? To recognise which algorithm is needed?
What, exactly?
If you're interviewing for specific language skills, then what you say is clearly true.
If it's a general coding skills interview, I invite the candidate to code in whatever language they like. More often than not they choose a language I am sufficiently fluent in to follow along. In rare cases I need to ask them to explain a thing or two. In very rare (but generally quite fun) cases they choose a language I am totally unfamiliar with; this tends to lead to interesting discussions.
In all of those cases the full coding transcript is captured and, if necessary, can later be additionally reviewed by/with someone who knows the language well.
P.S. Also, their thought process and approach to problem solving is just as important as the code, and is largely independent of the choice of programming language.
We do NOT require you to produce token-by-token perfect code, and nowhere in the process will I ever have to give feedback on whether the code produced was actually valid. So maybe you misunderstood your interviewer's intention, or something else went wrong, or maybe they were just joking. But it's not the interviewers task to copy code into GCC and try it out, that'd be a huge waste of time. So let me be very clear and explicit: no-one gets classified as "no hire" because they've forgotten a semicolon somewhere. You messed up somewhere else.
With that said, if a candidate says they can write in a language, we expect them to know the language, its idioms and at least parts of the standard library. Not every nook and cranny (e.g. I'd often instruct candidates "just pretend you have some library that implements a heap, and invent an API for it, I don't care about that part"), but if you call "strlen" in the termination-condition of your for-loop instead of before, or do other stuff that shows you don't know the language well, that's a red flag. After all, we expect you to be able to write production-level code that servers billions of users.
And therein lies the problem.
It depends on who you get as your interviewers, so generalizing isn't really useful. Some interviewers can't relate the interview to what it is supposed to tell you. I've seen that in inexperienced interviewers and I've seen that in very experienced interviewers who had enough GOOG stock to buy a small country.
If the interviewer can't think of a better way to test candidates, that's on the interviewer. Not the candidate.
How much money can you bet that this never or does not happen? If you can't put your money, I find it difficult to take this seriously.
> We don't usually care if you don't know find the perfect algorithm (unless it's for a senior position)
The unless clearly means that you "do care".
“We do NOT”
“You messed up”
“let me be very clear”
“whether you’re able to code”
These types of statements come off as patronizing. If your whole process sounded like this, and if you somehow actually do represent a majority of Google interviewers, then it’s no wonder so many folks have a distaste for the experience.
The arrogance displayed in your comment isn’t backed up by the ultra-low quality of product being produced by Google. Something is clearly wrong with the culture and hiring process there. Maybe instead of fretting over people using strlen as an exit condition, you should look for people who can actually produce software people enjoy using. You don’t even need to do a coding interview! Just browse GitHub for people you want to hire and get to work convincing them to join you.
I can see this interviewer writing feedback like "Well, this candidate didn't come up with a perfect implementation of Dijkstra's shortest path algorithm, but its OK, they were pretty close. Oh wait, they are a senior engineer? Nevermind... they should have really mastered these algorithms while building CRUD APIs all these years."
As far as algorithms/data structures, most of what we do on a day-to-day basis is more about selecting the appropriate data structures and algorithms that fit the problem, and assembling them together correctly. I've never needed to code a hashtable, but I need to think about their characteristics and whether they're appropriate all the time. I've never written a btree, but I do understand database indices pretty well. So in my view, asking candidates to code up these things on the fly in an interview with no reference materials is a total waste of time. What matters more is if they can correctly apply them. If you're really sure someone needs to write these things, then a more realistic move would be to sit them down with a standard textbook or paper and see if they can get the code working.
> After all, we expect you to be able to write production-level code that servers billions of users.
And you do all this through sheer clairvoyance, rather than using tools like unit tests, code review, design specs, etc, right? No? Then why are you expecting people in interviews to do it without those things.
When you have 3 interviews per week for a prolonged period, you, as an interviewer, are not going to do a stellar job every time. What's worse: you will develop a routine and it becomes very easy to give candidates that do not fit your routine a lower grade. It takes effort on the interviewers part to recognize talent that perhaps doesn't fit your routine or your expectations. If you are not going to end up being a bad interviewer you also have to try to relate what you see in interviews to what you know about work.
For instance I _never_ asked people to code live (mostly on whiteboards back then) because it just isn't a relevant exercise. And I was kind of horrified at experienced interviewers who asked people to code and then got obsessive about small details that the tooling would have taken care of. Absolutely pointless.
The only piece of advice I found useful from the interview training was this: this is the candidate's big day. For you it is a chore, for them it is their big chance. Keep that in mind and respect it. I kept telling myself this for every interview - and some days I felt really terrible because I wasn't properly prepared.
The other thing that horrified me was when we let inexperienced people who had been out of school for less than a year interview people. These interviewers barely knew how to write software themselves, and they'd get even more hung up on irrelevant stuff because they simply had no idea how to be software engineers.
I doubt that I would have done very well in those kinds of interviews because this isn't how I work and it certainly isn't how I teach people to do problem solving. Problem solving requires more time because any even mildly tricky problem worth solving tends to have a lot of facets far beyond picking an algorithm or knowing how to code it up. That's the easy part because for that part, you have books, papers, tools and other people to seek advice from.
Junior programmers right out of school with no engineering experience have no business interviewing developers. They make poor and overly judgemental interviewers and only rarely are able to spot talent if it doesn't fit their template. They also aren't going to fight for candidates that may not fit the imaginary template, but have some special gift because they are junior programmers. It takes a certain amount of balls to say "I know you think this candidate is rubbish, but I see something here and I don't care what you say, I am going to insist".
(btw, statistically, this used to be a good predictor for later success: candidates that were somehow "controversial" in that they didn't make the grade with some interviewers, but displayed something that made other interviewers fight for them)
Thank you for being kind and respectful.
I don't see a lot of focus on the hide-the-ball aspect of interviews, but is something I've experienced a few times and bothers me way more than anything else.
The clearest time this happened I was told the company was big on pair programming, so I'd be doing a pair programming session. It turns out they meant I'd be tested on whether I could finish a coding exercise in the allotted time with someone watching. There was zero "pair programming" of any kind involved and time spent on collaboration counted against me.
1. You should have been better informed about the expectations of the interview, so you would have had a chance to prepare yourself.
2. Coding in a Google Doc is a terrible experience. It's a step up from coding on a whiteboard, but that's not saying much. Google has since moved away from both, prefering an online text editor that's not quite an IDE but at least more programmer-friendly.
3. The goal shouldn't be to write 100% correct code without any compiler feedback. That's insane. Still, there is a big difference between "candidate forgot a semicolon once" and "candidate did not know how to write a for-loop without IDE feedback".
1. Can they figure out how to solve a nontrivial problem?
2. Are they able to translate ideas into reasonable, working code?
1. Those that don't have a clue how to solve it.
2. Those that recognize it boils down to a topological sort.
3. Those that recognize it boils down to a topological sort and are able to implement a solution.
> I didn't remember the exact algorithm so I basically had to re-figure it out on the fly
Yes! That was the whole point of the question! You had already demonstrated that you were at least a "type 2" candidate, so now the interviewer was trying to move beyond that and figure out if you were actually a "type 3" candidate. Nobody expected you to have the exact solution memorized, but they expected you to be able to figure it out from first principles.
> I even similarly mention "in any real situation I would just look this up", but that didn't help
That was missing the point, which was to test your ability to actually implement a solution.
In the real world, if you encounter a standard problem (which happens often, like "I need this list sorted" or "I want to put this stuff in a hash table for O(1) access") you wouldn't even look up how to solve it. You would just call the existing standard library function and move on.
Logically, the problems that you end up spending most of your time on are not of the standard variety, and involve actually thinking about how to break down the problem and actually implementing your intended solution. Those are the problems Google needs you to solve on the job. If you can't even implement a topological sort from scratch, why should anyone expect you to do anything more complicated than that?
Remember reading Bentley's Programming Pearls and fairly sure that's what he starts Sorting section with a short implementation of
Just like I don't think the CA bar should have a pass rate in the 20% range, I don't think coding interviews should ask riddles that are nearly impossible to solve on the fly unless you get lucky and memorized THAT riddle in your studying.
But, here me out here:
Suppose the CA bar exam were changed in format to be more like a SWE interview. That is, instead of being a 2 day affair consisting of 5 essays of 60 minutes apiece, a 90-minute performance test[0], and 200 multiple choice questions, let's shrink it down to a format that fits in one day and under 5 hours.
Now, let's nix the performance test right away, because it would be incredibly difficult to shoehorn in any kind of real, practical task in under 90 minutes.
According to [1], it looks like 100 multiple choice questions are allocated 3 hours worth of time. So, basically, our cut down format could be 100 multiple choice and 2-3 essays. So, that's about half the amount of testing that's done currently, more or less.
Now, if you have half the amount of testing available, you have a choice: you can cover half as many areas of law, you can cut down the depth of coverage in each area, or some combination of the two. In any case, what you've done is increase the variability in the test. In other words, passing is now more likely to be influenced by exactly which version of the test you get.
If there's an area of law you're weak in (say, bird law), it might not even be covered. Conversely, if you're a real expert in bird law, you won't get as much of a chance to shine in the new format. That means our new format both allows somewhat more marginal candidates to pass, and gives up some sensitivity in detecting people who are really, really good.
So, in summary, the new format omits any sort of practical task, increases the variability of the test, increases the probability that marginal candidates will get through, and decreases the ability to distinguish truly excellent candidates.
Seems to me that's sounding more and more like a typical day-long SWE interview, isn't it?
---
[0]: Interestingly, this is essentially a work sample test, which is the thing proven to correlate best with job performance: https://en.wikipedia.org/wiki/Performance_test_(bar_exam)
[1]: https://www.tjsl.edu/academics/bar-prep/california-bar-exam
One such candidate I interviewed seemed like they'd be really great for the role: PhD in graph theory, publications, projects listed on the résumé, couple of different programming languages (including ones we used). To me, this person's résumé screamed "solid mid-level developer." I would have probably been willing to pass them at a junior level, had they been able to perform at that level, though.
The interview itself was a pretty familiar story. For the technical portion, I introduced the problem (not a LeetCode-type problem, a more practically-oriented problem), we talked about requirements, drew some stuff on the board, and then got to coding.
I had a feeling when we were going through the requirements discussion that this might not go as smoothly as I'd hoped, but I pushed that feeling aside and did my best to let them shine.
We let people code in any reasonable programming language, but they must write actual code. They can fill in stuff like dummy helper functions, if necessary, but we want to see some kind of running, syntactically correct, and, preferably, at least lightly tested code.
They chose to code in Java, which, while not a terrible choice, seemed to me kind of like they were just handicapping themselves when stuff like (IIRC) Javascript and Ruby were listed on their résumé.
To make the long-ish story a bit shorter, we muddled through trying to implement the requirements we'd talked about earlier in Java, meanwhile the candidate was showing me a distinct lack of familiarity with basic facilities of the language, such as "what sort of methods do lists have that might be helpful here?"
Needless to say, this person did not pass my interview, and we did not end up hiring them. But, I really, really wanted them to succeed. Like I said, on paper, they look great. And, I'm sure they could have gotten through a culture fit interview just fine. I'm just not sure how well they would have done on our team, working on our rather large, pre-existing, and somewhat crufty code bases.
If you can figure out a good way to automate the task of "filter these developers down to the ones who can write some semblance of code," in a way that goes deeper than just "Write some code and run it against our automated test cases," I'd like to hear about that. And, I'm not doubting that it could be done, in theory. For instance, maybe something like the engine behind GitHub's CoPilot could provide a way to analyze and grade the candidate's code on things like style, testability, test coverage, modularity, &c.
But, AFAIK, there's nothing like that out there now, so, a structured process consisting of ~1-hour technical interview sessions, one-on-one with the candidate, attempting as best as possible to simulate the real work environment, is about the best I can think of.
Of course prospective lawyers should clear a certain level of knowledge before they are allowed to practice, but the passing rate is puzzlingly low. CA law schools, as a group l, really only prepare such a low number of their students to practice?
also, gatekeeping has a negative connotation because it is usually used when it seems unwarranted. If only schools with high quality education are passing students, that doesn't seem like a problem with the gate, but instead with the other schools. I absolutely want lawyers and doctors to be required to pass certain criteria.
The bar is hard for CA because we go to school for the theory and then no one really teaches you the formulaic way to answer bar essays. Add on top of that it's a lot of memorization and study. Most students I went to school with had egos and thought they had it in the bag only studying on the weekends.
I got the offer and took it because I do contracting and had just unexpectedly gotten a contract canceled early, so I was unemployed and have a family. At the end of the 3 month contract they offered me a full time position and I declined.
Especially when I'm not sure the Graph approach is the right one, it's easier than either
1. Getting the Boost.Graph in the source tree to actually compile
2. Dealing with the bureaucracy of getting some, other, Graph library requiring feats of compilation possible for mere mortals into the source tree
This is, however, not something I do from memory - much like the ancestor comment I see the relevant skill as closer to recognizing positive-weight Shortest Path and knowing you want Dijkstra than being able to write Dijkstra without wifi
Holding this kind of bullshit interview isn't a bad idea if you're a megacorp with chaotic teams and fourteen levels of management hierarchy where people spend most of their time on infighting and career building. You need people who jump through hoops, because successfully delivering most projects in these environments is 10% difficult technical work (which the good engineers can handle, and you can typically hire enough of them via recommendations), 40% YAML-poking bullshit work, and -- optimistically -- 50% jumping through all sorts of technical and non-technical hoops, most of them self-inflicted.
I navigated this kind of process successfully early in my career, and the only thing that made me more miserable than interviews like these was the work I got to do afterwards, after accepting the offers. Once is happenstance, twice is coincidence, three times is probably just how these things are -- I'm now pretty convinced that the quality of the interview is (barring statistical accidents) highly correlated with the quality of the actual position.
Can you give some examples?
I can give one example, I guess, since it's been a long time, it's a very common scenario, and this is an internal thing, so anyone who can identify it is either already there (tequila's on me this evening, mate) or has worked there before (I'm still up for tequila).
The buggiest component in one of the projects was the testing framework. It was a home-grown testing framework, incredibly slow (think "takes about 5 seconds to send a 20-character string over a 115200 UART line"), and it had a huge bug backlog.
Virtually all bugs got closed with WONTFIX. The person who'd written that monstrosity had made it up the management line, and his minion was now in charge of the team that allegedly maintained it. Since all sorts of bullshit metrics like bug fixing rate and total number of bugs and whatnot came up during quarterly operational reviews, a low bug count was nice to have. And since no customer ever complained of a bug in the testing framework, for obvious reasons, all that was required to keep the bug count to zero was an understanding between these two guys that all bugs would just get closed.
So you had to spend a few hours finding creative workarounds, since the two-line fix you'd come up with in five minutes would never get applied. And I mean creative. We had code that literally eschewed non-functional framework code by exploiting a race condition in its code in order to do RPC calls without going through the buggy framework code.
Now imagine you have to do something like this for every single task you do and you have a pretty good idea about how it goes. I mean you technically spend 100% of the time doing what you're supposed to do, but only about 30% of it is actually what you're supposed to do, everything else is mostly fighting cargo cult practices, senior engineering ego, and management disinterest.
I didn't study CS at college, and I've never needed to write a sort on the job, so I've only ever written sorts in job interviews! I think I worked out a basic bubble sort, and told them it probably wasn't the fastest way of doing it but that it'd do the job.
I also complained that google's coding solution (docs, basically) was a terrible way to code, other companies use coderpad or whatever, but I expect that Google will never change this. They love to hire people who are excellent at coding CS approximate solutions, but have little to no judgement on how to do good software engineering.
> I thought I was done, then the interviewer said she would go go copy my code and compile it after the interview to see if I was right, which blew my mind.
I've been interviewing at Google for nine years and have never done this. I generally don't think it's fair to ding a candidate for something I don't notice in an interview, where I'm at a huge advantage. If it looks right to me then that's good enough.
But that said, I have often asked questions similar to what you describe. You have to write code in the shared doc because hiring committees want to see it - fair to blame the process for that, but not the interviewer. I actually appreciate this for a couple reasons:
* It levels the playing field a bit, in the sense that code is more objective than an interviewer's notes on how a conversation went (especially for people who aren't native English speakers)
* I sometimes find that candidates who communicate well struggle to turn their ideas info code. Other times, someone's communication and solution are kind of average, but then they use all the little things I like seeing (defaultdict(set), zip, etc. in Python). Lots of people claim to be very experienced programmers; seeing how comfortable and fluent someone is when actually writing code is a strong signal. If you don't like the focus on data structures and algorithms that you haven't thought about since college, you should probably appreciate the coding part.
Like thats how I would feel writing code into freakin google docs during a job interview...with Google.
Tie 1 arm behind by back as the synax goes wonky, I'm fighting the spacing, etc. etc.
Or put mario Andretti into a ford focus, then test his lap times, with 0 warning.
Yuck.
That said, if a person is being considered for a coding job, wouldn't that person want to demonstrate their coding abilities? I mean, assuming they're actually good at coding?
In interviews, I much prefer a concrete problem to an abstract one, and coding problems are typically far more concrete than most other subjects covered in SW dev interviews.
If you're a world champion, you would probably enjoy an exercise like this.
This lady pilot sure did: https://www.youtube.com/watch?v=5KiC03_wVjc
If you are gonna require a candidate to write compilable code at least use one of the many tools designed explicitly for coding interviews.
I think I’d rather use straight notepad than google docs.
You may usually write code in a terminal based programmer's editor (vim, emacs, ...) and realise the code you've just written is not quite right. You want to delete the last two words. There's even a default and handy keybinding for doing that.
So you press ^W twice.
When viewed in that light it actually doesn’t seem quite as bad.
Except that writing code in a Google doc on the phone doesn't in any way resemble the real "playing field". I grant that it's level in that everyone faces the same constraints, but to write code in a gdoc with red squiggly lines underneath every keyword, automatic capitalization after a dot, and variable width font? How does that give you any kind of useful assessment? It's like handing a butter knife and some twine to a doctor and saying "here, show me how you'd stitch up this wound".
As someone mentioned in another comment, I also never had to actually implement a sort since I left university more than a decade ago. I'm happy to discuss the different types and approaches to how they could be done - as to evaluate problem solving, logic, and general understanding - but to actually code in an interview...
In a similar way, this week I even jokes on Twitter how I'm doing many improvements and refactors on a codebase, but there's the occasional 'how I do join 2 lists on Java again?' moment when I completely forget something basic.
It's pretty clever, I'm surprised Microsoft didn't try it (or maybe I was just too young to remember).
The best interviews aren't scripted but are created from around the interviewers expertise but based on the skills and qualities needed for the role.
Multiple rounds give you more opportunities to ask questions to multiple people and get a better idea of the company. They can also be a pain in the ass.
More often than not I give my spot to a more junior team member if they are available. So that they learn something from watching the interview as well as "just" see if the person interviewed would be a cultural fit. If they could imagine working with them.
> What's not in a Linux inode? > My answer was: Lots of things...dinosaurs, the moon...
You can answer that you want more clarification, or even answer that "we can google this".
The "dinosaurs" thing might make the interviewer feel that you are being unprofessional since the interview is to test one's ability to perform in a professional environment. You don't help your colleagues by answering in this way when asked similar questions in work...
What is in an inode, sure. Or why is the filename not in an inode. But what isn't in an inode is just a useless trivia question.
1) they are smart
2) therefore if you're smart you have the same way of thinking
3) also you have the same knowledge (and gaps!) about irrelevant details
Therefore instead of checking your knowledge they check whether you're like them.
It's just amateurish.
But many recruiters work as independent contractors or in recruiting firms. They often do a minimal phone-screen, vs sending a candidate "cold" to the hiring company.
The question is meant to be asked by a sourcer - a contractor whose list of requirements does not include being answer themselves any of the questions they ask. Famously even if you know the answer pretty well, say because you were the original creator of the thing, but answer in a way that they can't link to the answer key, you still fail.
Which is the most ridiculous part of it. You are being examined and evaluated over trivia in a subject that the examiner likely has no idea about and where there are only 1-2 possible "correct" answers.
That's like sending a janitor to "source" surgeons by asking questions to people in white coats in a competing hospital about appendectomy.
Yet this is considered effective (and acceptable) somehow ...
I tend to ask open-ended questions. Let them talk about code, and I can probably figure out whether they're full of shit or not. And a real coding challenge proves better whether someone can code than any code question or whiteboard challenge.
How is this fact not seen as a complete failure of hiring practices or company/team leadership?
Turns out upper management rates predictability quite high.
Note: that's anecdotal from a couple years of observation. I haven't looked into any Google-wide statistics (and if I did I would not blabber about them). But I'd be surprised if this was way off.
You will still be choosing people through a mechanical procedure, what is quite stupid, but it's less stupid than that way.
Everything above would make sense if the question was "what is an inode?". But it was "what is an inode not?". That wording doesn't make much sense to ask anyone, no matter how you spin it.
After that whole depressing charade was over, I figured it would be an offer or GTFO. Nope, I got called for another interview. I said "eh, no thanks".
I took great pride in the fact that my questions were unique. I designed them myself, about 30: some quick knowledge tests, some elaborate coding challenges, and everything in between. And for a given candidate I would pick about 6-7 questions of the 30 to ask them.
I didn't care if the candidate didn't know or didn't find an answer. I would entice the candidate to drop it and just move to the next question. Some candidates make it hard because they want to keep persevering, keep thinking, but there is limited time in an interview. As an interviewer, my goal is to (quickly!) find and evaluate what you are good at, not what you don't know.
> Some candidates make it hard because they want to keep persevering, keep thinking
Yeah, amazing that some candidates want to demonstrate their perseverance even in face of problems that they find challenging. Crazy right?
A candidate who spends far too long on a part of the problem without getting anywhere will get some guidance and nudging. If they take that on board and get back on track then that's great - they're responding to feedback and correcting course. If they remain too committed to their chosen approach and continue to struggle, then we've seen it with our own eyes.
At the end of the day, we're giving candidates the benefit of the doubt and recognising that, a lot of the time, it's their nerves that are doing the talking and you need to work with that.
And rest assured that I always made it very clear to the candidate that abandoning a question they are stuck on is best to maximize their chance of doing well in the interview. If I have a 45-min time slot to spend on a candidate, I don't want to waste 30 min on a single coding challenge that they do poorly on and have barely 15 min to cover other topics. If I get a sense they won't do well after 10 min, I stop it, move on, and that leaves us 35 min to do other coding challenges. I have more chances of finding what the candidate is good at in 35 min than in 15 min.
I don’t think you learned this style of questioning in interview training. Going off script like this uncallibrates the entire system. In fact, if I was your coworker, let alone manager, I’d recommend you for remedial interview training. This is not how you conduct an interview for any role.
... Is this part of the process? Questions made up by random person? That sounds absolutely ridiculous if you want any sort of consistency.
A casting is always stressful, they don't need me as an enemy as well. If they are not good enough with a ton of help, they won't be good enough period. If they are really good with a little of help, they can still be better than someone who needs no help at all. In the end I care about the final result, not about whether they grade well on some invisible scale that only I can see.
Doing a collaborative interview requires careful attention by the interviewer, but I agree it’s worth it.
I've definitely had interviews with solid candidates who just faced an early roadblock, but were brilliant after I gave them an early push. Sometimes that's more of a sign of communicating a question poorly or nerves than genuine lack of knowledge on the candidates part.
I've been doing a bit of technical interviewing and I usually try to help people along so they reach the "end" of the interview, especially if they're not doing too well. So many candidates sound defeated when they're struggling with a task and it's a form of respect for me. They've put themselves out there, after all.
Treating candidates - which you know you are going to reject at some point of the interview - with dignity is the right thing to do and can go a long way when it comes to your company's reputation.
Usually it is not hard to notice whether you'd like someone to succeed and then factor that in.
What about the opposite, that you don't like someone, or worse, you are indifferent to their success?
Maybe the hard part is to get a HR person that cares about the outcome instead of their authority.
Why should their interview be a stressful stone-walling event when life as an employee is not?
Maybe an interview should have "Who wants to be a millionaire" lifelines. Two "Googgle"s, and an "ok, I give up - give me a hint".
How does an interviewer ensure all candidates are offered help fairly and equally?
What is the purpose of asking a question, that if a solution is found after "hints" are offered, would be acceptable for hiring?
When they are unsure then they will usually ask about the problem or about how the problem should be solved (microservice, shell script, ...)
These are valid questions and you can turn them into more knowledge about the candidate by asking them what pros/cons they see by going each route.
Just like that I have actors that want to know more about the role and actors that need less guidance. In the end their performance counts. I will still try to give them hints inbetween takes (just like I would when we work together on the set) — but in the end it is their work which I will judge.
Unless you are hiring for a position where a dev works in complete isolation and receives no guidance whatsoever I think emulating the real thing is the way to go. And that usually doesn't entail holding a devs hand and neither it does entail not helping them at all.
does not seem trivial given the differing permission model, but not impossible either. for fat32 I wonder though if the total absence of permissions allows for that.
The question is still phrased terribly of course and the candidate would have to reverse engineer what the interviewer is actually asking to have a chance to answer it.
Were they considering you as an experienced developer of a Unix/Posix filesystem, who would almost certainly know what an inode is?
Or were they considering you as someone who had been using a Unix so long and extensively that you had a chance of once having had to configure an older filesystem for huge numbers of inodes. Or a chance that, for some rare reason, you once had occasion to learn that the `ln` command isn't always used in conjunction with `-s`?
In either of those cases, you might then guess at what the question was getting at, in a slightly clever way. If you got it, then both of you could share a bonding moment of both knowing this thing not everyone knows, and it could be a quick warmup to better questions.
Or, if you didn't get it, you could feel thrown off, and insecure or negged, which is also a win for an evil interview process.
If I'm feeling punchy at 3am, an alternative theory is that they could be a recent CS grad, who'd had a class in which they were told to recite, after the professor, "What's not in a Linux inode is the filename," and that's what they think is important about that. (By way of introducing the separation between inode and directory entry in Unix, through catchphrase and rote memorization. Other professors would probably instead explain using a diagram or the code for structs.) (Theory variation: perhaps the only professor who ever said this phrase was at Standford, which would make calling for it an especially transparent shibboleth for frat-like alumni affinity, and an overly-precise filter for socioeconomic class.)
The rounds don't build on each other. You have X interviews and the interviewers don't talk to each other and are independent events.
They have gone through phases of having an initial phone screen interview which is a hurdle, but the rest are(/were) as laid out above. There may be exceptions for very senior people, but they are sufficiently rare to exclude.
Google has it's problems to be sure - but by and large the individual people there mean well.
There does however seem to be a lot of criticism of FAANG interviews which seems immature.
That's to say it's information that is useful to have in your head if you're an SRE, just part of understanding Linux fundamentals.
That's not to say it was a good question. Despite my encounter with that bug in my code I still wouldn't have answered the question correctly. Filenames point to inodes, inodes point to data. The word filename might not even pop into my brain when thinking of inodes in isolation.
Also it doesn't show the full picture, I'm not at all sure I have what it takes to be an SRE let alone one at Google, that I sort of know what an inode is says nothing about if I can properly use that information to make architectural decisions.
At one point, why not just drop the pretence and ask "repeat back to me the algorithm on p. 343 in book xyz."
As programmers we always learn, we learn what we need to learn to do the job, there is no reason to reject someone because he does not know the answer to a technical question, but if you are not making the effort to know the answer in order to get the job, maybe you don't want the job.
They don't prescreen for candidates that will put up with a large amount of big corporate bullshit without fucking off unexpectedly, however.
I have just passed an interview for my new job and it was none of the above. Yet very technical, still very involved - but with competent people on the other side that were showing they are as interested in getting someone hired as I was in getting the job.
There were 2 interview calls in all (normally the second one would have been on-site but Covid ...).
No need for BS scripted questions, no need to ask trivia, there was coding test but on a computer (not paper) and nothing crazy you would need to read books or study for.
Is it perfect? Of course not. But that's why there is a 3 months trial period in the contract during which they can terminate the employee "overnight" if not performing satisfactorily.
That's a much better solution than trying to evaluate everything and the kitchen sink in an interview by asking trivia questions and wasting the candidate's time with reams of books to study. Which, in the end, evaluate only whether the candidate is able to cram for interviews and not whether or not they are actually competent at doing their job.
Yes, there are 3 months trial period, but Google will have thousands of candidates every week, they need to quickly filter them rather than evaluating them equally. Many people interviewing don't even know the job they are interviewing for, that's the problem of big organization.
So why do I have to re-prove this at every new job? It's not obvious enough I can learn if I've learned a programming language or framework in the past? Do companies have some brilliant insight into neuroscience where they know people become incapable of learning at some point?
Any 2/4-year degree should also answer that question as well. Lots of things can answer that question. Ridiculous questions are about the laziest way to test someone for it.
Granted, it was an automated email, but an automated "No" would have been more appropriate. Is it so hard to offer different standard responses? Why does the company consistently fail at human interaction, be it candidates or customers?
From my circles, most share the feeling that FAANG/MSFT are insulting for candidates (I can only speak for Google/Microsoft).
Like... yeah thanks I guess this degree and 5+ years experience isn't worth much. Such a broken process
A team looking for people with knowledge instead of looking for people to know how to reason is a team that is already dead.
Google is hiring 10's of thousands of engineers a year. It's really hard to do well. Most of the questions are deliberately scripted because they are known to be good questions on some dimension.
So... work with them. Most of them actually want you to do well. Most of them are smart. Some of the questions are an open invitation to just talk and show that you can behave like someone they'd want to work with.
Your answer of "dinosaurs" etc, while the result of frustration more than anything, just said to the interviewer "not someone i want to work with".
It sucks, but you have to know your audience.
When I did technical interviewing for my company for a period, granted it was still on top of my 'day job ' but I had the scope to get really invested in the process, and wrote guidelines for other reviewers. Treat technical interviewing as a respected role in its own right and not as a chore that interferes with 'real' work and it's a better outcome for all parties
The long and short of it is though - one has to face the reality of the situation they are in. If you go interview at Google (or any FAANG I would guess), you have to understand what you are in for and do your best to get through. Or, just don't interview there.
From my perspective as a candidate, it was fine (the interviewer was friendly and asked industry-standard questions) but I do wonder how it goes for companies that essentially outsource their hiring bar.
On the other hand, you'd need to be doing a lot of hiring to make it worth dedicating a software engineer to just interviewing people. Or you have someone who doesn't really understand code—like a recruiter—run the interview, with all the difficulties that creates.
TL;DR: hiring still isn't a solved problem.
I have been headhunted by them multiple times in the past. The last time their recruiter called me and explained me that after the usual screening and HR calls I would need to pass multiple increasingly complex technical interview rounds - and then THEY will decide on the role and project I am best suited for (if at all). I have flatly asked the guy whether they are being serious and turned him down.
To be fair to Google, though - their interviewing used to be first class. When I got into the first call sometime in the early 2000 or so, the interviews were difficult but with competent interviewers and no BS scripted questions. But that was because it was done in-house, I was talking directly to some engineer in Palo Alto over the phone. Even the HR lady was actually pretty technical and was asking me rather pointed questions.
Later on they outsourced it to HR agencies and it became "the process", with people being called over irrelevant/not interesting jobs (entry level sysadmin in Ireland once - even the HR guy on the phone recognized it makes no sense to call me over it ...) and the "we decide ..." at last.
However, Google is by far not the only company doing it. Microsoft's hiring process was very similar and Google's explicitly inspired many smaller companies or "less desirable" (for the candidates at the time) companies to ape this, thinking it is somehow a good idea.
This seems to be pretty much the norm in the tech industry. Along with attempts to effectively have the candidate redo all comp-sci final exams during the interviews - because "credentials can't be trusted", as someone told me.
Give me a break. It is high time tech companies should start treat (especially experienced) engineers with a bit of respect and dignity, we are not school kids anymore.
Well, he had a quota to fill so ¯\_(ツ)_/¯.
There are situations where the market can be spectacularly efficient. Outsourcing hiring to third parties is definitely not one of them.
In this case, big companies can afford broken interview process, because it's not their time that's being wasted, and the inertia of a big corporation can hide a lot of inefficiency.
As much as I dislike interviewing I totally agree with this statement. Almost none of my graduating classmates could write a fizz buzz and I wish I were kidding.
To this day I have NO idea what happened. I never heard back from them and the recruiter wasn't able to provide me with any further feedback when I asked.
I thought maybe they saw me on camera taking a photo of the Goldman-branded water bottle on the table while I was bored waiting... Or someone was digging and saw an anti-Trump tweet of mine. Or whatever.
Would have been more fun for me to turn them down after this whole madness (which I fully intended), but I didn't get that pleasure :)
When I got out and was on my way home, the recruitment consultant phoned me up and quite literally screamed at me for about 5 minutes down the phone about why I hadn't worn a suit. He didn't mention this interview requirement beforehand.
So yeah, weird things happen at investment banks :-) I didn't get the job obviously.
I can't think of a single other high-paying profession that pulls this shit.
I used to be a software developer and an architectural firm (that designs buildings). The architects plus engineers had to go through 5 years of college, do years of on job training, all before they can be licensed.
I felt kind of bad for them though because I made more then most of them before I was 21.
The interviews are crazy though. The last big company I worked at had a "probation" period. For Sr Software Engineers we would only do a single 1 hour interview. But if they did not do well in the first 90 days we could fire them.
Seems much better than telling people to study leetcode hours per day for 2 months prior to an interview.
I live in Los Angeles where companies never did this type of interview when I last got a new job (4+ years ago) so I had to grind LeetCode for several months then didn't get the job I studied for even though I got all questions right (I was a little slow on some of them). I kind of resent it because I know my time can be much better spent (keeping up on security topics for example).
The process is so bad it makes me hope to be no longer doing software development as a employee sooner than later.
Or the position was cancelled during the interviews.
Not every reason has to be personal.
My feedback was that, if the CV is so impressive, according to them, why do I have to endure such interview processes?
Anyway I never bought into the whole do no evil marketing, nor bothered to apply, if it wasn't for their HR reaching out to me in first place.
Based on perhaps a dozen intervies here and there I had the conclusion that recruiters have no idea who they are going to employ but practically draw a name from a hat (after filtering out obvious incompetents, if at all). This includes the position I won, and those I did not.
In one occasion I refused a fairly well paid and interesting job because they tried to measure my competence by performing quick basic calculations (related to financial topics), giving impossible amount and urging as many answers as possible. Being an engineering development position it was hopelessly incompetent way to test, which they intended to be the base of future promotions and assignments of roles too. They claimed it is for the sake of fairness, testing every employee equally, regardless of the role. How supid is this for god's sake?! Roles and expectations of the roles are different and cannot be tested the same way. It was just lazyness from the HR, pure lazyness to rely on robotic methods. Robots from the HR (ironic calling themselves !human! resources) pushed through incompetent methods. Destroying fairness under the flag of fairness, crazy. I considered better not be engaged with such an organization.
which is not even true in some file systems that can inline data directly into the inode, if the data is small enough.
for the downvoter(s):
> If the data of a file fits in the space allocated for pointers to the data, this space can conveniently be used. For example, ext2 and its successors store the data of symlinks (typically file names) in this way if the data is no more than 60 bytes ("fast symbolic links")
> Ext4 has a file system option called inline_data that allows ext4 to perform inlining if enabled during file system creation. Because an inode's size is limited, this only works for very small files
This means the name of the file the symlink points to. It's not the file name of the symlink itself.
but they are both paths in the end
That's a pretty low bar. A Fizzbuzz test culls more bad engineers than good ones.
What happens to the 3 that get rejected, do they try again later and filter through? Or do they tire of the process, give up, and work for competitors?
The experience was so bad that afterward I sent a lengthy email to the recruiter thanking her but pointing out I expected to fail the interview because the interviewer insisted on things that were wrong or irrelevant and set out why as a courtesy so they could address it for the future.
I was rung up and was told the recruiter had gotten the interview set aside, and offered to just have me bypass the technical interview and wanted to move on to an interview with the hiring manager.
In the end I declined, as the first interviewer would have been one of the people I'd have managed, and I just did not want to deal with a team with a person like that, and the whole process was just excruciatingly slow to the point I had offers on the table before they could line up an interview.
It seemed to be a process optimised for people who either desperately want to work specifically at Google, or doesn't have alternatives.
I kept getting calls from Google recruiters for years after that and kept recounting my past experience and asking if they could provide a better experience this time around.
I have had worse interview experiences than Google, including one where I halted a phone interview halfway through and told them they'd shown me I didn't want to work there, but Google is pretty high on my list of places I'm not particularly interested in interviewing.
Oh, I can totally empathise with you because I've been there. I applied for a position which was the head of a team and a future direct asked me esoteric statistical questions from his PhD thesis. I did quite well to answer most of them but he wasn't impressed.
Wow, even if you were hiring filesystem experts to write filesystems I think there are a million better ways to ask that question.
e.g.: "Hey, talk me through the design of a really basic filesystem, it needs to support hardlinks, symlinks, files and directories."
If the question is too vacuous surely you ask for clarification -- "well, what happens when you issue the 'mv' command" -- and presumably if you designed file systems you can talk about different implementations, optimisations, and problems crossing filesystem boundaries or whatever.
- It's unclear what they're trying to judge. Do they want to know if someone understands filesystems on an intimate level? Do they want to know if someone knows how hardlinks work? Do they want to know if someone knows what fstat returns? Are they trying to trick someone since an inode in many contexts is just a number? This is an unnecessary level of uncertainty for a question and encourages random tangents which may not be the answer the interviewer is looking for or cares about.
- Someone who has studied google's standard questions which this apparently may be one of [1] would be able to answer this without understanding the implications, what does that tell you about the candidate?
- If you want the candidate to go into a tangent about filesystems in order to figure out how well they understand them, this is as mentioned before a really stupidly open ended question.
- If someone did understand you were talking about inodes, they may be of the opinion that the inode contains a reference to the file's contents and as such contains the file contents. In the case of a directory this means that an inode "contains" the file names of files in that directory. This makes the question a leading question which is trying to lead to what would be a wrong answer from that person's point of view. How do you answer a leading question when you disagree with what it's trying to lead you to?
If you want to determine if someone understands filesystems on an intimate level. I think my question would be far better at elucidating that.
If you want to understand if someone knows how hardlinks work, I can't come up with a question off the top of my head but I doubt that "what is not in an inode" is anywhere close to the best one.
If you want to trick someone, go ahead, this is a good question. Likewise if you want to screen for people who have googled "Google SRE Interview Questions" and memorised the answers.
[1] http://www.gwan.com/blog/20160405.html ( https://news.ycombinator.com/item?id=12701272 )
Regarding the above reference:
I've spoken to someone who interviewed for an SRE position and she said the questions were very similar to an early phone interview she had. She said the interviewer did not know what they were talking about and were just going off an answer sheet. So I don't think the interview in this case is representative of one for a Director of Engineering but is representative of an early screening interview for SRE. In which case anything BUT the expected answer to the question "What is not in an inode" would be considered incorrect.
It is still a pretty poor question, I remember getting a similar kind of question when I passed through the (at the time, in Sweden) mandatory conscription testing, where you are tested for which role you best fit as a military conscript.
One question on the intelligence test was: "What is heaviest, gasoline or water?". I did not know how to approach the question, I had not memorized the density of gasoline and I didn't think an intelligence test could have assumed that either. I was stumped. How could that be an intelligence test question? Only afterwards did I realize that the test creators probably assumed that knowing that gasoline floats on water as common knowledge, and if you were intelligent enough you should be able to derive the answer from that. I think the inode question is similar.
It depends on the amount. Two pounds of gasoline are heavier than one pound of water.
Yes, I get that they are asking about density, not mass. My point is that tests need to be carefully written. I remember once during an early online screening at a multinational they asked something like
Alice went shopping in the morning and bought apples. What did she buy?
A) Apples. B) Oranges. C) All of the above. D) None of the above.
With the information provided, the only answer we can reject is D, because we know that she did in fact but apples. However, it is possible that she also bought oranges (and/or something else), in which case answers B and C would also be correct. We don't have enough information.
Bear in mind this was a test for recently graduated software engineers, who are supposed to be trained in logic, so I spent a few seconds puzzled wondering why the question was worded so strangely.
I did answer A and moved on.
I see what you did there
What makes the question bad is that nobody can guess what answer he wants, and anything else, as correct as it may be, will be understood as a mistake (what is evident by the OP's answers that were perfectly correct).
"What number am I thinking right now" may be a really strict question that fails your expected number of people, but it's not a good interview question.
I am actually just curious as to why this would ever even be a thing you come across unless dealing with filesystems directly?
In fact the only reason I know anything about inode and dentry specifics is because they are 'very clever' interviewer favorites! I've been a professional UNIX admin for 15 years and I've dealt with inode issues literally once in my life lol
I have even read books on linux architecture and remember discussions about filesystems and inodes and remember the general structure and form, but a detail around what is and what is not stored in the actual inode... seems like an absurd detail to memorize.
The only way I could see this being commonplace is if I somehow missed out on a widespread bug that somehow caused inodes to be corrupted and requiring manual intervention/surgery to prevent data loss.
Hard links can be a somewhat notorious footgun due to this by the way; with a soft link you know you're only deleting a link, but with "rm hard-link" this is a bit trickier: if you think there's another link but actually, it turns out you made an error and there's not then you've lost that file. A "hard link" isn't really a thing on its own: it's just another reference to an inode. This is why symbolic links are used in most cases, but you can hard links are still used from time to time in e.g. /bin and some other places.
1. With senior or experienced developer, it is usually pleasant and respectful and they are open to a diverging answer if it is justified.
2. Some of these companies either have an inexperienced person in a senior position or delegate it to an inexperienced developer to do the initial filtering.
3. Inexperienced people are extremely painful to interview with, they have "accomplished" something in their current/previous job but do not realise there are better ways than that. Sometimes it might just be an opportunity to reinforce their own confidence (imposter syndrome).
Is there a curated list of simpler, more human, more efficient for both parties, companies ?
It means the sort of people for whom Golang was designed.
Egos are the worst parts of humans. A lack of sense of humor is a personality or character flaw.
But a clever candidate assesses "is this a good employer?". Even during the hiring process.
A lot of those interview questions just seem to test for "how good is their memory", which I don't think correlates to future performance very well.
Curious if you happen to remember what any of those books were.
“Programming Interviews Exposed: Secrets to Landing Your Next Job"
Authors: John Mongan, Noah Suojanen, and Eric Giguère (Wiley Computer Publishing)
"Programming Pearls"
Author: Jon Bentley
"Introduction to Algorithms"
Authors: Cormen, Leiserson, Rivest & Stein
I was a recent grad, around 10 years ago. A Google recruiter called me out of the blue. After a couple of minutes, she started asking technical questions about Linux, which I had just started using.
After a while came the final blow: I was asked what was the fastest way to sum two integers (there were probably some additional specs I don't recall).
I mumbled something. Wrong! The answer is, in fact, using the TLB. I vaguely remembered what the TLB was from my CPU architecture classes, but was aghast at the connection between that and summing two integers.
The recruiter pretty much said I wasn't Google material on the spot and said goodbye. I felt bad for myself at the time, but now I can see this is a ridiculous approach to interviewing.
And thirdly - because it's a proxy for intelligence by people who think they're smart for having memorized sorting algorithms.
Who wants to work in a place where people who memorize things are conceived of as smarter than people who didn't memorize the same thing at the same time interval (i.e. cramming before interview or just out of college?)
Fuck those places, I'd rather work with human beings.
In the real world, you cannot remove risk. You can manage it, but you cannot remove it. Asking candidates to go through 6 interviews before making a decision and not telling them when a decision will be made signals a risk adverse culture that cannot make decisions.
The best teams embrace and level up their low performers and make the whole team better.
The delta can’t be too big.
The company doesn’t have to prove that the employee was failing. It’s perfectly legal for a company to fire an employee because they the employee likes the wrong football team.
The employee or people pursuing legal action on behalf of multiple employees has to prove that the company fires the employee(s) because they were a member of a protected class.
Assuming there are no incriminating emails stating that that was the reason, the only realistic way to do that is to show a pattern.
If an employee decides to sue, whether you had them on a documented performance improvement plan for 6 months or 6 days isn’t going to be the deciding factor.
They do if the employee sues claiming age discrimination, for example. At least, they have to defend the accusation to show it’s not discrimination. When someone has been at the company for 25 years like in the parent’s example, and they get fired abruptly without notice for liking the wrong football team, it’s likely the stated reason is untrue and inviting a challenge.
> If an employee decides to sue, whether you had them on a documented performance improvement plan for 6 months or 6 days isn’t going to be the deciding factor.
It certainly helps show that the company isn’t discriminating arbitrarily, and gave the employee notice and a chance to improve the situation.
BTW actual legal action isn’t necessary for firing to be getting harder. The fear of legal action is all you need, and that is in fact going up.
They don't have to show anything. The employee has to prove that it's age discrimination.
>When someone has been at the company for 25 years like in the parent’s example, and they get fired abruptly without notice for liking the wrong football team, it’s likely the stated reason is untrue and inviting a challenge.
Without a pattern of discrimination this isn't a problem. If there is pattern of discrimination then it is. However, if that's the case it doesn't matter how much documentation they have.
>It certainly helps show that the company isn’t discriminating arbitrarily, and gave the employee notice and a chance to improve the situation.
You can't discriminate arbitrarily. Discrimination in this context means firing someone because they are part of a protected class.
>gave the employee notice and a chance to improve the situation.
Whether you gave someone the chance to correct the situation or not isn't relevant.
>BTW actual legal action isn’t necessary for firing to be getting harder. The fear of legal action is all you need, and that is in fact going up.
The number of charges filed with the EEOC has gone down over the last 20 years https://www.eeoc.gov/statistics/charge-statistics-charges-fi...
https://www.natlawreview.com/article/eeoc-roundup-part-i-10-...
"At the same time, FY2020 saw the lowest number of charges received from workers in more than two decades. The agency received 67,448 charges—continuing the steady downward trend since 2017 in the numbers of discrimination charges filed with the EEOC."
Yes that’s a compelling data point for decreasing legal actions (and it’s interesting, thanks for including it), but not all actions and not all fears end up in front of the EEOC, right? This data point alone is likely due to decreasing union membership over the last 20 years, but is also explained by the increasing prevalence of mandatory arbitration clauses. What it doesn’t explain is why HR departments nationwide are increasing efforts to educate employees about anti-harassment policies. If they are legally in the clear, why is that happening? Twenty or thirty years ago it was hardly a thing, today it’s the norm.
> They don’t have to show anything. The employee has to prove that it’s age discrimination.
You are right about the legal burden of proof in court, absolutely. Court isn’t the only possible outcome of a discrimination claim, though, and the one specific example you gave is a defense against a discrimination claim that would not hold up in court (firing a long-time employee for claiming to not like the right football team).
I agree with everything you’re saying about what is required in court, and what are the legal rights for all employers in the US, not just tech companies. That’s just not exactly what I was talking about.
Honestly, I don't have a good solution to the problem.
In the past I would never have been interested in a contract-to-hire. These days though if the company and role is right, and this an option to short-cut a ridiculous interview process, I might spring for it.
When I was an actuary we used to do “intern to hire” for unemployed recent grads, but I can’t imagine leaving a full time position for a contract-to-hire position. I think for me personally the opportunity would have to be really interesting and the comp upon converting to FTE would need to be at least double my previous comp (meaning the contracted rate would probably be something like 4x my implied hourly).
I've see that work before, but it was some time ago. The company also had a very large test department with separate management and kept to a strongly enforced waterfall-esque design routine.
Of course, it used to be a lot harder to ship out version 1.01 of the software.
I just assume it was a different world as this was in the days of US manufacturing, very limited set of software tools, high importance placed on domain knowledge as opposed to toolset, longer average stays at employer, lower wages for programmers. Probably not applicable to modern times.
There's a quality-distribution of both books and films.
There are only so many good books. And a percentage of films end up poorly made.
Sufficiently low-quality books tend not to get made into films. The ones that succeed are notable --- there's nothing but upside.
A good book can be made into either a good or a bad film. If it's a good film, then yay, but if it's a bad film, people are aware of it (through the book's quality and popularity). This is a perception illusion called Berkson's Paradox. It's an illusion because what awareness fails to account for are all the bad films made from bad books.
Hannah Fry of Numberphile does a much better job than I of explaining this: https://youtube.com/watch?v=FUD8h9JpEVQ
In the interviewing / performance case, you have good vs. bad interviewees, and good vs. bad performers.
Someonehone who interviews poorly but performs well is a positive exception. Someon who interviews well and performs well meets expectations. It's the good interviewer/bad performer who stands out. But it's the poor-interviewer/poor-performer who is missed by this assessment.
The problem is management are often too busy or overwhelmed with other stuff to observe and provide feedback until someone's passed the probation period then releasing them becomes a bureaucratic nightmare - and when the new hire's not getting feedback, you can be sure not a lot of the rest of the team are.
I've never understood this given that the hiring is so often at will.
It's a huge risk on the other side as well. Not to mention that management usually gets to control the narrative and not the employees.
I finished the 7th on-site interview. After I left NYC and flew back home, they wanted a 8th ( phone screen ) interview because one the interviewers lost the results.
On the one hand, this space’s modus operandi is more data is always better.
On the other hand, they have to trade and make decisions in a fast paced environment with imperfect information.
yeah, no. You dodged a bullet with that one.
Probationary periods could work but it's a coordination problem. Such periods are the norm in Europe (coz it's very hard to fire someone) but for an at-will place like the US, given that the industry doesn't really do probationary periods in general, any employer who starts doing it would be at a disadvantage.
In the sense of offering signing bonuses for term lengths that get repo’d if the contract length is broken.
While I agree interviewing has gotten ridiculous with all the leetcoding and ten rounds of interviews and FAANG cargo-culting and whatnot, one small advantage - assuming I'm not desperate for a paycheck - is that it gives me, as a prospective employee, time to consider and withdraw my application if I see too many red flags or I just prefer the devil I know.
A short interview process with a probation period on the other hand is a big roll of the dice. Maybe I'm not able to ramp up on time, or make a silly mistake due to unfamiliarity with the codebase or underlying business logic. Maybe I don't get on with the team or manager. Maybe I'm going to be dumped into a doomed death march project on day 1. I could find myself unemployed a month later with an embarrassing gap in the resume. Perhaps on the other hand a better interview process (not longer, just have properly trained people and constantly improve the process with feedback) would save us all that pain.
All the while, productivity suffers as the remaining team falls further behind due to short-staffing and being pulled away from their real jobs to interview.
> In general, people leave their jobs because they don’t like their boss, don’t see opportunities for promotion or growth, or are offered a better gig (and often higher pay); these reasons have held steady for years.
And if it is about money, then this is called paying competitively.
But lastly, recognize that if everyone is training employees you're still not really losing out unless you're only hiring entry level employees. Sure, you might be training someone that leaves, but so does your competitor. But if you're only hiring junior engineers then you're probably doing something wrong that's much bigger.
Out of curiosity, what sort of "non-monetary" benefits were you thinking about? There's usually not a reliable way to turn (small amounts of) money into the sorts of things that really build loyalty.
If an employer does do training, it means they'll probably continue to do more training over time, which helps the employee become more valuable.
If the employer doesn't do training, yes they may be able to allocate the training budget to salary, but they are not going to spend anything training you or letting you work on projects to increase your skills while you're there, unless they absolutely must.
I think people also have some human perception of how they're being treated, and prefer to work for people that invest in them.
Sometimes they leave. By that time they've used what they've learned and passed some of it on to the next person.
I don't know what it is but I feel like people have forgotten just like basic truths about how humans work. Maybe it's because managerialism has infected everything.
Even still, it’s obvious that comp alone isn’t enough to retain employees. Even FAANG companies, which pay extremely well, have pretty low retention numbers. Facebook does best here, at an average job length of only 2.02 years. If comp was enough, people would stay there longer. This implies that people are changing jobs for reasons aside from “this other company will pay more”.
Even if some of them genuinely get promoted before they’re ready and wash out, you’re not really that much worse off than if you’d lost them before. Besides, there’s always the risk that your new hire is unprepared too, which is a much harder thing to quantify.
Losing people who are experts within the domain of the software they're maintaining because you refuse to invest in them is going to cost you thousands of dollars... the only question is whether that's tens or hundreds times that amount... and in some cases it can cause you to lose your entire business.
Basically there’s two types of efficiency, investment efficiency and allocative efficiency. (There may also be other types I don’t know about.)
Investment efficiency means people are incentivized to make positive-expected-value investments. Think about how people are incentivized to invest in their house, e.g. preventative maintenance, because if the expected value is positive then they will recoup that value when they sell the house. If you’re renting you don’t have this with respect to where you live - water damage or no, not really the renter’s problem. Investment efficiency is maximized by private property, where you know that no one will take your property without your consent.
Allocative efficiency means things go to whoever is willing/able to pay the most for them. Renting does have this property - if both of us want to rent a house, and I’m willing to pay more, in most cases I’ll end up getting the house. This is why gentrification can cause displacement - when wealthier people come into a city and are able to outbid the current renters, they win and the current renters lose. Allocative efficiency is maximized by auctions and things like them, where the good goes to whoever is willing to pay the most.
Bringing it back to your comment, job training isn’t worth it because our careers as programmers are dominated by allocative efficiency, not investment efficiency. If you can train a programmer create $50,000/year more value in general (i.e. it’s not training that would only be useful to your company), they can now get paid about that much more from any of your competitors, and you will have to pay them about that much more to stop them from leaving. So you gain nothing from giving them general-skills training.
Another way of solving this problem is with sectoral bargaining. If you have a sector-wide union, they can make all companies start training simultaneously, or assume some of the costs themselves. It’s a win-win for the industry and for the programmers, but it doesn’t happen nearly as much as it could because of that coordination problem.
The union is ensuring that no company can ruin it for everyone.
But it makes Reginald the investor angry that his ROI isn't exactly 20% each quarter, so they jettison apprenticeships and start cooking the books to make that possible.
I had a kind of career crisis/breakdown, where I realised no one gave a shit about anything except my utility as a walking set of tech keywords. Accepting that it wasn't working for me was one of the best things I've done for my career.
It's that I firmly believe that there's more to software dev than just knowing a 'stack'. And even then, fair enough if they were curious about my .NET skills. But them asking about specific versions of .NET core really woke me up into how much of a commodity labourer they were trying to turn me into.
Many software engineers have accepted that they have to continually learn and will do so.
This process though, makes it impossible to know what to learn with an impossible random and unknown credential set. It's not the same as something like elevator attendants having an obsoleted skillset. It's a combination of not having time in a lifetime to even try to specialize in the random employer chosen skillset. When instead, employers should expect a good engineer to adapt quickly and employers should also commit to training staff.
At the risk of suggesting you might be dating yourself, I think this is an outdated model. It's simply no longer realistic. I personally believe that having personal expectations of what my adversaries or those outside of my control "should" do will inevitably result in sadness on my part.
Corporations will aim to do what they must to increase profits (given, by definition). Any additional assumptions from that are liable to be faulty. Perhaps you are used to the times when they needed to train staff but that's simply a symptom of the circumstances as opposed to a duty.
- going on $JOB_BOARD
- sending out CV & Cover letter
- talking to recruiter
- going to 3 interviews
- rinse and repeat
Wasn't working. I was not in demand. I had to constantly reach out to people, just to get interviews at places I didn't really want to work for. And even then they'd usually reject me.
It was a wake up call that I was on the fast track to nowhere, and something had to change.
Ended up specialising in an industry and doing contract work. I'm not super successful yet, but there's a lot more interest in me. My work days are much less frustrating and I'm earning more.
I am genuinely asking. Why is this objectionable?
Why do people find it so horrible that their labour is a commodity? To me that just tells me I should treat my labour like a merchant treats his goods. Always be checking the market to ensure you have something worth selling and while you might sign long term deals, periodically check for the best price to ensure you are getting it.
Why is it important to you that your employer view you as a person?
Because we, generally speaking, are people and not robots ;)
That being said, I agree with your point : people would have less issues if they just felt happy about whatever makes logical sense. That's just way too hard to live by for most people.
The answer to the question as written is...of course people want the entity that has outsize influence on 40 hours of their week to view them as a person instead of a mindless cog in a machine. People get treated better than cogs. Workers want their working hours to be as pleasant as possible, which is much more likely if your employer sees you as a person.
Is that really surprising to you?
Needs can include a nice workplace and you can negotiate specific details about what that means to you. I did not mean to say that it needs to be money.
You're not describing an employee, you're describing a consultant. Not everyone wants to be a consultant, particularly since most people don't get any training in it before they have responsibilities. If proper entrepreneurship was a subject at school, then maybe people would be willing to be their own business, but that's not what the system creates (or wants).
Fair, I can see why this might bother people. I don't think job security is a thing (career security perhaps), but I can get why its absence would be disturbing.
> expectation to be wading through the job hire swamp every couple of years.
The high level of turnover in this industry indicates that people at least tolerate it. The only people I know who make it 24 months in a role are chained by stock options.
This would all be fine, but no one writes ads saying what they actually need or what they're trying to do.
It's not about being viewed as a person. It's about being viewed as a professional.
Good organizations hire talented and bright people with mastery of CS and SWE fundamentals. Bad organizations think "oh we use Java, better hire Java programmers". Really bad organizations think "oh we use JUnit, Spring Boot and IntelliJ, better hire people with experience in JUnit, Spring Boot and IntelliJ"
One of the strongest signals of how good an engineering organization or a tech team is how few specific technologies they list in their job ads.
I'm not even an exceptionally talented programmer: just a competent one. Of course there are real differences between languages that matter, but at the end of the day ifs are ifs, ints are ints, functions are functions, etc.
Relevant old joke: https://www.reddit.com/r/ProgrammerHumor/comments/4k994j/if_...
That said: there are some reasonable scenarios when you want to hire someone with prior experience; for example as a first or second hire it's probably a good idea in most cases, or if you really need someone who can hit the ground running.
Case in point: a Stripe job listing I picked at random
https://stripe.com/jobs/listing/backend-api-engineer-core-mo...
No single language is named! And this specific sentence is a really great sign (unsurprisingly)
“Languages can be learned: we care much more about your general engineering skill than knowledge of a particular language or framework.”
I think that in the specific case of Stripe, they specifically mostly use Ruby (from answers I found online). I may be wrong, but I assume that not mentioning Ruby is a way to attract Python/Go/C/etc. developers that might otherwise think that since they don’t code in Ruby, they shouldn’t apply.
Your main point (re: Java) remains of course.
"We mainly use [language X], but you don't need experience in [language X] for us to consider your application" - this is a totally normal thing I've seen in many job postings.
Stripe is sometimes more explicit about it:
https://stripe.com/jobs/listing/infrastructure-engineer-ruby...
"Our most popular language in the company today is Ruby, and we are building a new Ruby services practice in support of this."
... but that job is also an openly Ruby-centric job.
You can't just go around telling people that: you are going to make hiring harder once everyone figures it out!
When you get a referral for a 10x and you're meeting at Blue Bottle you need an ice breaker; clueless community-college tier HR asking for versions of frameworks makes for an excellent one!
It doesn't matter :-) such organizations aren't good at finding out if someone is "talented and bright people with mastery of CS and SWE" in any case
Learnability is totally ignored.
It is terrible for inexperienced developers eager to learn on the job as is common in other industries or was in ours in the past.
It's terrible you're an experienced developer that is able to pick technologies quickly, or just wants a proper work-life balance.
It is terrible for developers who are deeply familiar with the technology but expect to work with a team of professionals, rather than with "walking set of tech keywords".
Software engineering is at a schizophrenic point where it is very hard to categorize in either of traditional "blue collar" vocational job (given people seem to be employed close to very little formal schooling) or as a "white collar" professional job (given some roles need a CS degree level understanding of the fundamentals).
Some roles are more the other than the other.
I'd say listing a very specific tech stack signals the employer is looking for "blue collar" "commoditized" labour.
White collar "professional" types probably feel treating their contribution as "commoditized labour" is a category error.
The majority of useful education comes from mentorship and on-the-job experience. Sure, you can get a formal education, and sure it helps, but it doesn't make you a useful software engineer. It just gives you a foundation to build upon through mentorship and experience.
In GP's case, the arbitrariness originates from their potential employer not taking the effort to really evaluate GP's relevant skills in software engineering, but instead resorting to lazily ticking boxes on a checklist. And what's on the checklist isn't even particularly relevant.
What I imagine this does to GP's view of the world (based on what it would do to mine) is: "I believe I am competent because I've built up a set of subtle skills in software engineering over many years, and this is what I take pride in. But from an employment point of view, this is wasted time: I should instead have focused on optimizing the checklist (and I only found this out after years in the industry)."
If what you mean is that it can be rewarding (intrinsically and extrinsically) to think about skill, craftsmanship, and other ways to make your labor a great value add, sure. Most of us benefit by thinking about that.
If you're really asking about why keywordification is a problem, well... keywordification of job roles indicates a way in which companies are quite possibly struggling to actually model the roles they're hiring for and identify what makes make an individual productive within them.
This happens on at least two levels:
1) Technological. Engineering decisions are sometimes "we have a specific problem, specific tech is the solution to our problem, therefore we need expertise in specific tech." In that case, the keywords regarding that tech are meaningful. But for non-trivial use cases, engineering problems are very, very rarely just that, they're commonly the aggregation of off-the-shelf + consideration of how to mix them with what tradeoffs + in-house custom solutions embedded in an organization attempting to understand and model its domain problems and fit/reshape all those solutions to those models. This is not exactly a keyword-driven process. Keywords represent the shallow end of the pool.
2) Human. While labor clearly is something bought and sold on the market, even from a point of view of a value system which is OK thinking of humans primarily as industrial inputs, it turns out that's a significantly leaky abstraction and most of us have all kinds of "compiler flags" or other inputs of our own that make us more or less productive. Some might consider this to be too warm and fuzzy; they might find it comforting that it can be approached from as a-humane and manipulative point of view as one might approach tweaking a database to get it to perform better: https://www.youtube.com/watch?v=HkFztAgK-8U
As for whether it's OK to think of humans primarily as inputs to any process on a moral level... like Terry Pratchett's character Granny Weatherwax said “Sin, young man, is when you treat people like things. Including yourself. That’s what sin is.” What are the consequences when social institutions consideration human beings primarily as inputs to institutional purposes? Generally, individual life, liberty, and pursuit of happiness become valued less, and individual suffering is more freely disregarded. Not super desirable under my value system. YMMV.
How did you pivot after this?
It's a contrived example of course (particularly if the end goal was just to check the "knows feature X from C# 8" box!) and I wasn't at those interviews so I've no way to know what their intent was. I'm occasionally on the other side of the interviewing table though so I'm just trying to reason through why this might come up. FWIW I hate the "what isn't in a linux inode" type questions, or situations designed to fuck with the interviewees.
"No, I'm not familiar with this, but I have done [market themselves, mention relevant experience, ask relevant questions] and I'm confident I can get the job done"
First probe is if the candidate doesn't have slightest clue what version they were using, that's a big red flag. This is more common than you would believe.
Second probe, candidate knows, but they only used a 25 year old version (also more common than you would believe when it comes to c++), this can be a warning flag that they are not interested in learning new things. But doesn't have to be if it was company policy, which is also interesting if they were in position to change this.
Third probe, ask follow up questions on differences since version N-1, this shows if candidate is staying up to date with latest trends or not.
https://clairehu.com/2014/02/18/a-little-bit-of-slope-makes-...
At least a few years ago, Google made it a point that the interview process was generic, not specific to any position or team. More like an undergraduate admissions process.
I read your comment and I was thinking in my head...wow, five seems like a lot, and then I realised that even these places I liked went pretty hard...I think they call this conditioning.
I didn't get either job btw, the work was trivial but I get terrible interview nerves so tanked both of them...in both cases, I also had a 6-hour take home...the results of which were largely ignored. Neither company is ever fully staffed...ofc.
If I talk to HR on Monday, take a phone screen with an engineer on Wednesday, and come on-site (or Zoom now) with 4 engineers next Monday, that’s 2 rounds and 5 interviews (or 3 and 6 if you count HR)
My experience has been that if you clear the engineering phone screen the company asks you to go through all the rest of the (4-6) interviews, even if your performance in one or more of them has been sub-par. And at least here in India the post-screen interviews are spread out over several days to 2-3 weeks - there is no "onsite" as such, even over Zoom.
This is going to become more and more common though. In fund management, there has been a huge move towards "professionalisation"...which, ofc, means doing lots of pointless exams that select for the wrong thing. MBAs are the same. It is very hard to solve because the system selects for people who will play into this self-image (in my experience, this isn't solvable...you can either handle the risk of being wrong or you can't).
This also overlaps with a lot of the issues that a lot of companies are having with hiring. A company which frames hiring as a risk rather than opportunity and has these very long, negative process of hiring (be real, the point is to uncover "weakness", not learn more about someone) is going to fail to hire people of different backgrounds. The amazing thing about the "candidate shortage" is that it isn't more severe. Companies are so bad at hiring, it is surprising they end up making any decisions at all.
Instead I think companies, especially large companies where small numbers of employees aren’t a massive proportion of spending, should try to see the potential for upside more. Especially in a world where everyone does a similar interviewing process, a candidate who performs poorly at those interviews could be cheap and an excellent hire who is undervalued by the market because of their poor interviewing skills.
By the time we got to the end of the process I'd already concluded that the hiring process was a reflection of their internal decision making and that this was not a company (or department) I wanted to work for.
Then I was hired elsewhere and I saw something similar happen to a candidate and realised that this was truly an indication of the indecision. We had lots of roles, just none shaped in a way that fitted the person, and what we should've done is reject the person but on that occasion we hired and it was a terrible decision. They were a good person and very capable, but not a fit for the role finally offered. I had the sense that if I had accepted the Amazon role that would've been true for me too.
An interview process of more than 3-4 defined steps that takes longer than a month to schedule, is a bad sign.
Top tip for candidates: Ask what the process is, if they cannot conclusively tell you then double down on interviewing at a company that can.
Edit: Meant LP's. Leadership Principles.
I've known a lot of far better engineers than I am. We've all been in this game a long time. Titles, companies and package aren't the most important thing to any of them. I'm sure most will look back and even though our titles and roles appear to have changed it feels like we still do much the same as we always did, just at a different scope and what's important is whether the work is engaging, there's as little politics as possible, and you're setup for success.
The more people who interview, the more average the candidate has to be to succeed.
For all the talk of "hire fast, fire fast" the reality is that most companies do not know how to evaluate someone within the probation time period in which they could let go of someone with ease (usually under 60 days) and after that they then fear doing so even when it's miserable for both the person (candidate) and team involved.
I hire a lot, and some of my thoughts on the process:
1. The interview process should be short and sweet. 3 steps is enough, if you can't make a decision in 3 steps then the decision is to decline.
2. The hiring manager should be the first to interview. We have a good idea of what we're looking for in a team and what other roles other managers have open, we can speak of most teams and can spare both the candidate and ICs from interviews that cannot realistically result in a hire. Likewise, we can increase the chance of a successful hire by having the people from the team the candidate would be joining conduct the interview.
3. Some of the best candidates get love/hate feedback, a candidate who consistently gets "hire" feedback is seldom as good as those who get "strong hire" mixed with "no hire" feedback. The consistent "hire" usually typifies an "on the fence but don't want to take responsibility for declining so will wave through"... opinions should be stronger, interviewers should be excited for people - challenge whether a consistent stream of "hire" feedback actually means "hire". All that said, always listen to "strong no hire" when it turns up.
4. To increase diversity you only need to interview people who aren't already over-represented in your org... you will hire those people at exactly the same rate as you hire everyone else. If you don't have these people in your pipeline you have a sourcing or branding/reputation problem so focus on those things. If you do have those people and aren't hiring at the same rate, you have a bias problem and should root it out with urgency.
5. Degrees are not a signal, so absence of a degree is not a signal.
6. Don't hire based on what someone has done as it only reflects what their employers asked them to do, instead hire on what they can potentially do - if it lines up with what you want to achieve it's a win-win.
Most of the above can be summed up as: Have an opinion and care about what you're doing.
Is this a thing? I would certainly judge a company doing this, and likely leave a manager who hired someone with an expectation that the beginning is just a probationary period, if I’m understanding you correctly (I hope i’m not).
Leaving a safe job for a probationary period puts too much risk on the employee that the employer doesn’t really share.
But I choose not to work for those companies, instead I prefer a strongly opinionated hiring process that won't play with anyone's life like that.
That said, treating probation as probation is definitely a thing. Especially in legal domains such as France and Germany. In the USA it's far less of a thing as employers can mostly let go of people at almost any time if they wish to and it's not a pattern of discrimination (though this is the fear of course, that a pattern could be formed).
[1] strictly not any reason, you can't be discriminated against, but enough reasons that they could invent one.
Are large companies really afraid of PR in firing individuals? If a company with many thousands of employees fires one person, outside of the C-level officers is that a news story? Even if disgruntled former employee tries to say anything disparaging, doesn't that immediately make them less credible as a source?
Also all of these big tech companies can just not refresh your stock if they don’t want to bother with firing you, which effectively halves your compensation.
1. On my first chat with a candidate, I layout the entire interview process. I acknowledge that it is long and I preemptively thank them for going through the process and say that we value their time. I make sure our recruiters can reiterate the process as clearly as I can.
2. I let the candidate know that at any time if they want to pull out, that is a-ok, and that they are welcome to apply again in the future in good standing. I also tell them that during our coding assignment, we really mean it when we say it's ok to ask for more time, and that we don't judge them negatively.
3. I tell the candidate that if at any point we decide to decline, that I will send them a written letter of feedback so as to make the process worth their time. This isn't always easy, but it's always been appreciated. Sometimes it is hard to write these letters, how do you tell someone multiple interviewers didn't like them? I do it by pressing our interviewers to state clearly what didn't come across well, and then I relay those things to the candidate. Sometimes even still the letters probably aren't super satisfying to the declined candidates, but I do my best and hope everyone realizes that job hunting in general is rarely satisfying.
Basically, transparency, honesty and specifically thanking them have gone a long way for me. I fully understand that an underfunded/understaffed startup might balk at the feedback part, especially when lawyers can get involved. But offering up items #1 and #2 to candidates should just be table stakes of your hiring process.
However, I don't think I'd value it after more than 3 interviews. Candidates are applying after work hours and there's a time / energy limit to how many processes they can take at a time. After a given point, you're wasting not hours but possibly months of their life.
But I agree, it's usually pretty obvious if you just weren't good enough, or you had a bad day, or they just didn't like you for some random reason.
Thank you for doing that sort of thing. It really helps.
> I acknowledge that it is long [...] and say that we value their time.
I dislike this communication style. Maybe it's a cultural difference. I've heard several times from an American speaker that they "value my time/comfort/satisfaction". At the same time their act clearly showed that they valued something else much more.
For me, your sentence would sound much more personal if you just omitted this last part and kept only the explanation.
> I acknowledge that it is long process, so we appreciate your patience.
Especially if there is an assignment with the interviews I really think that feedback should be required. I spent about a week on an assignment like this with 3 interviews and just got back a "nope, sorry". And it wasn't even from anyone I had interviewed with, just the original recruiter.
One thing that I noticed at my company:
When I first got hired (in 1990), it was made clear that I was a desired and valued employee. They were a very picky company, and might well have rejected me, but I felt respected and valued, from my first interview (I was flown out to the West Coast, and interviewed by two managers at a trade show).
As the years have gone by, I noticed that our HR department started to have a very different posture. They had to be the ones in charge. Applicants were supplicants. The company was doing them a favor, by considering them for this position.
Also, the HR department started to project this attitude to current employees, to a visibly increasing degree, over the 27 years that I was at that company. By the time I left, the HR posture was that employees were little more than serfs. There was no illusion that employment was a two-way relationship. They started to impose some really draconian policies on employees, with "termination of employment" as the only choice, if the new policy was not acceptable. No negotiations.
I think that this is an attitude that has become a standard in HR, these days, and that part of the reason for this interview process, is to filter for people that won't talk back to HR, and are willing to abase themselves for the company.
I've noticed though that as I've gotten more specialized to compilers and programming languages, my application experience has improved significantly. It's not a large sample size but the last few processes I've gone through have been fewer interviews that usually involve going over a project of mine or doing a problem that's related to compilers. It's really refreshing to have an interview where I actually learn something about my field of interest during it. I know that doesn't scale because we shouldn't expect compilers knowledge for junior compilers jobs but it's a very nice change of pace for me.
more competition = worse time for you
Currently I'm going through the interview process with a ton of companies (because my company is really dumb and is forcing everyone to move back to a certain bay area city post-covid), and I have been happily surprised to find that most of my interviews are very practical, project based, ones instead of straight whiteboarding leetcode problems. I've received several take-home projects that are followed up with a simple add-on interview to sit down and explain the choices made during the take-home. They have all been specifically focused on domain knowledge to the mobile platform that I'm interviewing for. Its really nice! I hope this trend continues.
That said, I am still reviewing leetcode problems for the stupid faang interviews I have coming up as well.
This was after a 10 minute conversation with the company's recruiter. To top it off, nothing in the job listing said anything about software. Just Cloud and Devops management role.
I am absolutely ok with take home or some presentation of my skills. However, I expect to know that I am being taken seriously as a candidate by that point. I don't want to waste my time on something with no investment from the company.
As you can guess, I bowed out of the running explaining that I didn't think it was appropriate for me to give them so much of my time with no commitment from their end. I also told them I could tell their take home project took them less than 5 minutes to generate for me as it was everywhere on the internet. How can I trust a process where the answers to the interview are everywhere? How can they really know my skills as a candidate if I can just steal the answers off of GitHub? Worse, how can I know how I will stack up to someone who might be less scrupulous than I and steal those answers when I tried in earnest and actually burned an afternoon trying to solve their test?
Look, a lot of people have good-looking CVs and can't code shit. I don't know about you but my experience was that one really can't hire based on CV alone. Also, I've seen "architects" that are smart and fairly knowledgeable people that failed to code very very basic stuff (as in, merge 2 sorted arrays).... I get it that at some companies you are expected to draw diagrams in Confluence as a main job, and might no longer have actual coding skills; but we want even the most senior people to actually code, and that doesn't seem unreasonable to me. So just because you're a very-senior FAANG employee doesn't automatically mean you'd be a good fit. I'm not saying they're bad employees, but maybe they just wouldn't be a good fit and wouldn't enjoy the job if they expect to just design stuff instead of actually implementing, too.
If I applied to 10 companies, and every single one of them asked me to come onsite for whiteboarding as the first step, that would also suck tremendously, but at least it would be limited in scope by the employer's time as well. As it stands, arbitrary companies can expect a large time investment without any of their staff ever having to speak to anyone.
I'll take a calculated stab at Amazon's once every 6 months I guess, because if I pass (which I haven't) I can potentially earn a hell of a lot more than any other place. I get it, whatever. If every company is doing it (they are)? I might just leave the industry if I can't find a way to be specifically good at remembering the implementation details of every data structure and algorithm. Sucks to be someone with pointless skills I guess.
The longer a candidate has worked on very capable teams the more surprised they will be to have those problems presented in a job interview.
Besides, if someone is duplicitous enough to have a good looking CV and no coding ability, what's stopping them from just cheating on the HackerRank?
TBH that's another argument I don't really get. Almost everyone agrees that basic CS knowledge trumps specific technology knowledge (I'd rather hire someone with strong CS fundamentals that didn't use Java before than someone who is a "Spring Boot expert" but lacks basic CS knowledge, even if I actually use Spring Boot right now).
But then, why complain that you don't do that in your work? Surely you need to traverse data structures from time to time, yeah it won't be the exotic tree traversal that I'd ask you to write but that's exactly the point - to test that you can be put in a novel situation that can't be directly-pasted from StackOverflow and you're able to write a recursive function that takes _a little bit_ of skill).
The hidden test case is opportunity for discussion during actual interview. And this answers your "what's stopping them" question, too - regardless of problem, I can tweak the input slightly so that your solution doesn't work - and more often than not, I don't even tweak the input, I just provide an additional testcase where your solution doesn't work. If you can quickly fix it ("oh, yeah, I forgot that URLs may have a fragment appended to it, let me quickly adjust my log-parsing condition") then it's awesome, it's exactly the signal I'm looking for, and we can go on to discuss system design and your relevant experience (but honestly, at that point my mind is likely ~80% made up, from CV + how you explain/modify your hackerrank solution).
1) you're expected to spend 3 or 4 hours on some HackerRank test before you've even spoken to anyone. Some of these tests (outside HackerRank) can actually be projects that take a day or more to get right. The issue is that at this point I don't know if the attitude is "hey, this seems like it might be a good hire, let's check if he can actually code" or if it's "let's send anyone this test and discard anyone who doesn't pass". I suspect that in a lot of cases it's the latter. I'm not opposed to investing time, but it quickly becomes unmanageable if everyone just asks you to pass their several-hour tests just to be considered for application. There is very little time investment from the company, and it feels almost like a dDoS attack on my time.
and 2), that a lot of these tests are asking you to solve some hard problem that you will rarely face in real life and where people have quite literally won Turing awards for finding solutions to them. Many previous discussions about this on HN in the past.
I don't think it's even all that much more effective at actually weeding out bad programmers than a simple test. We used to ask people to write a CSV address book importer with some very basic requirements; nothing fancy, you could do it in 30 minutes. It worked well enough, and a lot of the results we got back were horrible.
I am not one for LC type of problems, but at the least I have to admit they have the potential of being more objective than everything else during the interview process. You get the specs, you write the code and it gets tested via multiple test cases. It does not matter if the interviewer agrees your solution will work or not, and the interviewer won't have to copy&paste your code, compile and run it (like someone else mentioned in this thread).
On the other hand, what I particularly dislike about the LC problems is that many of them are essentially trick questions and brain teasers. Can't we just stick to problems that are relevant to an SWE?
The tech test seems often like it's cargo cult. It's on Joel's list so everyone thinks it is a must do. Instead of realising that the entire point of the tech test was to make sure people could actually code. With some of the original tech tests being do FizzBuzz or do something really simple in a short amount of time. Not, build me a production ready toy project using techincal DDD aspects.
Of course. But consider how that attitude looks from the perspective of a candidate - you'd rather waste my time that yours is a really good reason for me to drop out of the interview process.
This is essentially what's wrong with hiring right now. Companies don't want to have anyone "waste their time", so they have many levels of filtering to reject candidates as early as possible while doing as little work as possible to make hiring good for candidates. In other words, companies have largely forgotten that candidates are people, and wasting anyone's time is a pretty bad idea.
I think sometimes people forget people working at these companies are people too and noone wants to have their time wasted. This isn't companies deciding these things. It's people. It's the person on the otherside that doesn't want their time wasted.
Sans all of those qualifiers, anything more than 3 rounds is a deal breaker for me. If you don't know if I'm the right fit after 3 hours, verifiable experience, a public body of work, and a list of references, then your company culture isn't a good fit for me.
Every bad hire costs the company $50,000 - 200,000. Sometimes more. They can also sink or demoralize teams.
Many of the people conducting interviews are new to the process and don't know how to extract signal. Sometimes scales don't line up.
When you have a revolving door of employees (because that's the way things are these days), have trouble scheduling interviews (busy engineers trying to get their own work done), and can't get enough skilled interviewers on a panel, then of course the process will be a suboptimal experience for candidates.
To a degree, companies would rather a good candidate was passed over than a bad candidate was accepted. Type I and II errors.
Companies also don't like telling candidates how they did because that opens them up to lawsuit liabilities.
You have to do enough interviews to get signal yet not piss off candidates. (Or your employees in the interview pool!)
It's a hard problem for companies too.
Why is nothing done about this? As turnover soars and tenure plummets, I am willing to buy that companies do not value codebase knowledge, domain knowledge, or believe that it takes time for an engineer to get going. I can buy them seeing us engineers as replaceable widgets.
But we are at the point where a lot of companies cannot replace us and yet nothing is done about the endless parade out the door. The focus is entirely on shovelling new people in.
Chances are, the new hire replacements will be in the same 90%, so it is a wash (minus ramp-up time), but maybe the company gets lucky and finds someone in the other 10%.
And if you have a revolving door of workers, that suggests something else is wrong. Maybe you should focus on retaining existing workers rather than acquiring new ones.
You say that a bad hire is worth tens of thousands of dollars, but if that's the case, then most of what you said is irrelevant because a company that is smart enough to recognize this would be smart enough to never put a junior manager in a situation to make a terrible decision.
You would be shocked how many people blatantly lie or overstate their roles on resumes. Senior, junior, it happens all over.
A good practice is to ask candidates to go in depth about recent resume items and explain the technicals, business needs, etc.
> If someone is new to the interviewing process, then they shouldn't be doing interviews alone.
Most don't. But are you really calibrated after five interviews? Ten? And what about all the other folks that need to shadow / train?
If a manager is getting paid $150K a year and it costs $200K to fire a bad employee, then "when they're ready" is the correct metric to use.
I have seen a fairly small amount of employees hit the lower end on a singular dining bill when they had a company card and were meeting with business partners they were trying to "impress"
(obviously, the joke is free nice food and drink for all involved at the companies expense)
If you were fickle you could perhaps justify that as priced in to keeping good relations... but in the same light I'd call your figures priced into the talent acquisition process.
If I submit some “open source” code as some proof that I can code, how do you know I didn’t copy the code from somewhere?
Also, writing code for the sake of writing code doesn’t tell a hiring manager if the person can take requirements and translate that to an automated process. It just say that person isn’t that busy and can, excuse my language, shit out code for the sake of appearing productive.
Writing code can be a hobby, sure, but that’s only a small part of a software job and no amount of open source code can tell a company if the candidate can work with others and solve problems.
Balderdash. When was the last time an interview task involved working with others? I'd offer that open source PRs show this way better, and in an appropriate context (as a collaborator) rather than what we have now: adversarial interview{er,ee}s.
You can ask your candidate to explain the code... Is that not obvious?
> writing code for the sake of writing code doesn’t tell a hiring manager if the person can take requirements and translate that to an automated process
Kind of sounds like you don't know what open source software is.
> excuse my language, shit out code for the sake of appearing productive
I won't excuse your language. You sound like you're part of the problem buddy. I don't think you have any idea how to evaluate a programmer.
Asking about projects is the obvious thing, but only substantial and interesting projects really provide any interview value. Yet another Todo app doesn’t fit that criteria. Neither is another scaffolded crud app.
A PR to fix a bug in a semi-popular library is worth. But saying “I have a lot of repos” is def not.
> saying “I have a lot of repos” is def not.
When did I say that? I didn't. They should be looking at the repos and asking about them, not just taking your number of repos and using that as some kind of metric.
If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.
Usually it’s “I wrote some code and put it on GitHub, call it open source”.
> writing code for the sake of writing code
> It just say that person isn’t that busy and can, excuse my language, shit out code for the sake of appearing productive.
It sounds like you have a serious misunderstanding of open source at a basic level. It would have been questionable enough in 2000 but I’m not sure why anyone in 2021 would think that way.
Hell, I have public code on GitHub, but I’d never put it on my resume.
And this takes me to my 2nd point, and that is they current hiring model totally leads to companies hiring people who are good at interviewing not necessarily people who are good at doing the work required. There is no doubt t that interviewing for a job is a skill that can be learned and improved upon, and lots of crappy programmers have learned to be damn good at being I interviewed.
If you run a company and you have a "revolving door of employees" (ie: we can't retain talent), your managers "are new to the process" and don't know what they're looking for (ie: we hire inexperienced managers), and you "can't get enough skilled interviewers on a panel" (ie: "we don't hire enough engineers and we're too cheap and shortsighted to put them on tasks like hiring")... then yeah, you should expect your hiring costs to go up, have a revolving door of employees (because you don't know how to hire), and your teams to be demoralized.
The consequences of that are your (company's) fault. You should own up to your shortcomings and work on your hiring process... don't just punish the candidates indefinitely so that you can ignore your problems.
(I say this as a serial founder, and hopefully never need to be on the other end of the hiring process.)
I’d like to add time aspect as well. If selected, candidate will spend next 12-18 months with the team, 5 days a week. I look at those 5-6 hrs as worth an upfront investment from both the sides just ensure those days months aren’t miserable and you don’t end up parting ways on bad terms.
I’m saying this as an interviewee as well as hiring manager who has conducted more than a thousand interviews.
Nothing frustrates a team and hiring manager more than a mishire. It’s the same for candidate, they have to go through the charade of interviewing at tens of places again.
You have two ways to solve this problem:
1. Figure out what makes your employees keep leaving.
2. Hire people who are not good enough to work elsewhere.
2 things that line hits me.
1. Remuneration. If I can jump ship and come back later to much more money, why not?
2. I work to make myself replaceable. This is what good documentation, code comments, architecture is for!
* See the advert online, and send an email/fill out a form to apply.
* Have a quick phone-chat with a HR-person, where they ask about salary, history, and try to decide if I'm a chancer, or I have some somewhat useful skills.
* Have a 30-60 minute interview with some technical people, in-person.
* Optionally have a second interview with a tech-lead, or somebody else higher up the chain.
* Receive offer, rejection, or get ghosted.
Smaller companies sometimes have different processes. More than once I've sent an email/CV in to apply and been invited out for beer/food, and received a verbal offer the following morning. No other interviews, or tests.
Thought your comment was interesting, so went to check out your profile.
That was also clean and well made, so followed through to your website.
Found this: "I published a simple tool to all your repository details from Github, self-hosted Github Enterprise installations, and other compatible systems."
Do you mean: ...to [pull] all your repository details
Since you have such a nice profile and everything I thought maybe you intended to include this word in there.
Hope this is helpful.
Somewhat related to interviewing and getting hired.
If it's in an appropriate comment for this threat then please remove it. @admin
I'll fix the entry you mention - as you suspected a missing word there.
Thought the beginning of your comment was interesting, so went to check out the middle of your comment.
That was also clean and well written, so followed through to the end.
Found this: "If it's in an appropriate comment for this threat then please remove it."
Do you mean: If it's in an inappropriate comment for this thread then please remove it.
Since you have such a nice comment and everything I thought maybe you intended not to make these typos.
Hope this is helpful.
I really am not looking forward to going through a formal interview process, because it will be so jarring compared to what I am used to!
Started with applications over a web form on the university careers website, then chatted over email with the hiring manager. Eventually got set up with some interviews with current lab people, and eventually the PI.
Mirrored in industry, although that was back in 2018. So all in all the “regular” route at least for this level of work in biotech/biology is pretty sane.
That being said, I’ve used your method in the past as well to great success, and is one of my secret techniques to get more traction when I’m looking ;)
If someone sits though 6 hours of interviews and pointless exercises that should instead be solved by consulting the documentation, they will probably just do what they are told without fuss, will work overtime for free and will let the company walk all over them with regards to sick pay, holidays, etc.
It's common for there to be some uncertainty with one or two of these things, but if there's a lot of uncertainty, you are being strung along. Best case they are waiting you out trying to find a better candidate, worst case they don't even have the budget for you and are playing politics within their company using you as leverage.
Interview multiple places in parallel, and don't cancel any interviews until you've got a signed piece of paper. But of course, prioritize the ones that aren't jerking your chain.
The process was first interview was 30 mins and basically a getting to know you and us session. Second interview was a two hour technical interview with debugging/fix this function type question and a single from scratch example question in the candidates language of choice. The final round was purely optional if the CTO or CEO wanted to meet the candidate (they rarely did).
If you made it through all that you got an offer. Of all the candidates I hired only 1 didn't work out long term.
Now that I am on the other end, I don't understand the need for this overly complex and generally noncommittal (on the employer side) process. If it's FAANG I am lucky if I can even get a fucking job description these days. They want to interview me for jobs I can't know about and best fit me for their needs. What about my needs? What about my time? If I can't even get a job description, why do you think I want to waste 3 hours doing "homework" before I can even talk to anyone for more than 10 minutes about what possible job I could be actually doing for you?
Hiring in Tech is broken and I don't know what we can do to fix it.
Why don't you find people working on a problem you like, then ask them if they have open positions?
Working though engineers is almost always better than filtering though company recruiters. You'll wind up with a role you like rather than being stuffed into open head count.
I've done this. It works.
That's not always straight forward. Once you get patched over to HR, it's their process.
I am glad to hear that this is still working for you, hopefully a serendipitous moment will occur soon to open a door for me as well.
> Working though engineers is almost always better than filtering though company recruiters.
Doesn't this say something about hiring being broken when you have to dig through profiles on a company website or linkedin and cold contact devs to get your foot in the door?
I am by no means suggesting that what you are saying is a bad idea, just that this reeks of poor and inefficient hiring policies.
And that's really the issue.
The FAANG's are throwing around so much money that people are willing to put up with almost any amount of abuse to be on the other side of the line. The FAANGs can deal out any amount of abuse and they will still have a line of applicants around the block--there is no negative feedback in the interview process no matter how bad they make it.
> Hiring in Tech is broken and I don't know what we can do to fix it.
Software hiring in the Valley is broken--possibly.
Hardware folks I know still go through the same old, same old. Single phone call with an engineer to make sure you're not simply a waste of oxygen. One on-site with 4-6 people (and 6 would be an unusually long day--generally that would mean you're doing well and some extra people want to talk to you). One week to response--two weeks MAX.
WTF are you software people doing?
I had an ME friend who got into an argument with an interviewer about the convection equation. The interviewer was completely wrong, eventually my friend admitted "Ok I literally have it pulled up on my screen right now, I think you're mistaken."
I don't consider those terribly unfair. Depending upon how the discussion goes, I could see myself doing something like this.
For example, one of my standard questions for firmware people is a state machine in Verilog (for those who claim to know Verilog). What I'm looking for is whether you know the difference between blocking and non-blocking assignment.
> Take home coding challenge -> take home hw design challenge where they expect you to have access to expensive software.
> I have a dozen more questions to get through.
These are not fine, though.
> The interviewer was completely wrong
This, sadly, happens. I have had an interviewer cite incorrect information about semiconductor device physics.
Quite often, though, it happens in more junior interviewers with "standard" questions that are passed around because the interviewer doesn't fully grasp the question. When I was a junior engineer, I was always terrified that I would make that screwup. I used to do review study on my own questions and area before every interview to make sure that didn't happen.
For example, I had an interviewer who gave me a question of "clock a binary number in serially and use a state machine to divide it by 3." It's a really cool question and was passed around between engineers of a certain company. But ...
This is either a really easy question or a really hard question depending upon your choice of direction to clock the number in. If you pick the easy way, it's something like 3 states and it's obvious. If you pick the hard way, it's 6 states and takes a somewhat subtle inductive proof to show that you're right. If the interviewer doesn't know that this can happen, he can't dig the candidate out if they pick the hard direction.
Of course, you know which direction I picked in the interview. LOL.
Last time I got that question it was a schematic large enough that I would have put it on multiple pages and I only had a few minutes to get through it, which was a problem. Brought it up because it seems to be a touch point for others.
I think it stems from the fact that software is "soft" i.e. highly malleable and flexible. This improves time-to-market considerably and there is an inherent expectation built-in to "move"/"execute" quickly.
This also creates problems. Now the same thing can be done in multiple ways. There is a "my-company" way of doing. There is "my-way" of doing. Throw in personal tastes, likes-dislikes for testing, syntax, editors to name a few. Over the time, people take on multiple identities (e.g. FAANG, language fraternities, clubs of certain technology, editor fraternities etc). These mix and match in at best interesting ways and at worst in toxic ways.
1. An exam. You literally take a test. This mostly takes care of the technical portion, evaluates your cognitive skills, IQ, EQ, whatever. The idea is to get a general idea of what you "know" and gives some baseline reference numbers. You could also do a "coding test" as part of the exam, but I would not lean too heavily on those as they are subjective too. You would need to look at the results to see where they were strong/weak, as for some roles it's fine to be weak one place and strong another.
2. A veteran/senior (or two) interviews the candidate, asking deep questions to probe into the person's actual experience - because experience is 1000% more important than "what you know". The way I do this is a "binary search" of questions both simple and very specific, and based on responses I get more general or more specific. I can very quickly discover how much real-world experience the person has this way.
3. An interview with the team. This is actually for the team, not the candidate. The team can see whether the candidate is a mesh for their particular culture. It's just as important that the candidate fits the team as whether they're capable of "performing".
Within this system, you wouldn't ever do more than 5 rounds (3 on average), you get a mix of "impartial facts" (the exam) and "gut feeling", and you still have the human factor both evaluating the person's experience/responses and checking for culture fit.
I also think the attitude of companies during interviews really sucks. Many feel like they're doing you a favor or you're wasting their time. That was a distinct feeling I got when interviewing at Google, but not at Apple and I really think it's why I passed those and not google. They were collaborative and fun at Apple. I put a lot of effort into making candidates at my company feel welcomed and like they are already part of the team and IMO it really helps them succeed.
It isn't fair to the person applying because they didn't pick the people on the panel, but if the one doing the interviewing doesn't hide their feeling it's obviously not great.
Also, regardless of whether or not they want to be there, it's a bad look for the company. Somebody took a day off to talk to you, it's only fair that an interviewer reciprocates
It has upsides and downsides, like as you said you had to go through 3 different on-sites (one for each team), but you'll get a good sense of the team before getting an offer (and they'll get a good sense of you). I like the Apple method much better but I had an unusually bad Google interview process so it's possible other people had better experiences.
Can confirm that this is largely true, with an asterisk.
The interview panel (for SWE candidates) is indeed drawn at random, but it's becoming more and more common to conduct fit interviews for specific roles. This is usually done by the hiring manager, in rare cases also involving other people (e.g. the tech lead).
After that I asked how many more interviews I should expect. To my horror the answer I got was "we only hire people if all the partners agree to hire you, we all have veto power, so you should expect to see everyone"... so TWENTY more interviews. I rather abruptly told the guy that was insane and I didn't have time for that, shook his hand and walked out. He seemed perplexed.
... they went bust about a year later.
But the alternative is more filtering before the main round of interviews, to increase the base success rate of candidates, which many people hate (see many other comment threads on this post). And too much would turn off the best candidates probably more than the worse candidates, as they have more outside options.
Once a req is approved then it goes out to the team to disperse as well as hr. Some roles get handed off to the critical search team if the hiring manager pushes hard enough. But that doesn’t really matter.
We get flooded with candidates. Almost every one of them could probably do the job so we have to figure out who could do it best through the interview process. I personally never ask stupid gotcha puzzle questions because those annoy me as much as they do most folks here. I ask people to talk about their experience as it relates to the role. Usually this means I ask about how they solved a truly difficult problem at work, what made it difficult and how they were able to overcome it. Then I like to get into the technical stuff of what they implemented and why. Mostly I just like letting people who are proud of something they’ve done get a chance to talk about it.
Anyway we’re supposed to score people based on these arbitrary metrics like longevity (how long we think they will stay) and communication ability (this is very, very close to being racist…draw your own conclusions).
I never score people. Managers ask me why and I say because I don’t interview spreadsheets.
Anyway I’m one of usually 4 interviews. I interview by myself and the rest are all panel interviews. And once you finish the last panel that’s the last you hear from us unless you get an offer. I hate it.
I'm trying to draw my own conclusion but I'm confused. Communication ability is very important for developers and other technical roles. We need to be able to talk to each other about our work, and in many organizations we also need to be able to work effectively with other non-technical staff.
Of course, this doesn't mean that you have to speak or write the company's primary language in some particular way, as long as you can make yourself understood. Nor does it require that you speak that language as your first language.
Is there something specific about _how_ Big Ass Corporation is evaluating communication ability that is racist?
When in fact, these candidates may have excellent communication skills, and in a blind interview situation the same interviewer might praise their writing abilities.
But you don't really know, because the interviewer is rating communication skills in a scenario that can easily bring out a lot of hidden biases.
I think it's really important to spell out what "communication ability" means so that all the interviewers know what they're looking for. And more generally, it's very important that before you start the hiring process, you have a clearly defined set of criteria that everyone participating in the hiring process agrees on.
Something is going to have to change - really a lot of things. One of them is going to be that companies need to learn to figure out how to hire people without putting them through a grind-fest. Figure out how to deal with bad hires after-the-fact, but don't let yourself get screwed not hiring good talent because you made the interview process a giant pain in the ass to catch the crap.
Oh and compensation needs to go up to make some of these interview grinds worth it.
And that's the rub. Not only do they struggle to value my skillset, they also can't compensate it accurately. And sadly, FAANGs don't even have the roles in a lot of niches.
When you can make 3x what a FAANG would offer, annually, but the companies building in your same niche are too immature and pay 1/3rd of what FAANGs do, its tricky to want to tolerate any of it!
Given how many ways there are to do that and much more, I would like the structure of someone else’s idea to focus (aka being an employee). Doing things solo has overhead costs and liability risks, whereas employment has almost none but half to 3/4ths of your compensation is withheld the whole time. So there is a limit to what comp I’ll accept, given the opportunity costs. Would be great if that comp was FAANG level.
Can you share some things in the past that were easy money that netted you $1.5M in a year? I'm genuinely curious.
I used to have a ton of ideas that I thought if I did everything right I could've maybe made $300-600k. But then you can just get that as a paycheck at FAANG.
None of my ideas ever were easy and could realistically generate more than that. Plus there was always a risk they would generate $0.
Hm, worst case, people on HN debate an irrelevant understanding of what I say is possible
Best case, they copy it en masse and dilute the opportunities faster
No thanks
I would take $500k doing the same stuff for a tech employer but nobody is offering that right now. Some contracting firms do, kind of, don’t really want hourly though and also want the benefits. I want to focus on someone else's visions, get paid on days off, no risk. Also want a ton of equity I wouldn’t go and purchase myself. Or private equity that I wouldn't have the opportunity of purchasing in addition to an attractive cash compensation. (These are all things I could do in just frontend/fullstack work.)
Some smaller companies are going above the 125-150k range, to double that. But not quite and they’re still few and far between.
this is a thread about the conundrum of leveraging this experience without losing freedom or opportunity costs, not about being miffed that someone won't share how to make money, its like you all want to be scammed into purchasing an some youtuber's outdated amazon dropshipping masterclass.
> You can launch DAOs that automate anything these days and take a small percentage from the users of it. Just automate any small aspect of what people do and auto-liquidate proceeds for USD* so that you aren't accidentally speculating on anything, your users can pay for the liquidation too. > *Your oracle server/cron job can incorporate a broker's API to get actual USD, your DAO can only get surrogates such as USDC which is redeemable 1:1 for USD at certain brokerages.
> It's a boom town. Anybody can make 3x more than what a FAANG would pay annually, and that's being generous.
Nothing changed regarding that one as far as I can see so interview processes getting longer isn't all that surprising. After all that's one surefire way to optimize for getting desperate people.
The worst offender was a company I had five meetings with, 3 of which were identical code reviews for the same code test. None of the reviewers realized I already had the code review with their peers. None knew what the next step was.
Most companies just didn't have an organized funnel for candidates.
The one that did I quickly took the job offer at. Here's what they did right:
1. The recruiter prepped me for each interview as if they were a good friend looking out for me. They told me who I was talking with and what hobbies they had so I could relate to them.
2. I knew of each meeting and its format in advance. It's weird I'm calling this out as it seems simple, but here we are :-)
3. The code review was paid. And actually quite fun. The previous company code review was unpaid and 20 hours of 'implement a REST API'
4. The engineering team was actually trained on recruiting. Each one had read my resume and asked detailed questions about my hobbies, experiences, etc. Engineers elsewhere hadn't read my resume at all.
5. I always had quick feedback on technical meetings and didn't have more than three.
The most important difference I noticed is that most companies were ambivalent seeing me fail.. a select few even seemed to crave that.
I've seen the same thing. It makes no sense. I keep telling myself the incentives can't really be such that your hiring process be actively antagonistic...not if we want anything good right?
But perhaps the market can stay irrational longer than I can go without income. Hold strong to the companies that bother to acknowledge you're a person.
See, if your test is so difficult that people are failing, then it must mean that you are being selective and only hiring the best!!!!!
- investigating the role, the company, their stupid website, their made up culture
- doing the unpaid take home tests (currently investing 8 hours doing a technical test for yet another stupid startup)
- answering dumb questions ("why do you want to work for $neverheardofstartup?") on fancy js forms
- having to register to their stupid career backend, thanks for yet another chance of having my inbox filled with spam because you don't know how to encrypt data
- uploading hours and hours of video presentations (as if cover letters weren't dumb enough)
only to be canned with a copy-paste "due to the amount of curricula we received unfortunately we cannot provide feedback - good luck with your job search" nonsense.
And if I'm lucky enough not to be weeded out by a bored-to-death HR person with the attention span of a starving kitten, this was just interview step 1/5
Fuck you, from the bottom of my heart.
Technically I was qualified and able to answer their questions. But ultimately was turned down after 6 rounds of interviewing. I think I was heavily dinged because I wasn’t entirely familiar with their product in the wild, and was never given any hint as to what product I would be working on.
I also disagree that interviewing is not a technical challenge. For most programmers it is. There are very few who can breeze through FAANG-level technical interviews.
The only reason why I'd come somewhere is if I like the engineers or if I'm in need of money. If I need the money, I won't ask a thing.
I understand the reasoning: if you think you have a special mission and want people dedicated to that mission, filter by dedication. But I'm not really sure there is a way for any one candidate to consume as much time interviewing for a role as that company could consume out of a pool of candidates. And that includes my smart-ass idea of trying to interview at Pinterest and stopping in the middle of the interview saying "please sign up to see the rest of this whiteboard solution".
This is a typical HR strategy to keep themselves busy so they don't get laid off. HR is not a revenue generating department, so even if they aren't hiring, then they still need to push paper.
1. Review resumes to see who meets the criteria based on credentials.
2. Recruiter phone screen to screen for any glaring issues
3. We conduct an interview day and the candidate interviews with 3-4 people (30 minutes each). We have a mix of levels conducting interviews but make sure to have at least 2 leaders from our practice. We try to make sure we collectively poke around all areas (technical, cultural, communication).
4. That same day or the following day (want to make sure candidate is fresh in our heads) we discuss candidate.
5. Each interviewer (starting with the most junior) has to speak about candidate and rate them from 1-3. It can be any decimal rating but cannot be a 1.5 (an “I don’t know” answer).
6. Interestingly, we are mostly in the same ballpark on these calls and when we move forward, we are generally happy with that person.
I can’t speak for the candidate who may have to wait a bit between application, recruiter conversation, and interviews. But at the very least, the interview to decision process is pretty painless and you’ll have a decision within 2 days max.
total length of time ~ 7 months emails sent/received ~ 50 phone calls ~ 20 technical interviews: 7 (1 with screen with recruiter, 6 with engineers)
team match interviews: 3 (for me at least these were real interviews, in that I "flunked" the first 2, and decided to take the 3rd one very seriously before getting an offer)
Before getting hiring approval, I honestly felt that I would get rejected, and I can honestly say that being more "personable" and very "communicative" probably had a lot to do with why I made it through.
My honest advice would be to stop thinking of these long interview processes in terms of a a binary outcome that you have complete control over. Instead, think of it as trying to maximize some hidden parameter of a binomial distribution, where every interaction slightly increases your odds in the final coin flip.
However, I wholeheartedly could not disagree more w/ "having won the <insert_x_silicon_valley_company_here> hiring lottery". 80+ hours of interviewing? No offense, that doesn't sound like winning the lottery. That sounds like you don't value your time. Unless you're getting paid for that many hours of interviewing or receive a signing bonus to make up for it, any company that does 10+ hours of interviewing can take a rusted iron rod and shove it up their own arse.
In a market where software engineers are in super high demand, if a company cannot refine the technical interview(s) down to a max of 3 hours for any specific role, then why waste your time? I understand wanting to gauge a candidate's technical abilities. But there's a balance between understanding the candidate's technical abilities, the technical knowledge required for the job, and (the most important bit) what can be learned on the job for the role.
Google's point is just that they prefer to avoid false positives at the cost of (potentially) a lot of false negatives. The current interview process is probably some local optimum;
I haven't worked at a company yet that is actually good at interviewing. Where good is optimized over high recall and accuracy and a small time investment.
I know that Google does have one big advantage, in that a good percentage of people that get the offer end up accepting. That (unfortunately) gives Google a lot more leeway and possibly less incentive to further optimize the interview process. Software engineers are in high demand, but also Google is in high demand among software engineers.
At my previous job, trying to find a candidate for a role essentially involved lowering the bar until somebody was no longer in demand, since we weren't "in demand".
As for working at Google, I think it really depends on the person. For me it was a good gamble in terms of both immediate learning and future opportunities; for others it won't be. I do find the opportunity to have my code (or what's left of it after reviews anyways) reach billions of people a thrill like no other though.
There is so many people applying for positions now that companies are resorting to these more and more annoying filtering processes.
My first job in this field 14 years ago was one interview and I got the job the next day. That would be almost impossible today.
I blame it on two things, oversaturation of the "learn to code" meme and the rise and growth of recruitment agencies and their influence on HR practices. They have to justify their own jobs after all - just 10 years ago there wasn't really much of a concept of an HR or IT recruiter as far as I recall - or it was just emerging.
I've said this before but I believe this field is becoming increasingly commodified. Soon you will be either a "white-collar" fang or a blue-collar "independent contractor".
Only way to fire someone on the spot is if they are breaking law or refusing to do the work
If this person is literally not producing anything useful, then set them a basic piece of work and tell them to complete it. If they can't give them a warning, tell them to upskill. Repeat after a month. And again a month after that. If they still can't do it then you have plenty of evidence to justify firing them, anywhere in the world.
Google took 3 months. 1 month was from the virtual onsite final interviews to the Hiring Committee decision. It was a miserable month and even my wife hated Google by the end.
Second was for a Director of Engg position at a mid sized company. It took 2 months and finally I had to force them to answer. It was a company with weak leadership and it showed in their inability to make a decision.
* Phone screen with recruiter that reached out to you
* Screen with the hiring manager
* Behavioral interview with multiple peeps
* Code pairing session with multiple peeps
* System design session with multiple peeps
So AT LEAST 5 hours time commitment just on interviews. Add time to research the company, its employees, and etc. Maybe the code pairing is instead an at-home test of some sort. This could potentially add hours(or in the case of Teleport like 20+ hours). Just engaging with a handful of companies was a huge amount of extra work and stress on top of existing responsibilities.
I pulled out of three voluntarily and declined an offer from the last for various reasons, opting to stick out till my RSU cliff in October. For the next round of engagements I may start toying with filtering out companies based on their hiring process as well and giving push back on it to see what happens.
I did actually tell one that the schedule of phone interviews (2) and video call rounds (4) was too much commitment without more details about the role and salary range. They responded with "if that's too much commitment the position is too".
Dodged that bullshit!
Google is already kinda doing this with Grow With Google, so I am just thinking of an even more extensive and rigorous version of this
And/or just ask people about their best Factorio factories and EXAPUNKS solutions :)
This is nothing to do with removing risk from hiring processes. It's to filter for those who want to be in the fraternity so much they will do anything to get there - including being chronically underpaid and badly treated.
There is still a shortage of good people. Let these companies have the less good people.
Good employers know talent is in short supply.
I had a long interaction at Amazon where the recruiter told me they are trying something new. Their goal is to keep the candidates mental health in mind and create a welcoming and open process.
I spent 2 hours in the phone where she presented me with different process and what not. I even learned the name of her grand daughter, and her dog, and how she had to raise the grand kids when the mother was going through a phase, and how she had to paint her hair pink to keep up with the new generation. She gave me her personal cell, and we communicated everyday until my assessment test.
I passed the coding challenge. But that cultural or psychological test? No idea. Anyway, never heard from her again despite emailing and texting.
Incidentally I've noticed that the Ruby community has this weird thing about insisting on either N years of Ruby experience or requiring interviewees use Ruby during technical interviews or take home projects. Ruby shops were the only places where I've ever been required to use a particular language during an interview. I suppose it's because there's so much magic happening in DSLs like Rails that they assume it'll take too long for even experienced engineers to come up to speed?
Obviously there's risk involved in the hiring process. But I think there's a lot more risk involved in procedurally treating people like garbage.
Anyway, after that ordeal I'm going to insist on being allowed to interview in a language I'm familiar with. They'll judge me on my best work or not at all.
I was being interviewed for a principal engineer. I was very clear and kept saying I wanted a management track position. They kept saying we love your background we can work with you on this. Ninth interview was with the CTO. He said the same. Them ghosted. Wouldn't answer my emails or calls. 9 hours, plus prep time wasted.
The company I ended up getting hired by also did a large number of interviews, 8. And they took even longer. Just over three months from initial contact. They're fantastic to work for, but I do think there comes a point where if you keep digging you're going to find something you don't like.
He was unemployed. They interviewed him 5 times over a month and a half, and tried to get him on site for a 6th interview loop roughly 2 months after starting the whole process. They were most put out when he told them he'd already got another job. He was amazed at how offended they were, especially that he'd wasted their time.
He was, apparently, supposed to just sit around and wait for them to make a decision, because who needs money to pay for things like rent, food etc?
In that time, I had already started my new job -- I didn't actually take the role at RedHat, but, I was able to use their offer letter as leverage to increase my salary.
I've worked for YC companies, I've worked for large companies. The larger companies seem to be a little bit easier to get into: my only interview at Luxottica was literally someone asking me about some retail experience I had about 20 years ago and some very basic Linux questions (retail technical architect position), but, I've had YC companies have a multi-month long interview process where I've been told after 10 or 11 interviews that they thought I was "Too senior for the role," which, just kinda blew my mind.
The whole process is broken, but, there's not really a good solution to fix it.
You'd think spending some executive muscle to smoothen out the warts in the process would be beneficial to any company trying to recruit smart people. But I guess having regular engineers or other employees with whatever ineptitudes in empathy or social skills won't be fixed by somebody telling them to "be sensible and nice." If that's how they were treated and think it's ok to treat others the same way, that's how it will be.
If candidates have less time for interviews, they will have less offers/counter offers to use as leverage
Finding your own clients doesn't start looking as bad, and a discussion to see if you'll work together is much better than an interview.
Long, multiple interviews are great for those who are already in the group - it provides legitimate excuse to hold off doing actual work, feel smug with their peers about how difficult the job is, and also provides acceptable excuse for project delays.
As a senior engineer, it's amusing being interviewed by intelligent but very junior engineers who clearly cannot understand the scope of what's in the resume. This usually happens with a quick scan of the resume followed by a realization (there is this peculiar look) that they don't have any relevant questions to ask about the experience, and finally landing on their favourite puzzle questions because what they really want to know is how my thought process works.
It's a risk mitigation strategy.
[0] Data Science Playbook, Booz Allen Hamilton https://www.boozallen.com/s/insight/publication/data-science...
If you want a backend engineer - book a few hours, even on a weekend, set up an IDE and get on a real world project. No bullshit. Build a small API to these requirements, using these technologies but take care of edge cases and deploy that bad boy.
I’m guessing not.
It’s poorly designed and/or poorly implemented hiring strategies that lead to bad hires, mostly through a lot of noise being collected during the interview process.
This is a very solvable problem.
Edit: I will add that this is an ad for Booz hiring, so of course they want more process.
What’s maddening about that is that this was for a consulting position not a developer position. It didn’t matter though because the contract written one way, the management at the client refused to accept the terms of the signed contract, and the developers I was there to help thought I was their subordinate to dictate.
My experience with a firm that started with three, then paused, had an "open evening" for interviews and then wanted more (which I politely declined and privately blacklisted them) reminds me of the lucky escape I had: the firm went through this mess only to uncover (a little later) an operational error that left them refunding several billion to clients, trundling on as a zombie firm!
I don't know these things well enough but it makes no sense to me. For starters, in the tech sector in my country the salary for fresh grads like me actually come mostly from the government. Moreover, these companies are all secretive about compensation, and they probably think they can get away with it by dangling their "reputation" in front of you like a carrot. In most cases the salary is about the same as a small startup because, again, they get the money from the government.
People can argue about spending time and resources on training and what not but basically every job ad, from "top" companies to the web dev garage down the road, expects us to learn by ourselves anyway?
It's frustrating for early career starters that most of my friends and I are going through. It's such a huge waste of everyone's time and people are just churning because of this crap. Please get rid of non-technical HR and interviewers.
Sorry for the emotional rant. I would really like to know what risks (other than useless non-technical HR keeping their jobs) there are after candidates have past a certain threshold for quality, particularly for junior positions.
It's harder to deal with emotional kids than it is to deal with incompetent engineers. Maybe that's why those non-technical HRs might not be as useless as you think.
It's harder to deal with people who think they are competent and know it all than emotional kids.
And that's a risk that could potentially be spotted by a competent HR.
> It's harder to deal with people who think they are competent and know it all than emotional kids.
Maybe, but juniors are (unfortunately) seen as a commodity by the market. Commodities are about uniformity and adherence to some standard, rather than uniqueness.
It's a risk that could only be spotted be HR, don't know about the "competent" part. There would be no emotional-kid risks to speak of if it weren't for useless HR.
> Maybe, but juniors are (unfortunately) seen as a commodity by the market. Commodities are about uniformity and adherence to some standard, rather than uniqueness.
It's making even less sense now. If we are commodities and it's all about uniformity and standard, why do we see senior engineers complaining about this, too? It also makes no economic sense to spend so much time and effort on elaborate bullshit on "commodities". I don't mind being a commodity if the standards that you speak of exist, and I don't want to be unique. But guess what? It's the HR that wants us to be the unique commodities.
Someone without the required technical chops can be useless, which isn't good, but these people can be worse than useless as they can derail and/or demoralize an entire team. I've seen it happen; it's not pretty.
This isn't unique to younger people, but in my experience the risk is quite a bit higher in younger people. I say this also as someone who, in hindsight, was quite difficult to work with when I was younger for various reasons. As I've grown older, I've learned a thing or two and I think that now I'm actually a fairly nice person to work with (I hope so, anyway...)
Everything else being equal, I'd rather take someone with a 9 (out of 10) on soft skills and a 6 or 7 on technical skills, than someone with a 3 or 4 on soft skills but a 10 on technical skills.
I agree, I've even had to reverse my own team's policy on this at work : I used to think the technical stuff was the most important and pushed my team towards hiring exclusively the technically smart people, but I have been proven wrong over and over again by those "smart" engineers I vouched for.
More and more companies are doing this now in tech space (AU) as well. My last 4-5 job app contains 5 interviews, even the medium sized one.
It is super annoying for me, but I'm not sure what to do about it, some of my dream big tech companies are like that so I have to go through that. I'm pretty sure a lot of people go through with that because that's their dream job too, not because they liked it
Another problem is in certain companies, senior management don't trust their own staff and want to be involved in the recruitment process.
Yet another problem is poor CV vetting. You really can tell a lot about a candidate just from the CV. Even if (in the UK) an agency has mangled the CV into its own 'template' for companies.
Demonstrating knowledge of algorithms is fine. Having to implement a red-black tree in an interview, or some arcane template corner of C++'s standard library from scratch, is not a good use of anyone's time.
If companies don't keep consistent interview processes, if they have two 'yes' candidates for one role, they can't fairly compare them and choose.
My worst/most lengthy interview was for a certain bank, that famously expects employees to work 12-14 hr days, and weekends. Total interview time: 24 hours. The result boiled down to the MD/partner interviewing me last, and having the yes/no decision.
More than that is just silly and contrived (although I usually end up talking to a VP or similar these days on account of my seniority).
There are usually three major red flags that make me step away (or at least curb my expectations):
- Any kind of automated coding test (I have a GitHub profile and plenty of public code, plus HackerRank and the like can be gamed if you have enough free time)
- Whiteboard or live coding interviews (I find contrived discussions about algorithms stupid when I can reach into my actual, physical bookshelf to a well thumbed-through copy of Skiena, get a tested approach going and _then_ figure out how best to optimize things)
- When I am asked for compensation on the very first interview. I see it as culturally rude, and if they read through my CV at all and have a target for the role they are interviewing me for they should have already done the math.
But as I am edging towards 50, a lot of the above just doesn’t happen. Instead I have long, rambling conversations about company values, people culture, and even end up doing free corporate strategy consultations, in which I am obviously expected to utter the right buzzwords that fit the interviewers’ worldview.
I quite enjoy those conversations for the insights they provide into how completely broken some companies are - instead of getting down to brass tacks and discussing their challenges, many startups end up coming across as cargo culting FAANG concepts without addressing their actual pain points (how to grow, how to retain employees, how to actually deliver product, etc.).
On the other hand, any Amazon interview has tons of people :)
There were a lot of interviews. For the fourth or fifth they flew me out for a whole day of interviews in Dublin. These included at least three different departments that I remember with separate coding interviews, and I had to give an hour long presentation.
I didn't get the role, and shortly after the Brighton outpost was axed. In hindsight I'm pretty sure that I didn't get the role because someone high up didn't want the outpost office to exist (it was only there because someone important they wanted was determined to live here).
I'm not sore though. Not long after the company hit the news for having a toxic culture (amongst other issues), particularly toward women.
The problem is companies don't care about you and your time until you are their employee. They'll gladly waste hours and hours and hours of your time, because doing so costs them nothing.
There's actually a super simple solution to this problem.
Require interviews be paid. Doesn't have to be a lot, a simple honorarium scaled to the role's salary would suffice.
If your time has a cost to companies, they'll stop wasting it and start optimizing to minimize the time hiring takes instead of optimizing for other factors and ignoring the negative externality of wasting peoples time.
Two months ago, in June, a company reached out to me regarding a senior level back/front hybrid role. This company previously ghosted me two years ago but still had my resume and were now willing to hire me right away for a substantial increase in pay.
Before I accepted any offer, I shopped myself out on Indeed and found there is a huge demand for folks like myself right now. Here's a taste of how it went: Company #1: Fintech startup. Two separate 30 minute, non-technical interviews. Third interview was a four-hour long interview involving multiple LeetCode problems. Fourth interview they wanted to discuss my performance during the third interview, and then schedule a fifth interview. I declined because a) I felt this was overkill and unnecessary, and b) one of their developers was rude and condescending because I am self-taught. He went out of his way for 8 minutes to berate me. I had never experienced anything like it.
Company #2: AI-focused firm in analytics. Hiring for a management-level role. Went through three interviews. First was a 30 minute screening. Second was an hour long overview of my technical background. Third was mostly a follow-up to the discussion that took place during the second interview. And at the end of the third interview they informed me there would be four more interviews to meet the team, write code, and a whiteboarding session. I declined and said I'm not interested, again because of the time factor mostly.
And I noticed this process repeat itself for most companies. It's mentally exhausting, plus I have a family, my current job requirements, and other responsibilities.
The interview process is really unpredictable to a degree. Some folks want to see substantially more coding than others, taking into account similar job roles and descriptions.
I see a lot of folks who have interviewed with FAANG companies, and while I don't have any experience with them, the process sounds somewhat similar.
In short: shit on input does not bide well
I would say that's the worst person to do the personality check. Instead, engineers the hire would actually work with should probably do the personality check.
Often HR is either a bureaucrat with a non-technical degree, or an inexperienced young "internal recruiter" with a non-technical degree and a pleasant appearance meant to attract responses on LinkedIn. Neither of those are uniquely well suited to judging personalities. (Unless this is another case of, #wontfix, we want to screen out engineers who have personality characteristics that random 24 year old sociology students don't like.)
Ah and your professionalism stops as soon as you hire someone. The rest of candidates might be left without a response even in their 3rd reminder. I guess it’s tough to even setup the auto email notification in the ATS tool you are using.
Management does not like this and blames the assessment team for having "high standards" and feels that we are wasting previous time (of assessors) and not getting desired results. The assessment team feels that the written tests are not a good indicator of coding skill and that most applicants fail in the basics of coding (logic, for loops, pointers etc.). Management has given a new target to reduce the time to hire and increase our hit rate.
The solution will mostly consist of removing HR round (no value add, can be assessed in TA), reducing or eliminating TA (!) and relying solely on the written test. Given the written test quality (though it has mininal configurability in terms of the split between MC and coding questions) this seems likely to get in a lot of "false positives".
My questions - is it really feasible to use only a online automated assessment (not specifically the one we are using) to get a right coding assessment done for freshers? is there a "good" (efficient and effective) "standardized" framework/solution for fresher assessment which one can follow which you have used? (Note: we are a software company providing solutions and consulting in domains like automotive, networks, devices, embedded, etc.)
https://news.ycombinator.com/item?id=28029344
So… which is it? Or did some employers not get the memo? Or is this tech vs non-tech positions?
I don't understand why there must be 4 different persons asking me the same questions just so in the final to give me a lower offer than we previously discussed or to ghost me.
I had a bad opinion about HR when I was a student and didn't work based on how a few of my friends and family treated, now that I'm looking for work and have to deal with their bullshit daily I literally started to hate the people working on this dep and their lack of respect.
It's endless, every little bit of concern about personality or "We did this at X." place and "Need this guys input." are added and has zero proven value, but it is added.
At one company I worked at it wasn't uncommon for a department to decide to hire someone and HR or the recruiters somehow were able to hold things up for months.
My most recent job was at a smaller (not a start up) company and as an applicant I was talking to people I would work with and was asked legitimate questions and etc.
I just had candidate that was already getting paid what would have been an insane amount a few years ago, get a counter offer that included a 20% raise and significant equity.
EDIT: now that I think about it there probably needs to be one more where you can negotiate the sallary and benefits and actually sign the contract.
I’ve never had a company string me along. Four separate phone screens or interviews seems to be the limit. I’ve even been hired after one video conference interview.
I once was given a “we want to hire you, but we need to get the funds together before we can give you the offer” spiel during the great post-mortgage economic recession, but they did hire me after about a month.
After five separate rounds (again, talking to multiple teams on the same day after one or two technical phone screens and one recruiter call doesn’t count; that’s standard practice with many companies), I would tell a company they need to either, as my father put it, “shit or get off the pot”.
In terms of take home assignments, I have no problem doing them, as long as the employer has no problem having me put my answers on a public GitHub repo. I will not do Codility tests, because my experience is that employers who do those kinds of tests are Unicorn hunters.
When I lost my job during the pandemic, I had multiple jobs I was interviewing for, each took maybe a month to get through all of the interviews. Do they really expect unemployed people to suffer through a month of interviews? Some people actually need a job fairly urgently!
And these companies I was interviewing with, they all had a fake air of superiority, like they were the next Google. This interview culture needs to change back to how it was.
Three questions I always ask are 1. What's your hiring process, 2. What's the base salary range, 3. How does the company demonstrate its commitment to ongoing learning. Any reticence to discuss these items means that I learned about how the company just isn't for me.
- Unknown
(I read this sometime back on HN and it stuck with me)
(a) You are clearly too technical, we need a more managerial experience for this role
(b) You have too much managerial experience but for this role we need a more technical person.
Similar roles in leadership area, different companies.
Recently I have asked my HR if they could set up longer meetings with candidates because, honestly, 1.5h is in my opinion not enough to evaluate candidate. I would like to ask some technical questions, I would like to see the candidate write some code, I would like to have a discussion on general tech topics just to get the feel of the candidate. And also have time to respond to questions that the candidate may have.
Usually it is the coderpad part that overflows and takes more time but it is also hugely helpful in understanding how candidate works and deals with problems.
So the response from HR was that they "don't want to scare the candidate". And if I need, maybe they will set up follow up with the candidate "just don't tell the candidate upfront to not scare them".
So that's that.
https://www.linkedin.com/posts/mike-t-conley_jobhunt2021-lea...
(Not previously discussed on HN best I can tell.)
1 week later the managerial guy called up and said ok everything went through now we can talk about the job I said "sorry, I took a job". He wished me good luck but I'm not sure from his voice if he really meant it.
I can tell you it's not an easy job to take interviews as well. I have been interviewing candidates for my company for past 4-5 years. It drains your brain a lot than giving interviews IMO. Sometimes I get exhausted and frustrated for the day after taking 4-5 interviews. start to feel, brain stops functionating. And frustrating thing is you have to provide feedback for audit purposes in more than 100 words. Especially rounds like System Design, Hands On coding, Knowledge of Technologies, Resume drilling.
Also interviews been happening continuously at least for past 2 years due to attrition issues linked of pandemic. So never ending process now a days to take interviews in the company.
All are essential, day-to-day situations any developer will find themselves in. It's difficult to replicate that in anything other than a technical interview.
Having said that, tech employers don't hold the same power they once did. Decent developers with people skills know they can always find work or just make work for themselves if need be. We're entering an era where these guys will set their own hours and pay and the employer will be the interviewee.
My CV goes back 20 years and it is quite clear about what my technical skills are. For me the most I will do is one phone interview, one HR interview and one technical interview. If the recruiter has any questions about my skills they can ask them in the technical interview and I can also put them in touch with people who can vouch for me as well.
I've experienced a few recruitment processes where there were multiple round and also take home tests that took up way to much of my time. To me the time investment required to go though these is too high as the risk of coming away with nothing is too great.
If a potential employer can't figure me out from my CV and a few interviews then I don't think that is a place I would want to work.
The expectation was that I made the example exercise + tests.
Fu*k them.
Ha, that's familiar. I'm not in the US but, during my last job hunt, I'd already accepted a job offer before some of the companies I'd applied to replied to me. Companies that are paying recruiters to bombard my inbox or paying staff bonuses to refer me.
Hiring is a very human, very broken process. There's little incentive for an individual to do it well short term but fatal repercussions if the group do it badly long term.
Whilst it was dragging, I do feel they were both adequate processes for me to learn about the companies and the role, and for them to get to know me and my fit for the team. I ended up learning quite a lot about myself, too, and got useful feedback out of the process.
It also was during the pandemic where organisations where finding their feet with remote hiring; I reckon in a pre-pandemic session, they would've been compressed into sessions together.
The scheduling, and comms about it weren't always amazing, but that's down to the recruiters rather than the hiring team, imho.
Each hour of interview costs a company ~$100, in the time of the interview alone, not to mention scheduling overhead, frustration and recruiter's time spent. 5 rounds for 5 candidates == $2,500 (1 week's salary on average at big tech beginner roles).
For each candidate, that's 5 * (whatever they are getting paid, let's say $50) == $250.
If companies think of it this way, they might as well get some candidates for short amount of time to see a fit, instead of countless rounds spanning months.
Ideally, they should also compensate interviewees for their time, which I doubt will ever happen.
Hiring should never take more than a day or two of interviews.
In fact if you spend time on leetcode , you would get a fair idea of what companies ask LC medium/hard, which ones ask Dynamic Programming and which one will specifically ask questions that are not on LC
Then they kept me hanging for a week, only so send me a rejection mail.
It might only work for low-level entrants. For higher positions you are hiring the person for their experience, not on how well they can jump through arbitrary hoops.
I didn’t mind the way it unfolded — people were busy, I wasn’t working, and it was only a couple of minutes away from me, so really it was only perhaps 8 hours. But after three weeks I felt I wasn’t getting the answers I needed and they didn’t seem to be making progress on the hire. So I said no thanks.
This was a company with 50 or so people — I have no idea how they managed to hire them.
Six weeks later, I was told I was still their preferred candidate. However they still did not offer me the job. I think they were waiting for me to make a lowball offer since the industry typically doesn't pay well for artists or the systems people.
There is a lot of pressure, if you hire the wrong person, someone has to be responsible. That's why they developed a lot of processes. So if the person turns out to be the wrong person for the job, you can tell everyone you thoroughly vetted them, and it's not your fault.
From my perspective the only way is: Interview people once or twice, hire them as quickly as possible, work with them for a few days/weeks and make a quick decision (together with the person) if it is going to work out.
I learned a lot about hiring there and how incredibly stupid and broken the standard hiring process is of big comps.
If anyone tells me to invert a binary tree now i just get up an leave haha.
But my main takeaway there was that this is actually a huuuge competitive edge Startups have. They dont have to adhere to the BS standard process and can snatch up a lot of good talent which falls out of the standard metrics.
I certainly would! More than one hour of interviewing is a sure sign of a diseased company that probably suffers from massive management overhead, internal conflict resulting in inability to make decisions or someone's complete paralysis out of fear of making wrong decisions.
You'd have to be pretty desperate wanting to start work at such a place. If not, better to keep looking and not waste your time.
As someone with 10+ years experience in the industry, I've about had it with these technicals. I'm just going to start refusing. I'm happy to have a long technical discussion on my work experience and to provide you with portfolio examples. Take your hacker rank problems and get out of here.
It's hard to establish during the interview process that someone will be able to do the job you need them to do. Hiring them is a huge risk, both legal and cultural. It's not easy to fire people, and lawsuits/arbitration are common.
The endless interview process, which costs companies many good candidates, is there because they fear the bad ones they can't recognize.
That said, for whatever reason the startups that tried to be intermediaries (and also various recruiters) tend not do very well in my experience.
It was respectful of my time. They were serious. I felt valued.
Don’t know why today’s tech companies have abandoned something that so obviously promotes good will in the new employee as well as the one passed by.
What "ruined" it for you, "made" it for me :)
I absolutely hated my CS courses in undergrad and dropped the major after 2 classes. Didn't get back around to programming until a few years later - using Google makes it way more doable.
I also doubt that companies are on purpose designing the interviews to be this long. It's probably more of the case of "more is better" thinking and no one being able to make a decision by themselves to streamline the process.
I suspect that these companies have structural problems that inhibit their decision making. Possibly also personal problems.
I also suspect that if they can't say yes after a third interview then the candidate is non-judgmentally not a good fit, by demonstration. Both parties should consider that.
I did 5 rounds over 7 hours with a top tier company recently only to loose out for my solution to one of the 3 coding tests not being as elegant as the interviewer would have liked.
I’ve been told to speak to them again in 6 months, we’ll see.
The article paints a needlessly bleak picture.
The neutral reading of the practice is, "managers are able to take riskier hiring decisions, because they are given an allowed turnover rate".
Which surprisingly enough is a solution to the ever-growing worry of false negatives in hiring - i.e., overlooking good candidates whos resume or interview did not shine strongly enough, or who perhaps are from a shunned, misunderstood culture, or who otherwise did not fit the generic hiring practice prevalent in the society. This solution allows an organization to make riskier hiring decisions at a well understood rate - hopefully catching the false negatives that did slip through competing organizations' hiring process.
--
If you “must” find a way to pick fault with your employees because you can only give out 1 “exceeds expectations” and at least 1 “meets most” then you’re likely creating a toxic environment from that.
Similar to telling managers that they “probably should” thin the herd.
I've been there 8 years and counting now, and my current job bears virtually no resemblance to what I was hired to do.
Slow pipelines mean low conversion rates (survival of the most pain tolerant), generating more internal demand. Natural reaction to to widen the pipe (more recruiters) not speed it up.
Outcome: You learn how they work, while showing that you value their time.
Does this mean that 14% of Google hires are incompetent for their role at Google?
Building companies is hella risky and hard, but if you're a senior engineer you could quite easily do it on the side
It’s tens of thousands of lines of code, in multiple shipping product form. All you need to do is clone a repo, hit “Archive,” and you have a built and App Store-ready app. Some of these apps are still on the App Store (most have been deprecated, over the years). I have full source for shipping apps (over 20), going back to 2012. I've been writing Swift -every single day-, since the day it was announced, in 2014, and have released quite a few apps, written entirely in native Swift. I'm working on a big one, right now.
Here’s an example of a repo for a currently shipping free app that is available as an iOS/iPadOS app, a Mac app, a Watch app, and a TV app. It’s a Bluetooth BLE explorer app (yes, you can sniff Bluetooth on an Apple Watch)[1], [2], [3], [4]. It uses this cross-platform Swift BLE SPM module[5].
All of the repos also include things like graphic asset originals (usually Adobe Illustrator). I’m a passably good designer. At one time, I considered becoming a professional artist.
All of my work is localizable and accessible. A number of my apps have been localized in multiple languages. These days, I also tend to do things like support Dark Mode.
I have a ton of SPM modules, tested, documented, tagged and available for immediate integration. I use most of them in my own work.
I have full source for a couple of server systems, that are in heavy use, today (I use them in my own work, and one is a worldwide standard, in use by thousands, daily).
I have dozens of blog posts, articles, tutorials, explorations and other online writings[6]. I go into great detail, how I design, test, architect, and think. Most of this stuff is extremely detailed, and comes with supporting playgrounds. I’m a fairly good writer. There’s a lot there, but it’s quite readable.
I have given instruction on technical stuff for years. The most recent one was a Zoom class on intro to Core Bluetooth, using Swift[7]. It was received well.
I don’t know if I have a single fork. I’m the original author of all of it. Since I have over a decade of commit history, across multiple public repository systems, that’s easy to prove. I also tend to have fairly informative (and frequent) checkins. It’s simple to see how I work. My GH Activity Graph is solid green[8].
My technical ability is not a matter for debate, it’s easy to see what I bring to the table (including limitations). I'm satisfied that there's lots of stuff I can do. I won't bother trying to claim abilities that I don't have.
Any interview should be only determining whether or not I’d get along, and whether or not I would be a good “personality fit.” Since I spent decades at my jobs, including at one of the most famous brands on Earth, that should also be easy to figure out. I could definitely see that some companies would not want me, but that should be simple to determine. I’m a completely open book. My LinkedIn profile is full of testimonials, by former managers, coworkers, employees, and open-source project partners.
It’s been my experience that all this has been completely ignored, in favor of ridiculous 50-line binary tree tests.
In one interview, I sent the recruiter links to several public repos of code for shipped applications, that pretty much exactly fit the requirements of the job they contacted me for. This was ignored. Instead, I was passed to an obviously bored tester, who gave me a binary tree test in a language not used by the open position, and I was dinged for not using a formulaic approach, unique to that language (which, did I mention?, was not the one used for the posted job). The repos that I had sent, were in the language that was specified in the opening.
After a few of these broken, insulting, awkward, hazing rituals, I simply gave up looking. It’s plain that no one wants me, and I won’t go where I’m not wanted. I'm fine, doing my own thing.
[0] https://stackoverflow.com/story/chrismarshall (SO Story)
[1] https://github.com/RiftValleySoftware/BlueVanClef (App Source)
[2] https://apps.apple.com/us/app/blue-van-clef-for-mobile/id151... (iOS/iPadOS App - Includes Watch App)
[3] https://apps.apple.com/us/app/blue-van-clef-for-tv/id1529181... (TV App)
[4] https://apps.apple.com/us/app/blue-van-clef/id1529005127?mt=... (Mac App)
[5] https://github.com/RiftValleySoftware/RVS_BlueThoth (BLE SPM Module)
[6] https://littlegreenviper.com/miscellany/ (Writing)
[7] https://github.com/ChrisMarshallNY/ITCB-master (Core Bluetooth Course)
[8] https://github.com/ChrisMarshallNY#github-stuff (GH ID)
It would be considered oppression if black candidate where given as many interviews as white candidates.
Actually it is a serious question. When diversity is apparent what is the difference in the number of interviews required?
Are white and asian males more scrutinized to make up for the logical shortfall of affirmative action hires that just get to mess stuff up while the asians clean up their mess?
I lost so many hours on this interview process that I would like to send them an invoice :)
Both sides of the technical recruiting transaction (job-seeking and recruiting) exhibit these behaviours and tendencies (what to wear, how to format resumes, presentation, side projects, for seekers, interviewing, tests and screens, and other filtering practices for hiring teams).
The consequence is a tremendous amount of friction, inefficiency, and fear-driven lore. Some years ago a senior Google staffer commented that they'd found a guaranteed hiring heuristic: "No". That is, reject all candidates.
My response was that if this was serious (and it was at least partially), that this was a profound sign of weakness within Google: an inability to seek out and onboard talent successfully.
There are other possibilities.
It could be that the notion of private firms hiring highly-skilled talent is inherently flawed.
I've speculated that one of the justifications for the ancient Egyptians to build pyramids was as a combination of a skills-development, skills-retention, skills-demonstration, and brain-drain-mitigation programme. From what I've read there's at least some independent informed speculation along similar lines.
One of the functions of writing a book, a notoriously unremunerative practice, is as a credible signalling of skill and ability. (And of book-writing capabilities, for what that's worth.) Books are very fat sales brochures.
In a tech world in which typical tenures are measured in months or single-digit years (2--3 years being typical from what I understand), and correlations between any hiring practices and actual performance ... at best weak, there's an inherent issue.
There's also the question of equitability of a process in which employers have vastly greater access to information on individual prospects than prospects do on companies or hiring managers / management teams. George Akerlof's "Market for Lemons" suggests that more information makes markets more efficient, though my fear is that highly asymmetric information access further tilts the employment market in the hiring firms' favour.
https://www.jstor.org/stable/1879431
http://libgen.rs/scimag/10.2307%2F1879431 Some of my earlier fad/information theoretic musing here:
https://old.reddit.com/r/dredmorbius/comments/62uroa/clothin...
Brain drain mitigation? Brain drain just wasn't a possibility 4400 years ago.
Pharonic Egypt circa 2580 was not without neighbours and there was both trade and warfare in North Africa and across the Levant and Mediterranian, notably with Syria, Canaan, Lebanon ("cedars of Lebanon" are a significant reference, as Egypt had virtually no timber), Ethiopia, and Nubia, amongst others. There's also the prospect of defection to internal factions. The Old Kingdom seems to have been generally peaceful with little internal or foreign warfare, at least until the First Intermediate Period, which was largely an internal rivalry. But it wasn't entirely without defence concerns.
https://en.wikipedia.org/wiki/Ancient_Egyptian_trade
https://www.worldhistory.org/Egyptian_Warfare/
I'm very happy to admit that my hypothesis is just that, and that there's no evidence and only a very little external support, though there is some. But if you're going to develop an advanced skill that would be of use throughout the region, it might be advisable to find ways to hold on to it, and as a pragmatic explanation for what was an absolutely immense effort ... there's some sense in the concept.
How? The only military use of large stone structures is as fortifications; their primary feature is that they can never move.
And Egypt isn't even known for its city walls. That's the other civilization of the time, ancient Mesopotamia.
But on top of all of that, none of that is a brain drain issue. You're talking about a hypothetical issue of loss of state secrets. Brain drain is the concern that the local population of skilled workers will all emigrate, leaving the country unable to do skilled work. It's not the concern that other countries may develop the technology to do the same things that you can do.
There's mathematics, surveying, architectural design, measuring, logistics, labour organisation, planning, transport, engineering, and a whole mess of related skills. If not kept in practice, they are lost (you're focusing strongly on the "brain-drain" element at the expense of "skills retention" and "skills development bits).
Too: once you've got those capabilities, there are numerous other abilities which derive from them. Large structures means civil engineering, construction, grain storage facilities, and quite probably some degree of metalworking and related crafts, again, which can prove useful in either foreign or civil war.
Take some time to think through possiblities, consequences, options, risks, and opportunities here.
Well, yeah. Look at my comment, in its entirety:
>>>> Brain drain mitigation? Brain drain just wasn't a possibility 4400 years ago.
If you can't defend that, then... don't? Make the argument that isn't obvious nonsense; you don't get more credible by throwing in a laundry list of "concepts that sound bad".
> There's mathematics, surveying, architectural design, measuring, logistics, labour organisation, planning, transport, engineering, and a whole mess of related skills. If not kept in practice, they are lost (you're focusing strongly on the "brain-drain" element at the expense of "skills retention" and "skills development bits).
There would have been no lost opportunities to exercise these skills in the absence of pyramidal efforts. They built temples, palaces, and cities on a continuous basis. Surveying is a constant need of anyone who collects taxes. (And it's particularly important in Egypt, where everyone's property lines move every year to match the extent of the flooding of the Nile.)
As far as I've read, the Old Kingdom pyramids stopped being built when the colossal economic strain they involved nearly collapsed the state. That doesn't suggest that they were useful in employing otherwise idle technicians. It also doesn't suggest that the system governing them was especially capable at logistics and planning. Planning would have involved noticing "this pyramid will cost X amount to build, which is more than we can afford".
> Large structures means civil engineering, construction, grain storage facilities, and quite probably some degree of metalworking and related crafts
I think this is backwards to a certain extent; I'd run causation from grain storage -> large structures, not the other way around.
You're the one constructing a far more magnificant pyramid of this than I'd ever intended.
The caveat: I needed to really think through the problems beforehand, understand other possible solutions, traps and potential dead ends (ie. spend time on it).
When a few years later I was asked to do some recruiting at my company (DS/R&D positions, not SE), first thing I did was to prepare a few sets of interconnected problems, to gauge the person's knowledge and how does (s)he think when encountering a new problem with all necessary tools at hand. The problems were difficult but I never expected anyone to actually solve them.
I did dome technical interviews as a candidate, being asked about random math puzzles/algos one can google in 30 sec and which are already implemented in standard libraries -- even though I usually could solve most of them I sincerely wish such interviewers would ef off and stop wasting my time. We are grown-ups, I already spent my fair share of time solving elementary riddles during high school math competitions and I'd like to be treated like a serious professional. During my years as a ML Engineer/dev I never EVER needed to implement a single tree/graph/whatever algorithm from scratch. Also, many adults have a life, family, other full-time job and grinding leetcode is not something anyone should be expected to do.
To be honest, quite a few times I doubted that the interviewer would know how to solve a similar problem without having the solution checked in company's interview problems database. Also, time pressure and stress are a buzzkiller.
As for multiple interview rounds -- a non-starter. Recently, while exploring the market, a top-tier betting company asked me to do a take home, 4h technical interview and then another long take-home (unpaid, of course). I told them that they are ridiculous and asked to never contact me again. I'm at liberty to do so as I have a job I'm happy with and zero need to actually change it, but if someone has been laid off I can see people get grinded to death -- both mentally and physically -- by such interview processes.
This is ageism. I hope he realized this after 10 6 rounds of interviews.
Like I said, not to invalidate anything, these experiences are so common amongst the whole pool that it has to be weighed accordingly.
(Not everything people say online is true.)
It wouldnt take me 700 hours to get familiar with all the abstract problems and concepts I’ll encounter, but it would take me a very long time to, and longer to synthesize solutions that are above average, and regurgitating that on the spot for an interview in a quicker time than other candidates.
The idea is to drive out older, less-pliant potential employees, in favor of newer ones, who can be molded into a shape the corporation prefers.
Have you ever seen a couple that has gotten married later in life? Many times, it may be a second (or more) time for one or both of them.
They need to make massive compromises. Both have gotten used to supporting themselves, and keeping their own counsel. They generally both have a lot of property, maybe grown kids, careers, etc. Usually, they don't actually need each other, for more than emotional support. They each do fine, on their own. It's a relationship of equals.
It can be a challenge to make it work, but when it does, it's amazing. I have known many couples like that.
I understand why corporations don't want to put effort into working with older folks, but it can be well worth it.
So many times, when I see these awful, Jurassic-scale disasters, made by companies that are staffed exclusively by younger folks, I say to myself "That was a really great idea, but they completely pooched the release. Why didn't anybody raise any red flags?"
The answer is generally, that no one on staff had enough experience to understand the ramifications of many decisions, and often, they were afraid to countermand ideas put forth by their superiors.
Couple that with 20-something CEOs, who are often fearfully insecure, and you have a recipe for disaster.
People never got any smarter, but the nature and details of group activity have changed over time.
After a career of delivering products for boutique manufacturing companies, I'd say that my ability to pass a modern interview suite is essentially nil. My last gig for a company with modern practices taught me that it's no fun in any case as design devolves into manufacturing (perhaps for good reason).
Give me a young body, and I'd look into purposefully arcane careers with little remuneration. Blacksmithing perhaps.
https://reddit.com/r/dataisbeautiful/comments/p1ba3t/oc_visu...