However, while I do sometimes feel this way, the article went on for a little while. I was sort of expecting an explanation or a twist at the end. Oh well, still good.
I'm assuming it's satire referring to those required job postings that are intended to single out a specific H1-B candidate but need to be posted anyways to satisfy the "we looked for an American and couldn't find one" requirement. They typically have very specific requirements that match the exact skillset of the intended hire to ensure that any American applying will be lacking in some required "qualification," even if it's "only has experience with software w.x.y and we require w.x.z."
Note: I'm not saying all or even most H1-Bs are hired this way, just that the scummy companies that abuse the program tend to post these kinds of job ads.
I agree that those who participate in a process like this shouldn't circumvent its rules -- that just makes the whole problem much more difficult to manage. However, I think you could just as easily argue that the process itself is scummy for requiring the job posting when a well-qualified candidate has already been identified.
Why is a candidate's country of citizenship the test for whether a role must be posted publicly before it can be filled? Wouldn't it be best for both the economy and the company if this rule were followed (without circumvention) for 100% of job openings? If your answer to that is "no," then why require it in any circumstance?
Generally because employers, either through lack of effort or deliberate attempt to shield feelings, are never clear with people about why they weren't hired after an interview.
"You flubbed the algorithm question. We're looking for someone with a stronger CS background."
Done. Clean and ultimately more kind.
... Unless a large number of candidates actually are getting rejected for sexist / racist / ageist reasons masked behind culture fit concerns, and the company obviously doesn't want to admit to that?
The main reason that candidates don't get honest feedback is to limit liability-- companies don't want hiring managers to say something horrible or misphrase something and then have them be liable for violating hiring discrimination laws.
Having been involved a bit with screening candidates, I'm not even convinced that interviewers or hiring managers are routinely clear with themselves about why they do or don't hire somebody. It seems more like a feeling that is rationalized afterward.
I strongly agree that this is true in a lot of cases, and the ahead-of-time rationalization of limiting liability helps to perpetuate the lack of necessity of a clear, defensible reason for rejection.
I say this as a hiring manager, by the way, knowing full well that nothing involving the hiring process is as clean and straightforward as anyone involved wants it to be.
> You flubbed the algorithm question. We're looking for someone with a stronger CS background.
When Triplebyte wanted me to go through their experimental interview, part of what I was asked was to "talk about" hash tables and, later, red-black trees. That seemed vague, but, prompted for what they were looking for, I covered the following:
- Hash tables are the generalization of arrays to non-integer indices. They have the access characteristics of arrays. They store data in a backing array.
- When two keys collide, the hash table can store them in a linked list (the "buckets" approach).
- If you don't like that, you can do quadratic probing, in which you repeatedly square an offset from the true hash value for that key, until you find a space in the backing array that is not currently full.
- Quadratic probing has the disadvantage that when you delete an entry from the table, you have to leave a placeholder in the backing array saying "there used to be something here!"
- If you generate an index into the backing array which is greater than its size, you would usually deal with that by taking the index modulus the size of the backing array.
- If the backing array gets too full, you would allocate a new backing array of double the size and rehash everything into the new backing array. You double the size so that amortized insert time stays constant.
- Amortized time complexity refers to the average amount of time taken for a set of completed operations.
- Red-black trees are a type of self-balancing binary tree with the property that all paths root to leaf are within a factor of two in terms of length. I can't say much more about them and wouldn't be able to write one off the top of my head.
The feedback they gave me was that, if I wanted to continue working with them, my highest priority should be to improve my knowledge of hash tables and red-black trees.
And sure, there's plenty of room for improvement in terms of red-black trees. But I am mystified as to what else they wanted for hash tables.
Were you interviewing for a position in which you'd regularly have to implement hash tables or red black trees (possibly with some novel twists) or other algorithms?
Here are a few questions that are not explicitly answered in your post.
How is the index into the array determined?
What are the best and worst cases for algorithmic complexity of a hash table?
Disclaimer:
I don't conduct interviews at my employer. If I did, I wouldn't ask about hash tables. I was asked to talk about hash tables in a Microsoft interview years ago and my accepted answer was much less detailed than yours.
Odd question. Theoretically, that choice is unique to the individual hash table, not a property of hash tables in general. I believe languages with default hash table implementations often use the machine address of the key, although obviously that won't work for keys that are compared by value, like integers and strings. I know there has been research into how to hash strings well, and I wouldn't be surprised if such research is still happening today.
> What are the best and worst cases for algorithmic complexity of a hash table?
What's a realistic worst case? A bucket-style table using linked list buckets will perform, at worst, as a linked list, except that if you add too much the backing store will be resized and everything will be rehashed. It would be quite a challenge to provide a large number of keys that all collided with each other for multiple sizes of backing array, assuming the hash function was decent. If you limit yourself to a small number of keys, the fact that you're seeing "worst-case" performance probably doesn't really matter.
Isn't that a bit of strange question to ask if you wanted someone to explain hash tables? If I brought in a candidate to interview for hash tables, I would probably expect them to already have a base covering hash functions.
Otherwise, if you go down this rabbit hole, how deep does your knowledge about the basics have to be? Do you need to know every possible hash function? Their tradeoffs? Their probability distributions? The uses for each? Implementation details?
It's easier to have a relatively objective interviewing process for technical roles. OTOH management/sales roles are usually decided on subjective criteria and on how much confidence the interviewee projects.
I've seen someone (who was highly skilled and highly qualified for the job) not get hired, simply because one of the interviewers on the board interpreted the candidate's well-founded confidence as arrogance. They deemed the candidate as a "bad culture fit" as a result.
The interviewer then recommended that we hire one of his friends instead.
I've seen this sort of thing happen all the time, at multiple companies.
A few years ago, I applied to work for Cisco, straight out of getting my Bachelor's in CS. I was extremely thankful that the hiring manager was up-front with me. She told me exactly what my lack of knowledge was, what I needed to work on, and wished me a good day. I came away from the experience feeling a little disappointed at the rejection, but ultimately encouraged and motivated to learn more about the subjects mentioned.
Problem is: how do you know she is right? The subjects mention may be irrelevant to another employer. Due diligence is recommended to see what the market is looking for.
For ambitious people it's very likely. You apply for more senior or ambitious jobs. As a result your probability of success is less per application. There will be many near misses before landing an offer you choose to accept.
The first problem is having people doing the interviewing who don't know much of anything about the work.
The second problem is from organizations so dysfunctional with everyone so irrational and afraid of nonsense criticism that they spend most of their effort covering their asses.
A third problem is an economy that is far too slow with far too many people looking for jobs.
A fourth problem is just a generally sick organization.
In a sense, these problems are good news because they give an example of an industry where even a sick-o company can still survive and even hold job interviews.
Sure, you don't want to work for such a sick organization, but, if you can, maybe you should get into that industry as a competitor!
More generally, when you see an organization that sick, and the OP was a joke but not very far from the truth, the flip side may be an opportunity!
Hmm, what's the programmer equivalent of a carpenter hanging out outside Home Depot hoping to get picked up to do some work that day? Maybe hanging outside the Apple store?
Wow, is it really so hard? I mean, is it even possible to be a decent programmer and not find work in the US? Isn't the unemployment rate for software developer like 2% ?
Depends on where you live, age experience, looks, etc. The unemployment rate is a measure of people activity looking it would not surprise me if 10% or more could not find full time work depending on region and other variables.
I'm semi-retired now, but 20+ years ago I was caught in a big internal political fight in IBM's Watson lab. Some long time managers were demoted out of management. A lot of people left. I was walked out the door.
My work was in expert systems. I was doing a lot of programming and won an award for some crucial programming work I did -- writing the code all night one night -- saving rule subroutines in our AI language. I published peer-reviewed papers in expert systems, applied math, and mathematical statistics.
I was and long had been good at programming and computer science, several operating systems, languages, many algorithms, lots of applied math software, etc. I'd taught computer science in ugrad school at Georgetown and in grad school at Ohio State University.
I sent 1000 resumes and got essentially nothing. My location was 70 miles north of Wall Street, and I was willing to move anywhere.
In wildly strong contrast, early in my career in software and applied math within 100 miles of the Washington Monument, once a sent a few resume copies and soon in two weeks I went on seven interviews and got five offers, all with nice raises. Soon I was making in annual salary six times what a new, high end Camaro cost.
IMHO, the idea that there is a lot of demand for people in computing, software, algorithms, etc. is just hype and hog wash.
But I'm still good at applied math and associated software so am doing a startup. I have to please my users and, thus, my advertisers, but no way do I have to please an HR assistant, an HR phone screen person, an HR interviewer, or a hiring manager.
I've typed in 100,000 lines of typing with 24,000 programming language statements (lots of internal documentation), nearly all in Visual Basic .NET with ADO.NET and ASP.NET. There is a redundantly reliable and scalable software and server farm architecture with a Web server, a Web session state server (instead of Redis, I wrote my own, just TCP/IP sockets, single threaded, using the TCP/IP queue as the queue of arriving work, object instance de/serialization, and two instances of a standard .NET collection class -- simple, fast, small, works great), two specialized compute servers with my original applied math. It all appears to run as intended. For production I don't like the log file approach I took based on what Microsoft has, so I intend to take my session state server, rip out the collection classes, put in a write to a file, and, presto, get a log server. The servers all communicate with just simple TCP/IP sockets.
I identified the problem, designed the Web site, designed the architecture, designed, wrote, debugged, timed, and documented the code, and got it all to appear to work. Alpha test in progress now.
I'm a native born US citizen, have held security clearances at least as high as Secret, have never been arrested, have never been charged with any crime except for minor traffic violations, am in excellent health (now for my age), but have to say that for the past 30 years I've been absolutely, positively, totally unemployable for anything having to do with computing.
A shortage of people in computing? What a really bad joke.
Well, 20 years ago the landscape was completely different, I can believe the job market changes, and maybe in 20 years I'll find it hard for me to get a job. But currently, the landscape has never been better in my opinion.
Are you saying even today you're unemployable? How can that be? Unless you left some information about your credential out, like being incredibly annoying or some personality trait that would clearly reveal itself on the interview.
I mean, I believe you 100% if you say that you've tried to apply for work today, and couldn't get any offer after hundred of interviews, and that you're a pleasant person, and the whole thing is bad luck and that there are in fact less jobs then you hear, but I'd want to know more details. How can a pleasant person with your experience not find work in the current market? Is it agism?
Likely. Maybe Wal-Mart would hire me to stock shelves. In computing, essentially unemployable and have been since 1994. Long time.
Ah, along the way, I heard of a guy and several of his buddies who had, from a sudden change in some banking laws, found a hot resource allocation problem and, supposedly, some eager high end customers -- big banks. They had formulated the problem as a large 0-1 integer linear programming problem but gave up on using a linear programming package. So, they tried simulated annealing. They ran for days, quit when tired, took the best solution they'd found, and called it done without much information about how far they were from optimality. They mailed me their 0-1 integer linear programming (ILP) formulation. I looked at it, thought I saw a path forward with some non-linear duality theory (in some senses, amazing stuff), did some derivations, the told them that I'd have a little in a few days and all of it in about two weeks. I did. I typed in Fortran code so that for some of the work I could call the IBM Optimization Subroutine Library for linear programming, callable from a certain Watcom Fortran compiler I had. My code ran right away. On their test problem 40,000 constraints and 600,000 variables, all 0-1, on a slow computer I got a feasible solution the duality said was within 0.025% of optimality in 905 seconds. I wrote them back with the good news but never heard from them again. There was something about they were just going on vacation. Uh, the guy who had done the simulated annealing work wasn't thrilled that I might work on the problem. They had paid me nothing, so I wrote letters to the candidate banks and heard back nothing.
There was another, similar case: The problem was the old one of which pharmaceutical salesmen should go to which physicians and leave what samples. Surprisingly I found a network integer linear programming formulation -- there get integer programming for free. I was writing the code in portable Fortran, since that seemed to be the effective approach, when a guy in the company who had an old heuristic wanted to get rid of me, and did.
Agism is a lot of it.
IMHO, broadly a CIO wants a lot of worker bees age 20 - 35 and manager bees older. As worker bees approach age 35, a tiny fraction are promoted into management and the rest fired. No way do they want to hire worker bees over 40; certainly not at 45, never but never at 50. The above is broad but IMHO roughly the situation.
Really, a guy 20 would be better off starting a grass mowing service, with one lawn mower, grow the business to several mowers, trucks, and crews, expand into landscape architecture and commercial clients, and by age 35 own a nice business he could keep running as long as his health held out and pass the business down to his children. Just grass mowing.
Or, a guy in computing at age 30 should think seriously about being founder of a startup. No, call that age 25 -- heck, call it age 20.
I'm no longer looking for a salaried job in computing and, instead, am concentrating on my startup.
I was pleasant enough a person early in my a career when I could get a better job anytime in two weeks. Now my skills with people are much better.
IMHO, being a worker bee in computing is a long walk on a short pier. The field might be a profession like law, medicine, or some fields of engineering, but is not. So, there's next to nothing in professional certification, government licensing, professional peer review, legal liability, etc. From all I've seen, nursing works out better -- can continue to be a worker bee level nurse as long as can do the work. School teaching is better once get something like tenure.
I don't know how to solve the problem except just to leave it and, as in my case, do a startup. I can still do computing -- my startup software with 24,000 programming language statements in 100,000 lines of typing seem to work as intended, and I did it all ...
> My work was in expert systems. I was doing a lot of programming and won an award for some crucial programming work I did -- writing the code all night one night -- saving rule subroutines in our AI language. I published peer-reviewed papers in expert systems, applied math, and mathematical statistics.
I was and long had been good at programming and computer science, several operating systems, languages, many algorithms, lots of applied math software, etc. I'd taught computer science in ugrad school at Georgetown and in grad school at Ohio State University.
I sent 1000 resumes and got essentially nothing.
Interesting tale. Most people of your talents and eminence have a network of hundreds of people that they can tap into for assistance. What happened?
I sent resume copies, formatted beautifully with TeX, simply as just text in e-mail, with lots of detail, medium detail, very little detail, etc. with backspin, topspin,
overhand, side arm, etc., and nearly never heard back. I got a few phone screen calls, and never heard back. I got a few interviews, but they never led to anything.
At Morgan Stanley, I showed some research I'd done in high end, multi-variate, distribution-free, adaptive ("Look, Ma, no tuning!"), real time anomaly detection (for problems never seen before), and a Unix system administrator, responsible for 5000 systems, had just come from a meeting about how the heck to do that. Hearing a little about my work, he exclaimed "We can use that right away!". Didn't lead to a job offer. I explained my work to another guy there, and he was just convinced that my work just had to be cluster analysis, and I explained that maybe there would be clusters and maybe not, but my work had nothing to do with clusters. My work was original. An expert in statistical monitoring exclaimed "radical, provocative". But it's also correct, passed peer-review, and got published. I was suggesting that the work might be of
value in automatic trading where are looking for events or anomalies as triggers to exploit. The reaction that might write some code to automate trading fell flat with that guy.
My Ph.D. dissertation was in stochastic optimal control, but that cut no ice on Wall Street.
I have an excellent background in probability and stochastic processes from a star student of E. Cinlar, long the main guy at Princeton for
math for automating trading on Wall Street -- still, zip, zilch, and zero interest.
They just weren't interested.
It appears that for a short time, Wall Street had some interest in Brownian motion, stochastic differential equations, etc. mostly just to better understand the Black-Scholes formula but maybe also to do more on designing or pricing exotic options, but my guess is that those days were few and now long past.
I've got a solid background to dig into Karatzas and Shreve, H. McKean, E. Wong, etc., but I'm not going to set up a hedge fund and just didn't want to spend some months with that material, I like very much, without some hints that Wall Street would care. I didn't know about James Simons at the time (although he was recruiting heavily from the IBM Watson lab I was in) and still don't know enough about his approach, maybe mostly triggers, to know if he would be interested in Karatzas and Shreve etc.
Bottom line: No interest.
I don't know why.
On knowing a bunch of people, apparently I don't know enough of the right people!
At this point it is much easier and much more promising just to do a startup.
Here is my guess: Organizations really don't like to hire anyone in computing over 35. By age 50, no way. What they want is a lot of people under 35 and, then,
promote maybe 1 in 50 of those to management and fire the rest by age 35-40 or so. They just don't want experienced worker bees.
> Organizations really don't like to hire anyone in computing over 35. By age 50, no way.
52. Just got a new job less than six months ago, with one of my biggest salary and total-compensation bumps ever. So I'd have to say my sample of one differs from yours.
> They just don't want experienced worker bees.
No, they don't. They can find plenty of worker bees. At 10+ years of experience (and associated salary) they expect some very general kinds of skills - e.g. evangelizing an idea, mentoring others - and probably some very domain-specific ones as well. Above all, they're usually looking for someone who can be the core of a team, not just one of its members. Can you be that person? I have no idea. What I will say is that what you've presented here does not support that case. I could say more, but don't want to give offense. The only point I'm trying to make is that "experienced worker bee" is not a much-sought role. The jobs go to those who are something else, and who present as something else.
By "worker bee" I meant someone not in management.
No one knows everything: (1) Designing, growing, and managing the LAN for AWS? Well, if haven't been specializing in that for the last 10 years, then call Cisco, some network systems management vendors, etc., and hope that the company will wait as you become an expert in that work. (2) Same for the AWS connections to the Internet points of presence. (3) Large scale C++ programming, from design and documentation through testing, deployment, and bug tracking and fixing; again would want some years doing just such work. (4) Configuration and management of large scale use of virtual machine? If haven't been doing a lot of that recently, then call VMWare and hope that you will have time to become an expert. (5) Large scale front end Web site programming with hundreds, maybe thousands, of Web pages, sending thousands of pages a second, writing, updating pages continually, many a day, lots of details about JavaScript, getting bugs out, making it fast enough, getting it tested and documented, making sure it runs the same on lots of Web browsers, arranging the CDN help, working with Akamai on stopping DDOS attacks, making the security good enough for a big financial institution, keeping up on security threats, etc., working with the Web site back end staff to make the site fast enough. A lot of work, managing lots of work and people. Better have been concentrating on that, especially for financial services, for the past 15 years. (6) Handling system management, installations, updates, monitoring, security, performance, designs for growth for a large server farm -- better have been doing that for 15 years, with some one operating system family, and grown up in that work as server farms grew at Amazon, Microsoft, Google, Facebook, etc.
See, there are a lot of narrow specializations. For each of them, for the high level positions, need to have been specializing in those for years. Then with that career track, there is a big risk: That specialization may shrink or die. Then don't have comparable experience in another such narrow specialization and are in career trouble. Nursing and K-12 school teaching are much more stable.
I was willing to do whatever for a salary that would let me live without losing money. E.g., at IBM, cost of living was so high, commuting distances so long and expensive, and salary so low that I actually lost money working there. Heck, I saved money working myself and my wife through our Ph.D. degrees but lost money working at IBM. I can't afford to take a job that costs me money.
I am highly qualified in some specializations. For nearly everything that people hope to get from AI/ML now, my background and track record is highly superior. E.g., not many people want to do curve fitting with 1 million variables and 100 trillion observations! So, right, I've never programmed a high end NVIDIA GPU for curve fitting! For data science, my background, education, accomplishments, are superior, by a LOT.
But, generally, an organization should expect a new hire to learn over some months about the specific, narrow topics of importance at that organization. Then what is needed is a good, broad background, all the way from assembler, ring security and gate segments, capabilities and attribute control lists, enough in number theory to understand RSA, PKI, and VPNs, etc., and I have that. It remains, for analytical work, now likely considered part of data science, optimization, simulation, and control remain among the most powerful tools, and I'm quite good with those. E.g., going to do supply chain optimization with AI/ML? Not a chance! Usually it's a problem in stochastic dynamic programming. How many data science people know that? I do.
Here's one: A company wanted some revenue projections. AI, ML, data science? F'get about it! What was known? (A) The current revenue. (B) The revenue at the planned maximum share of the market. That was i...
I had a recruiter from Intel contact me recently, for a job that I seemingly had all the qualifications for. After a brief phone exchange she told me I was a great candidate and that I was what they were looking for. If the hiring manager agreed, I would be invited for a formal interview. Two weeks later I got an email saying I was not selected, the hiring manager did not agree, for reasons that will forever remain a mystery to me.
Thank you for sharing your story. Happened to me several times too. Once I received a rejection letter with 200 other candidates in CC list. We had a good conversation with each others.
It's true but it's also an opportunity. Somebody is going to capitalize on this in one of those a recruiting as a service businesses and they are going to get outsized candidate flow because of how hungry people are for some actionable rejection feedback.
I've had recruiters call me up and say that my rèsumè looked perfect and they were looking for someone just like me, but five years younger -- and did I know anyone who was looking who fit that bill.
What I never figured out is how could someone have my exact skill set and knowledge and yet be five years younger -- they started hacking about with computers in 1982 when they were just ten years old?
I used to work in a digital agency for a few years, they often used to refer to this "mythical" awesome junior; i,e, a very smart and super talented kid just out of uni to stupid to understand his salary expectations.
The reality I've learned from hiring a lot of people over the years is that recruiting is just not an objective process, no matter how much candidates and employers want it to be. I've often thought it's a bit analogous to dating. If you've ever had a close friend try to set you up with someone, you've definitely experienced it. Your friend will tell you how this other person meets all your criteria and you will be perfect for each other! You get all excited and then you meet the person and it's just a big letdown. Objectively you should be ready to tie the knot next week. But subjectively it's just not right for reasons you can't even always explain.
I've learned that if I'm not excited about getting a candidate an offer letter ASAP, it's likely they're not a good fit. If I have to talk myself into someone and make a list of pro's and con's, they're usually a bad fit.
I think you're right about what hiring typically is, but you transition to accepting it as correct too easily. The evidence for interviewing suggests that IQ testing, work product testing, and structured interviewing are the most effective techniques for identifying high performers. While of course nothing is truly 100% objective, those are certainly more objective than relying on excitement or gut feeling.
Huh. I guess I'm the only one who saw this as a thinly-veiled reference to how female/minority candidates feel when they're turned down for jobs. Not saying it's right or wrong for anyone to feel that way, or even whether the satire was effective/funny, but that's how I interpreted it.
When this happens I can't help but jump to the conclusion, perhaps erroneously, that it was something personal about me. Especially when you apply for a job that you are a perfect fit for, but never hear another word from the company. Was it my name? My gender? It's so elusive.
I feel like hiring is so much like gamble. Lot of time, the hiring manager clearly express I should get an offer or a request for next interview the next days. Only to have radio silent and rejected letter 1-2 week later even me follow up with them.
It seems like hiring requires a lot of decisions from multiple people. And they want to be safe, so all have to give a yes.
If you're not sure what this piece is about and suspect the joke is on you, welcome to The New Yorker's brand of humor. I feel this way about most of their cartoons as well.
73 comments
[ 6.9 ms ] story [ 187 ms ] threadHowever, while I do sometimes feel this way, the article went on for a little while. I was sort of expecting an explanation or a twist at the end. Oh well, still good.
Note: I'm not saying all or even most H1-Bs are hired this way, just that the scummy companies that abuse the program tend to post these kinds of job ads.
Why is a candidate's country of citizenship the test for whether a role must be posted publicly before it can be filled? Wouldn't it be best for both the economy and the company if this rule were followed (without circumvention) for 100% of job openings? If your answer to that is "no," then why require it in any circumstance?
"You flubbed the algorithm question. We're looking for someone with a stronger CS background."
Done. Clean and ultimately more kind.
... Unless a large number of candidates actually are getting rejected for sexist / racist / ageist reasons masked behind culture fit concerns, and the company obviously doesn't want to admit to that?
I say this as a hiring manager, by the way, knowing full well that nothing involving the hiring process is as clean and straightforward as anyone involved wants it to be.
When Triplebyte wanted me to go through their experimental interview, part of what I was asked was to "talk about" hash tables and, later, red-black trees. That seemed vague, but, prompted for what they were looking for, I covered the following:
- Hash tables are the generalization of arrays to non-integer indices. They have the access characteristics of arrays. They store data in a backing array.
- When two keys collide, the hash table can store them in a linked list (the "buckets" approach).
- If you don't like that, you can do quadratic probing, in which you repeatedly square an offset from the true hash value for that key, until you find a space in the backing array that is not currently full.
- Quadratic probing has the disadvantage that when you delete an entry from the table, you have to leave a placeholder in the backing array saying "there used to be something here!"
- If you generate an index into the backing array which is greater than its size, you would usually deal with that by taking the index modulus the size of the backing array.
- If the backing array gets too full, you would allocate a new backing array of double the size and rehash everything into the new backing array. You double the size so that amortized insert time stays constant.
- Amortized time complexity refers to the average amount of time taken for a set of completed operations.
- Red-black trees are a type of self-balancing binary tree with the property that all paths root to leaf are within a factor of two in terms of length. I can't say much more about them and wouldn't be able to write one off the top of my head.
The feedback they gave me was that, if I wanted to continue working with them, my highest priority should be to improve my knowledge of hash tables and red-black trees.
And sure, there's plenty of room for improvement in terms of red-black trees. But I am mystified as to what else they wanted for hash tables.
If not, why were you even asked these questions?
How is the index into the array determined?
What are the best and worst cases for algorithmic complexity of a hash table?
Disclaimer:
I don't conduct interviews at my employer. If I did, I wouldn't ask about hash tables. I was asked to talk about hash tables in a Microsoft interview years ago and my accepted answer was much less detailed than yours.
Edited to add an adjective.
Odd question. Theoretically, that choice is unique to the individual hash table, not a property of hash tables in general. I believe languages with default hash table implementations often use the machine address of the key, although obviously that won't work for keys that are compared by value, like integers and strings. I know there has been research into how to hash strings well, and I wouldn't be surprised if such research is still happening today.
> What are the best and worst cases for algorithmic complexity of a hash table?
What's a realistic worst case? A bucket-style table using linked list buckets will perform, at worst, as a linked list, except that if you add too much the backing store will be resized and everything will be rehashed. It would be quite a challenge to provide a large number of keys that all collided with each other for multiple sizes of backing array, assuming the hash function was decent. If you limit yourself to a small number of keys, the fact that you're seeing "worst-case" performance probably doesn't really matter.
What is a hash function?
Edited to omit needless words.
Otherwise, if you go down this rabbit hole, how deep does your knowledge about the basics have to be? Do you need to know every possible hash function? Their tradeoffs? Their probability distributions? The uses for each? Implementation details?
The interviewer then recommended that we hire one of his friends instead.
I've seen this sort of thing happen all the time, at multiple companies.
"If Carpenters Were Hired Like Programmers"
http://www.jasonbock.net/jb/News/Item/7c334037d1a9437d9fa650...
https://news.ycombinator.com/item?id=7819413
The first problem is having people doing the interviewing who don't know much of anything about the work.
The second problem is from organizations so dysfunctional with everyone so irrational and afraid of nonsense criticism that they spend most of their effort covering their asses.
A third problem is an economy that is far too slow with far too many people looking for jobs.
A fourth problem is just a generally sick organization.
In a sense, these problems are good news because they give an example of an industry where even a sick-o company can still survive and even hold job interviews.
Sure, you don't want to work for such a sick organization, but, if you can, maybe you should get into that industry as a competitor!
More generally, when you see an organization that sick, and the OP was a joke but not very far from the truth, the flip side may be an opportunity!
That's right on the money. So true.
My work was in expert systems. I was doing a lot of programming and won an award for some crucial programming work I did -- writing the code all night one night -- saving rule subroutines in our AI language. I published peer-reviewed papers in expert systems, applied math, and mathematical statistics.
I was and long had been good at programming and computer science, several operating systems, languages, many algorithms, lots of applied math software, etc. I'd taught computer science in ugrad school at Georgetown and in grad school at Ohio State University.
I sent 1000 resumes and got essentially nothing. My location was 70 miles north of Wall Street, and I was willing to move anywhere.
In wildly strong contrast, early in my career in software and applied math within 100 miles of the Washington Monument, once a sent a few resume copies and soon in two weeks I went on seven interviews and got five offers, all with nice raises. Soon I was making in annual salary six times what a new, high end Camaro cost.
IMHO, the idea that there is a lot of demand for people in computing, software, algorithms, etc. is just hype and hog wash.
But I'm still good at applied math and associated software so am doing a startup. I have to please my users and, thus, my advertisers, but no way do I have to please an HR assistant, an HR phone screen person, an HR interviewer, or a hiring manager.
I've typed in 100,000 lines of typing with 24,000 programming language statements (lots of internal documentation), nearly all in Visual Basic .NET with ADO.NET and ASP.NET. There is a redundantly reliable and scalable software and server farm architecture with a Web server, a Web session state server (instead of Redis, I wrote my own, just TCP/IP sockets, single threaded, using the TCP/IP queue as the queue of arriving work, object instance de/serialization, and two instances of a standard .NET collection class -- simple, fast, small, works great), two specialized compute servers with my original applied math. It all appears to run as intended. For production I don't like the log file approach I took based on what Microsoft has, so I intend to take my session state server, rip out the collection classes, put in a write to a file, and, presto, get a log server. The servers all communicate with just simple TCP/IP sockets.
I identified the problem, designed the Web site, designed the architecture, designed, wrote, debugged, timed, and documented the code, and got it all to appear to work. Alpha test in progress now.
I'm a native born US citizen, have held security clearances at least as high as Secret, have never been arrested, have never been charged with any crime except for minor traffic violations, am in excellent health (now for my age), but have to say that for the past 30 years I've been absolutely, positively, totally unemployable for anything having to do with computing.
A shortage of people in computing? What a really bad joke.
Are you saying even today you're unemployable? How can that be? Unless you left some information about your credential out, like being incredibly annoying or some personality trait that would clearly reveal itself on the interview.
I mean, I believe you 100% if you say that you've tried to apply for work today, and couldn't get any offer after hundred of interviews, and that you're a pleasant person, and the whole thing is bad luck and that there are in fact less jobs then you hear, but I'd want to know more details. How can a pleasant person with your experience not find work in the current market? Is it agism?
Likely. Maybe Wal-Mart would hire me to stock shelves. In computing, essentially unemployable and have been since 1994. Long time.
Ah, along the way, I heard of a guy and several of his buddies who had, from a sudden change in some banking laws, found a hot resource allocation problem and, supposedly, some eager high end customers -- big banks. They had formulated the problem as a large 0-1 integer linear programming problem but gave up on using a linear programming package. So, they tried simulated annealing. They ran for days, quit when tired, took the best solution they'd found, and called it done without much information about how far they were from optimality. They mailed me their 0-1 integer linear programming (ILP) formulation. I looked at it, thought I saw a path forward with some non-linear duality theory (in some senses, amazing stuff), did some derivations, the told them that I'd have a little in a few days and all of it in about two weeks. I did. I typed in Fortran code so that for some of the work I could call the IBM Optimization Subroutine Library for linear programming, callable from a certain Watcom Fortran compiler I had. My code ran right away. On their test problem 40,000 constraints and 600,000 variables, all 0-1, on a slow computer I got a feasible solution the duality said was within 0.025% of optimality in 905 seconds. I wrote them back with the good news but never heard from them again. There was something about they were just going on vacation. Uh, the guy who had done the simulated annealing work wasn't thrilled that I might work on the problem. They had paid me nothing, so I wrote letters to the candidate banks and heard back nothing.
There was another, similar case: The problem was the old one of which pharmaceutical salesmen should go to which physicians and leave what samples. Surprisingly I found a network integer linear programming formulation -- there get integer programming for free. I was writing the code in portable Fortran, since that seemed to be the effective approach, when a guy in the company who had an old heuristic wanted to get rid of me, and did.
Agism is a lot of it.
IMHO, broadly a CIO wants a lot of worker bees age 20 - 35 and manager bees older. As worker bees approach age 35, a tiny fraction are promoted into management and the rest fired. No way do they want to hire worker bees over 40; certainly not at 45, never but never at 50. The above is broad but IMHO roughly the situation.
Really, a guy 20 would be better off starting a grass mowing service, with one lawn mower, grow the business to several mowers, trucks, and crews, expand into landscape architecture and commercial clients, and by age 35 own a nice business he could keep running as long as his health held out and pass the business down to his children. Just grass mowing.
Or, a guy in computing at age 30 should think seriously about being founder of a startup. No, call that age 25 -- heck, call it age 20.
I'm no longer looking for a salaried job in computing and, instead, am concentrating on my startup.
I was pleasant enough a person early in my a career when I could get a better job anytime in two weeks. Now my skills with people are much better.
IMHO, being a worker bee in computing is a long walk on a short pier. The field might be a profession like law, medicine, or some fields of engineering, but is not. So, there's next to nothing in professional certification, government licensing, professional peer review, legal liability, etc. From all I've seen, nursing works out better -- can continue to be a worker bee level nurse as long as can do the work. School teaching is better once get something like tenure.
I don't know how to solve the problem except just to leave it and, as in my case, do a startup. I can still do computing -- my startup software with 24,000 programming language statements in 100,000 lines of typing seem to work as intended, and I did it all ...
I was and long had been good at programming and computer science, several operating systems, languages, many algorithms, lots of applied math software, etc. I'd taught computer science in ugrad school at Georgetown and in grad school at Ohio State University.
I sent 1000 resumes and got essentially nothing.
Interesting tale. Most people of your talents and eminence have a network of hundreds of people that they can tap into for assistance. What happened?
I sent resume copies, formatted beautifully with TeX, simply as just text in e-mail, with lots of detail, medium detail, very little detail, etc. with backspin, topspin, overhand, side arm, etc., and nearly never heard back. I got a few phone screen calls, and never heard back. I got a few interviews, but they never led to anything.
At Morgan Stanley, I showed some research I'd done in high end, multi-variate, distribution-free, adaptive ("Look, Ma, no tuning!"), real time anomaly detection (for problems never seen before), and a Unix system administrator, responsible for 5000 systems, had just come from a meeting about how the heck to do that. Hearing a little about my work, he exclaimed "We can use that right away!". Didn't lead to a job offer. I explained my work to another guy there, and he was just convinced that my work just had to be cluster analysis, and I explained that maybe there would be clusters and maybe not, but my work had nothing to do with clusters. My work was original. An expert in statistical monitoring exclaimed "radical, provocative". But it's also correct, passed peer-review, and got published. I was suggesting that the work might be of value in automatic trading where are looking for events or anomalies as triggers to exploit. The reaction that might write some code to automate trading fell flat with that guy.
My Ph.D. dissertation was in stochastic optimal control, but that cut no ice on Wall Street.
I have an excellent background in probability and stochastic processes from a star student of E. Cinlar, long the main guy at Princeton for math for automating trading on Wall Street -- still, zip, zilch, and zero interest.
They just weren't interested.
It appears that for a short time, Wall Street had some interest in Brownian motion, stochastic differential equations, etc. mostly just to better understand the Black-Scholes formula but maybe also to do more on designing or pricing exotic options, but my guess is that those days were few and now long past.
I've got a solid background to dig into Karatzas and Shreve, H. McKean, E. Wong, etc., but I'm not going to set up a hedge fund and just didn't want to spend some months with that material, I like very much, without some hints that Wall Street would care. I didn't know about James Simons at the time (although he was recruiting heavily from the IBM Watson lab I was in) and still don't know enough about his approach, maybe mostly triggers, to know if he would be interested in Karatzas and Shreve etc.
Bottom line: No interest.
I don't know why.
On knowing a bunch of people, apparently I don't know enough of the right people!
At this point it is much easier and much more promising just to do a startup.
Here is my guess: Organizations really don't like to hire anyone in computing over 35. By age 50, no way. What they want is a lot of people under 35 and, then, promote maybe 1 in 50 of those to management and fire the rest by age 35-40 or so. They just don't want experienced worker bees.
52. Just got a new job less than six months ago, with one of my biggest salary and total-compensation bumps ever. So I'd have to say my sample of one differs from yours.
> They just don't want experienced worker bees.
No, they don't. They can find plenty of worker bees. At 10+ years of experience (and associated salary) they expect some very general kinds of skills - e.g. evangelizing an idea, mentoring others - and probably some very domain-specific ones as well. Above all, they're usually looking for someone who can be the core of a team, not just one of its members. Can you be that person? I have no idea. What I will say is that what you've presented here does not support that case. I could say more, but don't want to give offense. The only point I'm trying to make is that "experienced worker bee" is not a much-sought role. The jobs go to those who are something else, and who present as something else.
No one knows everything: (1) Designing, growing, and managing the LAN for AWS? Well, if haven't been specializing in that for the last 10 years, then call Cisco, some network systems management vendors, etc., and hope that the company will wait as you become an expert in that work. (2) Same for the AWS connections to the Internet points of presence. (3) Large scale C++ programming, from design and documentation through testing, deployment, and bug tracking and fixing; again would want some years doing just such work. (4) Configuration and management of large scale use of virtual machine? If haven't been doing a lot of that recently, then call VMWare and hope that you will have time to become an expert. (5) Large scale front end Web site programming with hundreds, maybe thousands, of Web pages, sending thousands of pages a second, writing, updating pages continually, many a day, lots of details about JavaScript, getting bugs out, making it fast enough, getting it tested and documented, making sure it runs the same on lots of Web browsers, arranging the CDN help, working with Akamai on stopping DDOS attacks, making the security good enough for a big financial institution, keeping up on security threats, etc., working with the Web site back end staff to make the site fast enough. A lot of work, managing lots of work and people. Better have been concentrating on that, especially for financial services, for the past 15 years. (6) Handling system management, installations, updates, monitoring, security, performance, designs for growth for a large server farm -- better have been doing that for 15 years, with some one operating system family, and grown up in that work as server farms grew at Amazon, Microsoft, Google, Facebook, etc.
See, there are a lot of narrow specializations. For each of them, for the high level positions, need to have been specializing in those for years. Then with that career track, there is a big risk: That specialization may shrink or die. Then don't have comparable experience in another such narrow specialization and are in career trouble. Nursing and K-12 school teaching are much more stable.
I was willing to do whatever for a salary that would let me live without losing money. E.g., at IBM, cost of living was so high, commuting distances so long and expensive, and salary so low that I actually lost money working there. Heck, I saved money working myself and my wife through our Ph.D. degrees but lost money working at IBM. I can't afford to take a job that costs me money.
I am highly qualified in some specializations. For nearly everything that people hope to get from AI/ML now, my background and track record is highly superior. E.g., not many people want to do curve fitting with 1 million variables and 100 trillion observations! So, right, I've never programmed a high end NVIDIA GPU for curve fitting! For data science, my background, education, accomplishments, are superior, by a LOT.
But, generally, an organization should expect a new hire to learn over some months about the specific, narrow topics of importance at that organization. Then what is needed is a good, broad background, all the way from assembler, ring security and gate segments, capabilities and attribute control lists, enough in number theory to understand RSA, PKI, and VPNs, etc., and I have that. It remains, for analytical work, now likely considered part of data science, optimization, simulation, and control remain among the most powerful tools, and I'm quite good with those. E.g., going to do supply chain optimization with AI/ML? Not a chance! Usually it's a problem in stochastic dynamic programming. How many data science people know that? I do.
Here's one: A company wanted some revenue projections. AI, ML, data science? F'get about it! What was known? (A) The current revenue. (B) The revenue at the planned maximum share of the market. That was i...
Consider breakups. The Seinfeld classic "It's not you, it's me" is hilarious because it touches this truism.
Move on.
What I never figured out is how could someone have my exact skill set and knowledge and yet be five years younger -- they started hacking about with computers in 1982 when they were just ten years old?
It's usually all about money, not age.
I've even made it to a final interview where they flew me across the country, only to tell me that there's no funding for the position
I wish I could work as a hiring manager for a year just to see all the crazy stuff I've experienced from the other end
I've learned that if I'm not excited about getting a candidate an offer letter ASAP, it's likely they're not a good fit. If I have to talk myself into someone and make a list of pro's and con's, they're usually a bad fit.
That's a pretty good rule, I'd say. There's a more generic and shorter version too, which I tend to use:
If there's any doubt, there's no doubt.
That's my only takeaway from this.
It seems like hiring requires a lot of decisions from multiple people. And they want to be safe, so all have to give a yes.