Lessons learned from the recent job hunt

Western EU thing as well. There's an oversupply of candidates (everyone wants move/live here) and a low supply of jobs (in some countries), so companies can afford to be very picky.

Eastern EU has the opposite phenomenon, oversupply of jobs due to outsourcing/nearshoring coming in, and lack of skilled candidates since may skilled ones moved west.

The overwhelming majority of companies simply ghosted my application – Spotify, Atlassian, ADP, Lyft, Stripe, and Squarespace were all applications I made in one week, none of whom ever responded.

Hopefully I'll be closer to 1:1 once I've got 20 years under my belt ;)

I'm nothing special. But I do learn a little about each company I'm applying to and tailor my resume to each position. If possible I develop an internal contact so I can get some informal information on the position from the inside in advance. I only had inside contacts for two of the companies last time though.

I can't imagine doing that for 100+ companies like some people apply to. I have to imagine most people applying to that many are just doing a spray-and-pray method.

Or maybe advertising themselves but not selling themselves. In some cases a 2% conversion rate is a decent goal for a marketer advertising to the general public, but would be pretty bad for a salesman getting commission from personalized sales.

I'm no salesman, but approach the job hunt like an enterprise salesman who needs to land a good account with a good commission to live on.

Tech stocks are down a ridiculous amount and funding for startups is now much harder to come by. Probably other factors I don't know about as well.

- time vs. space tradeoffs

- insert vs. select tradeoffs

- Oh yeah they're binary trees also, with those implications

- What's reasonably distributable (downsides of UUIDs)

- at what point might you have query performance issues you can address w/ indexes

But like, again practically speaking I think this is just an experience test question. I think I'd prefer something like "on your resume you have Postgres experience dating back 7 years, tell me what you think about it, what its strengths and weaknesses are, and why you would or wouldn't use it".

---

Maybe you have thoughts about this too, but I'm also starting to develop some thoughts around whether to consider interviews quizzes/tests or conversations. Thinking about it, I've always approached my interviews (on both sides of the table) as conversations--even questions with simple answers. I guess that's why my answer here is "this should be a discussion about databases" and less "table scans vs. index scans in 30 seconds go". It's totally OK to drill down into specifics and be technical, but this is potentially your first interaction with a new colleague, and you should be collegial, not domineering and inscrutable right? I think we get so worried about hiring a faker that we justify anything to avoid it.

And it’s far more common, and more dangerous, in my experience, to see a loop that assumes it must eventually reach a terminal condition that isn’t actually guaranteed.

I just don’t think the risk of hiring someone who misestimates the time complexity of an algorithm is sufficiently great that it’s worth explicitly filtering for. Why is this the one piece of hard won experience or academic knowledge that we need a candidate to have before they join our company, given that it’s something that can be taught in a single CS101 lecture, and in practical terms, something I can explain to a competent developer in about ten minutes?

Ironically i suck at Big O notation itself. So maybe i under value it.

Which programming language is low level that need that kind of understanding? (Obviously all of them, but I still need the answer)

Maybe change the problem to an array of ints. It's the same solution but you will not have anyone asking about UTF and text direction.

Whether programmers like it or not, live coding has become a standard for interviews these days. I can see anyone still unfamiliar with this doing poorly, I used to do awful at these until I realized this is just part of the game, but it's not unreasonable to expect candidates to be able to do whiteboard/live coding.

However, you just sitting in the other room, tells me you also have a lot to learn about the structure of live coding interviews. Every major Big Co. that does these has a very well established flow, including providing helpful clues to the candidate. Most companies provide training to all interviewers to make sure this process is smooth, repeatable and fair to candidates.

Common tips are to: first make sure the candidate understands the question, make sure they are thinking out loud the entire time. You don't let the candidate go too far down the wrong path. Most important you have a list of anticipated questions with stock answers to help stuck candidates, as well as a list of stock prompts to help them get on the right track if they are lost.

For example, in your challenge, if a candidate is stuck you might ask as simpler subproblem "so how would you find out if a sting contained the letter 'a'?" and if a candidate starts heading down the wrong path, prompt with "hmmm... I think I see where you're going, but I recommend you back up a bit and rethink this part here"

It sounds like you're in a small shop so I highly recommend you enlist a few friends (especially some that have done interviewing at large companies) to help you work out the kinks in the interview itself.

Why would you want that? Look for someone who can (and is happy/eager to) learn *from you*.

Edit: smart isn't bad, but it's not much of a signal - there are plenty of ways to be smart but not very productive. Moreover, any test in an interview setting well be extremely limited. Ability & willingness to grow seems a lot more useful (and at least equally well testable).

Granted, I don't think it's all that hard a problem, and while I'm not at keys to check I think off the top of my head it should be solvable for constant strings in linear time - not like you're asking for sequence alignment or anything like that.

But if it demonstrates something relevant to the role and ten in a row can't hack it, then your pipeline's not finding you good candidates and that needs to be fixed.

And if it's not relevant - which is highly plausible, as who ever needs to or even should reimplement heavily optimized standard library functions, especially for as hairy a type as strings - then why even ask it in the first place?

edit, at keys: Yeah, it's simple to do this in linear time with constant strings (ie no backtracking):

    const cases = [
      {
        subject:
          "now is the time for all good men to come to the aid of their country",
        searchFor: "n to come t",
        expect: true,
      },
      {
        subject:
          "now is the time for all good men to come to the aid of their country",
        searchFor: "time flies",
        expect: false,
      },
      {
        subject: "short skirt",
        searchFor: "looooooooong jacket",
        expect: false,
      },
      {
        subject: "symbolized as ∆v and pronounced delta-vee",
        searchFor: "∆v",
        expect: true,
      },
    ];
    // TODO cases covering match at start and end, etc
    
    function contains(subject, searchFor) {
      let searchIdx = 0;
    
      for (let i = 0; i < subject.length; i++) {
        if (subject[i] === searchFor[searchIdx]) {
          searchIdx += 1;
    
          if (searchIdx + 1 === searchFor.length) {
            return true;
          }
    
          continue;
        }
    
        // We found a mismatch between subject and search
        // strings. Return to the first char of the search string;
        // we'll have to try to find a new match
        searchIdx = 0;
      }
    
      return false;
    }
    
    function assertEqual(expected, actual) {
      if (expected !== actual) {
        throw new Error("Assertion failed");
      }
    }
    
    cases.forEach((testCase, i) => {
      const { subject, searchFor, expect } = testCase;
      try {
        assertEqual(contains(subject, searchFor), expect);
        console.log(`PASS: case ${i + 1}`);
      } catch (e) {
        console.error(`FAIL: case ${i + 1}`);
      }
    });

In entire fairness, I have to admit that we do use problems of similar complexity (both cognitive and algorithmic) for our first tech session, which I frequently administer. In my experience, people tend to handle stuff like that pretty well, even with considerably less experience than it sounds like your candidates have. But - and I think this is crucial - none of those problems involves operating on strings.

As another commenter here suggested, you definitely need to express this in terms of Array<number> or some similar contrived type that's obviously not as complicated as strings, because anyone who's been around for a while will certainly have been burned often enough by string complexity that they're not likely to assume they can treat it purely as an array of bytes iso8859-1 style. I certainly wouldn't assume that!

To be clear, I would ask if I could safely assume that for the purposes of the problem, or more likely I would look at the tests around the problem and see if any of them included obviously non-Latin-1 chars and thus cue me that they need special handling. (If I can't see the tests while I'm writing the code that's supposed to pass them, you'd better believe I will ask about that!)

I wouldn't necessarily ding a candidate for not asking, though. For one thing, this is all pretty basic info, and would certainly be available in "real life" - so if it isn't available in the interview, then the interview isn't a sufficiently accurate representation to produce a clean signal.

For another, and for the same reason, the perceived power differential between panelist and candidate has to be taken into account. You're not going to get a clean signal if you bring your ego into the session, or otherwise give the candidate cause to feel more intimidation than the context naturally inspires.

Some folks are more confident than others, sure - but it's a technical interview, and confidence isn't really of interest beyond the baseline of not seeing a candidate dissolve into a puddle of flop sweat. (And, in any case, if that does happen then it's at least as much my fault as anyone's, because if I'm not able to help people be comfortable enough to even function on my team or in my engineering org, then I'm not doing my job right!)

So yeah, granted, I haven't interviewed with you and I don't know any details beyond what you've chosen to describe, so take this advice for whatever you find it to be worth. But, especially in a language like Java which I gather makes it more necessary to account for utf8 weirdness in strings than the languages I more commonly work with, I definitely think you'll see a significant improvement with just that one simple change of not using strings where you really don't need to in the first place. That might not be the only thing that needs attention - I suspect your pipeline may need some love, too - but I'm fairly confident it's an excellent place to start.

(For what it's worth, my experience with tech interviews extends well beyond the candidate's role; I've been participating in them as a panelist for a good few years now, and lately, by request, have been doubling up my sessions as mentoring/shadowing opportunities for other engineers and EMs who want to improve their own panelist skills. Granted, I've approached this discussion largely from the candidate's perspective - but then too, I'd argue very firmly that if you're not considering how your interviews might go from the candidate's perspective, then that's something you need to work on, too.)

Wait... We all know (?) that Java was conceived before Unicode 3.1 came out and somehow thought that 16 bit chars would forever be enough to hold unicode codepoints and hence Java strings are now a mess of both char and codepoint methods but... What's UTF-8 got anything to do with your question, even after a basic algo is working?

If I'm using Java's charAt(...) on both strings, what's the encoding got anything to do with matching if the substring is present? Who cares that one character may have a codepoint encoded using more than one Java char primitive? It's either encoded the same in both strings or it won't match right?

I'm confused.

EDIT: you said it's not fancy, so you're not looking for people to match combining codepoints in one string matching another codepoint in the other string or things like that right?

And you had to mention their age ... why, exactly?

As opposed to "a left-handed Java programmer", or "a Java guy wearing a Slayer T-shirt"? No -- for some reason, with this candidate -- their age was especially relevant to you.

Why?

But then people try to overdo it and deal with UTF-8 before having the basic algo working.

Because of one too many experiences with live coding interviews, (on appearances) pretty much exactly like yours -- in which one gets flushed (or otherwise dinged) for failing to proactively treat such edge-case details as encoding gotchas, zettabyte-scale strings sharded across multiple time zones, etc.

I’m pulling my hair wondering what’s this parallel world I’m in, or whether I’m introducing a bias which makes everyone fail (2 interviewees per month for 5 months).

In fact, you are introducing just such a bias. There has recently been good, solid research done into the fact that performative (that is: on a whiteboard, in front of a group) "programming" tests are really basically high-pass anxiety filters. That is, implicitly designed not to measure programming ability, but the (studied) ability to ... successfully complete peformative rituals in front of random strangers you've never met.

If you aren't aware of this research (or your capacities for empathy aren't at a level where this is intuitively obvious to you) -- then you shouldn't be conducting these kinds of interviews in the first place. No matter how good you are at programming per se.

So big-O implies that the runtime is "dominated" by the term in brackets, or put another way, if I say something is O(n^2) I'm stating that as n->infinity the runtime of the algorithm |R| <= c * n^2, where c is some constant.

This is still true of exp^n, since |R| <= cn^2 <= dexp^n. Or at least based on my analysis background I'd expect this behaviour. It is of course a little pointless to say the algorithm is O(exp^n), but that's a different issue. It is still an asymptotic upper bound.

I just checked my copy of Sipser. Example 7.3 on page 249 if you care. They give an example that f_1 is O(n^3) and state it is O(n^4) also, since n^4 is also an (asymptotic bound) bound.

But this is not the point. I have no formal computer science education at all (my background is mathematics, some logic if that counts, but I've never studied algorithms) but many interviewers insist on this one specific area of CS, and yet if you attempt to engage them on the meaning of the things then unless you are very lucky they will a) make some excuse about how they'd have to check, their degree is a while ago, or b) they're actually only reciting also.

I'm strongly of the view this is a massively cargo-culted interview question of questionable to no value for most software engineering jobs, given that interview time is very limited and there are many more important factors to evaluate.

The problem with asking mainframe questions is that they aren't as relevant in today's landscape. Meanwhile TLB is relevant for performance, UDP is a very common network protocol, consistent hashing is relevant for designing distributed systems, etc. Especially if you are just self teaching yourself you aren't going run into a chance to work on a mainframe unless maybe you use a mainframe emulator, but why?

Interviewing sucks...

The best jobs I had I just started on -trial- or whatever doing good work on their GH and from then i'ts pretty easy to know if we're a match or not.

(Paid) Trialhires should be a more common thing.

Companies should hire and fire more easily. I just don't understand I work mostly as a contractor so they really can fire me with 1, 10, or whatever days in advance...

It's not like I'm an employee with protection to being fired or compensation or whatever...

Why so much hassle?

I can't emphasize this enough. Successful interviewing is about pattern matching and what this really speaks to is more people means greater risk someone isn't properly calibrated on their pattern matching and their feedback negates someone else who's pattern matching is spot on.

Not saying it's a perfect process, but just providing a counterpoint that our process actually seems more likely to help someone with the rounded set of interviews we have than we would with fewer.

There are good research universities in the R2 list as well (RIT, IIT, etc.)

https://en.wikipedia.org/wiki/List_of_research_universities_...

If you need help identifying a type of position and a learning path to put you on track towards a developer job, taking into consideration what you already know and are comfortable with and also the market, I can help with that.

In USA a very senior engineer at a FAANG in California will earn 20x times more than a junior engineer at some small midwest company. In UK a very senior engineer in London will earn perhaps 4x that of a junior engineer in Wales.

In USA "pays very well relative to other professional-level jobs in the local labor market" will often mean a compensation that's double or triple of those other jobs; in UK "pays very well relative to other professional-level jobs in the local labor market" would imply a 20% or 30% difference.

That makes a meaningful conceptual difference.

By this, I would assume you mean the year of prep that goes into being able to pass the interview process at those companies.

Companies don’t die that quickly. It may not be one person but it might be a handful of high performers who leave over time due to a toxic culture. And even then it may take literally years for a VC cash infused zombie company to actually cease operations. One of the problems of having so much cash is bad decisions don’t reveal themselves until much later.

Don't misunderstand, I do understand the point of view from hiring managers. But in the current job market, where people change jobs rapidly to actually obtain said knowledge while at the same time technology continues to change rapidly (often repeating the cycle rather than actually innovating), surely it should be evident this isn't going to be efficient if not sustainable in the long run.

If anything, you're giving people the exact arguments why we shouldn't trust companies to act for the good of the industry long term.

> But ... they won't know the libraries let alone their intricacies and idiosyncrasies etc

triggered a related thought (also closely related to recent "how do you learn effectively?" and "I'm exhausted/burned out, what do I do?" HN threads):

In my most recent job-search, I found this type of expectation/requirement (specifically regarding deep (down to idiosyncratic) library (aka framework) knowledge & experience) to be the most off-putting. The likelihood that I will have used a specific library in the ecosystem your team/company has chosen in its pursuit of "teh hotness" is (to put it mildly) low, but I'm certain that my resume will be discarded, or worse, an interview process spun up but doomed because I'll be unable to regurgitate library documentation chapter and verse (much less idiosyncrasies (many of which may be version specific).

The proliferation of libraries/frameworks seems to be exponential; how would I ever acquire deep knowledge of the complete set of same that are considered "today's hotness" (both today and of the past N years) in an language ecosystem which I have extensive experience and familiarity with? My current employer/team has made its language and framework choices, and I'm bound to them for (typically) years, and I focus (for years) on being productive in that context. Am I expected (in the context of my next job) to have spent my non-working hours gaining/maintaining knowledge of both the contemporaneous competing frameworks (which current employer/team didn't choose, but came in close second, etc.) as well as each "new hotness" that comes along? The alternative appears to be that my future employment possibilities are continually being reduced/narrowed as the set of libraries/frameworks in popular use expands (exponentially) while my knowledge remains tightly focused within the domain. Even if I was willing to make an investment in self-study to learn a new library/framework well, given the above-described circumstance, what would be my criteria to make a wise choice? And if presented with the same question 6 months later, what is the likelihood I would make the same choice? I'm pretty sure the answer is not "100%".

In practice, I simply did not apply to the vast majority of job listings which I would have considered myself otherwise a good fit (i.e. could immediately grow into), due to this factor.

I love frank advertisements. Just put your real requirements up front and don't interview anybody who doesn't (claim to) fill them. Then it's fair to call bullsh*t.

No complaints about the salaries you have to offer or the thin pool of applicants, though. It's all a tradeoff.

I guess I'd like an evaluation as a hiring manager: does it work? Are you able to hire the people you want? If it's working none of this HN bellyaching matters.

You put it in an interesting way. But FAANGs and big tech are businesses, too. They would want to achieve their business objectives, too. Still they hire someone who is not proficient in a particular language / framework if he is a good developer. Maybe the time it takes for them new hire to ramp up is worth.

There are also a lot of valuable skills that transcend writing code. I'd argue these are probably more useful in achieving business objectives quickly instead of just having another warm body to write code.

Given the above reasons, it seems odd to me that you would discount an engineer solely because they don't have experience with the stack. I guess it depends what you're looking for though. If you specifically want a JS expert who will bring best practices and new approaches to the team then it makes sense, but otherwise I don't see it.

I did. I simply don't understand how such scores can be evaluated in real life.

Wow, that's insanely impressive. Can I ask how that's possible? I'm making that *BEFORE taxes, in Austria, Which nets me significantly less than you in take home pay and savings.