Things I Learned from a Job Hunt for a Senior Engineering Role (fuzzyblog.io)

I would say that's still management incompetence. They're paying all this money for experts in the field, and they still want to disregard their opinions.

What’s the order of arguments on this one? Does it modify the data passed in or create a new one? How does it handle nulls?

It’s cheaper to look it up than to debug. So that’s what I do.

And I wasn't even particularly nervous about getting or not getting the offer either! They approached me, and I wasn't fully sure if I would even like the job yet!

FizzBuzz-style filters not only don't prove that someone can code, they don't disprove it either. I'm not sure what the answer is.

Partly because it's not exactly easy to get enough context and understanding about a codebase in an interview to be able to accurately debug something, but also because again it comes back to what you are familiar with. 6 years ago I would be damn good at debugging and optimizing MySQL queries, today I'd probably struggle to get a moderately complicated one to work without a lot of looking things up and trial/error (I mostly work in postgresql now!).

That's why I like to ask about their past experience. Tell me your war stories, tell me what you did to figure out that bug that was causing the elusive crash, tell me about your struggles getting webpack setup, talk about how you initially planned to do X but then after issue Y decided to pivot to Z because it was simpler/easier/faster/whatever, explain how you accidentally put a quadratic-complex function into the hot-path of your application that one time and when you found out it was a problem.

Just talking about stuff like that can often show where a developer is in their career, what they are good at, how they go about solving problems, etc... And it's almost impossible to cheat/fake it.

I'd suggest a widely-accepted professional certification could help a lot, like doctors and lawyers have with the medical board exam or the bar exam. Easier said than done, but what we have today, where the candidate pool is overflowing with impostors with great resumes is not working.

Go long enough interviewing hundreds, you'll see a few no matter what. Have a crappy enough filter in front and you'll see them right away.

It annoys me that the good answer if you actually encounter the problem during the job is never accepted during an interview.

They were probably looking for the answer of, "Lets talk through it and figure out a better answer". Coders are often under a mistaken impression that interviewers care about your answer. They don't. They care about how you approach it, how you think through it, what you do when challenged, etc.

So from their perspective, they asked you to try harder on a problem, and you just said, "No." And they dropped you for it.

FWIW, I had similar questions in some interviews where we hashed through similar problems, and together collaborated down to a "No" answer... but we spent 15 minutes exploring the problem and seeing how well a couple coders can work through it before saying no. And I got the offer despite an otherwise rusty performance.

The problem that I have with those problems is, they always assume it's easy to answer after seeing the solution. But if you're working on them for the first time, it's a terrible environment. The minute that they stop asking you, as the canidate, are on a timeline to finish. (Also, to finish as well)

The answer to that item would be: (with scala)

> datasource.window(3,1).filter((a,b,c)=> a+b == c)

I mean if you knock it out of the park and know the internals of window.. then asking the bar raiser question is appropriate as a curiousity.

There are other problems as well: Those are the ones where they have an expected answer, response, and reiterate. I've seen that with tree problems. That's where they would low-key ask for the recursive version and then get you to say stackoverflow exception.

My immediate solution: Sort the two strings and then compare them:

  (defn anagrams? [x y] (= (sort x) (sort y))) 

"Ok, what's the efficiency of that solution?"

"Well, assuming the library sort functions I'm using are sane, I'll take a guess and say O(n log n)"

"Can you come up with a more efficient solution."

Off the top of my head, on the spot, I couldn't. Later, during the plane ride home, the obvious occurred to me: Don't sort the strings, just scan through each string once and build a hash table, keeping track of the number of occurrences of each letter in each string. Then compare the occurrences for each string. Not as elegant to express in code, but faster.

As it turns out, they later declined to hire me, giving me an excuse that made it clear they weren't really serious about hiring anyone for the position (as is the case at least half the time, it seems).

And thus ended my latest round of failed interviews. I cancelled the last one I had scheduled (probably another fake) and decided to take a break for a while (I mean, I do have a job right now, so it isn't urgent).

Reminds me of my final round at Amazon, which they always do in Seattle. I woke before 4 AM west coast time having flown out the night before from the East, and 12 hours later was still coding on a white board. After writing (to my surprise) a correct merge sort, they asked my to write a program to do basic math with, IIRC, binary numbers. I was like, um. I'm out.

And I have similar anecdotes related to candidates who claimed years of distributed systems architecture experience, and were yet unfamiliar with CAP (and when explained, could not tell me even at a high level whether, in the event of a partition, their system was CP or AP, let alone the specifics of how that actually exhibited itself).

I don’t think it’s essential to know this, but I’d be surprised if a web dev interviewed with us and didn’t know at least the basic version I’ve given above.

If you legitimately did the work without picking up -any- of the terminology, -and- respond confidently to questions you should know you don't know the answer to (rather than admitting ignorance and asking for follow-up questions, or declaring assumptions, i.e., "Well, I would assume it has to do with the behavior that if a constraint is violated or something similar in a transaction, the transaction will be rolled back instead of committing"), I don't want you. Because it means you both did not have formal training in, AND didn't seek out information or knowledge in the domain you were expected to be -senior level- in.

And while atomicity and durability are just characteristics of a relational DB (and so adminning one doesn't really require you to understand them), isolation and consistency both have definite relevance, because the isolation level is configurable, and that affects the consistency guarantees of the system. I expect someone saying they were a -senior level DBA- to be able to talk intelligently about those behaviors, and yes, to understand the words, because just reading the docs would have introduced the words.

I mean, look at this thread; would it be better to start with "Here are some example tables, please write the SQL that will return me (etc)" and turn it into a coding exercise? Because I honestly don't care that much about that from anyone espousing a senior level of knowledge.

Coding in the large is project management and could be tested by a take home, but I'd rather tease it out by asking in person questions about organization, prioritization, and technology choice.

Throughout my career, I've been in professional situations where I was under a lot of pressure: Having to explain failures to executives, near-impossibly tight deadlines, production outages. At least I haven't had to testify in front of Congress yet. Absolutely NOTHING I've encountered in my professional day-to-day has the extreme level of pressure of a typical silicon valley job interview.

Checking substring in a string is a 1 liner in languages like python.

I was at a final interview with FAANG. One question asked was to load a csv. I used pandas, it's a 1 liner. You could see the wretched face of the interviewer since he was expecting a

with open() as f: do_some_shit

and kept pushing me to write this on the board. I looked at him and said "Why? Why write your own method in a vanilla language? Give me a good reason."

const isPalindrome(str) { return str === str.split('').reverse().join(''); }

And the post interview notes said bad performance on the isPalindrome() question since I didn't write out my own functions (interviewer did not mention to).

Id say that close to 0 out off 10 engineers at work including me would get a working program without debugger or print statements.

Just tried in c and got me 2 compiles to get it right. Without the output I would just present a nonworking program.

Took me less than 10 seconds to come up with an approach that would work oh just though of a more efficient one but that would use a regex :-)

"Write a function that reverses the words in a (string) sentence"

i.e. (x) => x.split(' ').reverse().join(' ');

  return inputString.Count( "eaoiuAIEOU".Contains );

  static Regex VowelMatcher = new Regex( "[aeiou]",
    RegexOptions.Compiled | RegexOptions.IgnoreCase );
  ...
  return VowelMatcher.Matches( inputString ).Count;

  return 2; // number of vowels in "a string"

    def vc(s):
        return len([c for c in s if c in ['a','e','i','o','u']])

I've tried working with them before, have gone on job interviews through them, and then generally found that the jobs that hire through recruiters pay peanuts, and I end up finding a permanent job paying much more and taking that instead. I think if a company only works through 3rd-party recruiters, that means the company has no idea how to hire people, and doesn't want to pay much either (because they're paying the recruiter a huge commission).

Likewise, if someone wants me to walk them through a project I have with explanations of what choices I made and why, I'm happy to do that. But please don't waste my time asking me to implement DFS, or write another twitter API client.

Now: If you care about being able to collaborate on a tough problem with somebody, work on a problem neither of you has seen before together :)

Yes, some of the code may not be original, but unless the repo is a fork you can pretty easily see if the code is organized in a coherent way that shows the committer knew how to decompose a problem well. If they solved /every/ piece of the problem themselves, it may be a sign of a different problem (and also copy/pasting without citing source is also telling!)

If its is their own code it shouldn't be a problem.

If it isn't their code and they can still talk you through it, even better - they have managed to understand code that someone else wrote which is probably an even more valuable skill.

His resume doesn't say he did auth. He used an open source library and made unspecified modifications to it. That's definitely something a junior level Dev could do.

"Or maybe it's part time". Exactly. A resume should give answers, not raise questions.

Expecting people to be charitable while reading resumes is unrealistic. A resume has to quickly demonstrate the applicants qualifications other wise it's trashed.

At a certain point "can code" stops being "can write perfromant algorithms" and starts being "can work without direction, can be placed in front of users without fear, can defend their decisions, is not an asshat."

Ten minutes on a shared screen and we can find out if you pass fizzbuzz, can make a rational stab at an algorithm question. After that it's mostly cultural fit.

You cannot automate a test for "is not an asshat" so we get more and more people proving they can get 99% on programming tests when programming tests are 5% of the job.

What substantive evidence do you have of this shift?

Very well said and it happens in lots of areas where companies seem to wish for "big outcomes but all for free".

You will see this in security all the time.

"We have to make sure this thing is bullet proof."

"Ok it's going to take a month to harden and audit our the network and infrastructure and add monitoring and we'll be in good shape."

"Uhh ... no we didn't quite mean it like that ... can't you like install a plugin in half an hour that does the same thing?"

(made up conversation but you get the point)

Well yeah, churn and burn is my company's motto. At least we pay well.

Our organizational structure isn't immutable, it just moves slowly. After about a year, my team's effort resulted in measurable improvements for both revenue and end-user experience.

If you're senior dev level and want more of a challenge that's not just throwing more code at the wall, these sorts of scenarios are something to seek out.

I'm not a developer who is down in the weeds optimizing specific algorithms though, and I can see how a mastery of language-specific data structures and how they are represented in memory might be required for such a person.

With small companies, it often comes down to "were you charming enough?" They won't admit it, but it's a clear subconscious bias.

The problem is that it's kind of awful, and I personally really do believe that it's driving people away from the field.

Here's my take (I've posted this on HN a few times). Many people find in person, at the whiteboard exams quite stressful. This is fairly common, many people describe exams to be among the more stressful events in their lives.

Over time, I believe that institutions that conduct exams evolved a bill or rights between institution and applicant. Exams are used, but they are administered consistently and fairly, the topic and subject matter will not be a huge surprise (questions are kept secret of course, but their nature should be predictable). People who pass or fail will receive an answer, and often get a score and feedback to know how they did. The people who grade the exams are provided training to ensure they evaluate people fairly, consistently, and without bias, and are expert in their field.

Now, I know that universities, medical boards, bar exam reviewers, don't always live up to this, but it is the intended goal. I believe that our field, software, subjects people to exams repeatedly, but without any of the bill or rights I descried above.

For example, how do you grade? Are you qualified to assess general intelligence? Can you understand that someone might not be eager to submit to your general assessment of their intelligence?

Now, if you want to say nobody is entitled to a job, I certainly agree. But the industry seems to think it's entitled to workers, and they just seem utterly blind to how off putting their practices are. And in an industry with concerns about gender, racial, and age discrimination, double secret assessments of people's general intelligence by interviewers of unknown qualifications is about the worst thing you can do.

The idea is to assign low points to people who write a long function, and high points to people who write many small, self-documenting functions. Such an exam could also ask questions like "what is the cyclometric complexity of the following code?", which while not an indicator that the test taker will always write low-complexity code in a professional environment, at least indicates that the test taker is aware of maintainability metrics like cyclometric complexity - much more than can be said of programmers who mindlessly turn in 400 line functions with deeply nested conditionals.

I think that the google style data structures and algorithms exams are a good case in point. Think of these like the actuarial exam for linear algebra, vector calc, and numerical analysis. These exams don't of course test everything important about being an actuary. But they do establish competence in something that can be tested. As a result, actuaries don't (to my knowledge) have to do 5 hours of whiteboard exams doing LU matrix decomposition or finding a steepest descent vector. Whereas software developers have to find all matching subtrees in a binary tree over and over (and over).

What I like about the actuarial exams is that while they are rigorous, and it helps immensely to have majored in math or something closely related, you are free to decide how to prepare for these tests. Although I like the idea of a widely recognized entrance exam, I really don't like the idea of something like the law schools putting themselves (and 200k in debt) in between an individual and the right to take the exam.

The key is to only stretch it to the extent that you can explain your background in detail to the hiring manager and be able to openly admit where you don't know much if those areas come up. Generally speaking a hiring manager you actually want to work for understands that experience is heavily dependent on what your last role needed, and skills can be picked up as long as you have enough of the bare minimum covered.

You just negated your entire point there.

Yeah, you can have a bad day. I get it. We all fail interviews; I certainly have. Some I feel we really weren't a match (they were looking for a kind of developer that I wasn't, and don't want, to be), others I felt were unfair (for instance, interviewing with Microsoft years back, I had a C/C++ interviewer asking me questions that I had been told I was allowed to write in Java, and then disbelieving me when I told him (String).length is constant time so it didn't affect the Big O complexity that I had 'for (int i=0;i<(String).length;i++)', and clearly mentally checking out at that point). Obviously I don't feel any were because I wasn't, legitimately, good enough, but I also recognize I am very biased. But the thing is I also am in a place where I don't need an interview to justify my confidence at this point. I know I can deliver value. But I also know I will never convince the Googles of the world that I can, because I am neither a researcher of note, nor am I going to jump through the hoops of prepping for weeks on end for an interview; I have a wife, hobbies, and other, better ways to spend my time (even typing comments on HN! :P)

We first give people a take home. It's at their own convenience, we tell them it will be an hour and a half, coding, simple questions, to do it at a time they're comfortable. We don't stay on the phone, we tell them to use whatever resources they want (except, obviously, please don't try and google for the answers directly, or get help from others; it's simple enough that those who have tried to cheat have ended up with it being hilariously obvious, like leaving source comments that said it was by someone else, or variables for 'cat' when we never asked for anything related to cats, or being caught out during the whiteboard).

The interview is mostly a conversation. It starts with conversation. We talk about the position, the company. We ask about what the candidate is looking for, their resume, that sort of thing. Only after thirty minutes or so do we get to anything technical. We ask a few questions, and they're intended to be placeholders for conversation; plenty of right answers, we mostly want to see that the person is knowledgeable enough to discuss things. Even when we get to questions that have a right answer, it's mostly to gauge knowledge, and for the more complicated, even if a person gets it wrong, we'll tell them what the right answer is, and then ask them for a rational as to why. If they can figure out the rational, that's just as good as having known in the first place. Then we have a whiteboard question. It, too, is not hard. We tell the candidate "If you think there's a library function that will help, but you just don't remember it, you'd need to Google it, that sort of thing, talk it out with us, we'll give it to you". We try to help suggest things to get candidates unstuck. Etc.

Really, it's -not- a particularly antagonistic process. We really, really do want people to succeed (because, frankly, we want the position filled so we can stop interviewing and go back to work). So, yeah, if the interviewer doesn't manage the trivial coding tasks...we're going to pass. We -aren't- saying "this person is a bad developer", we -are- saying "this person could not demonstrate that they passed the bar of our interview process".

But there have also been some who have flat out said, even on the take home "I can't do this". Or those who have admitted when faced with the whiteboard question that they don't know how; that the take home had been done by someone else. Etc. Given those situations, yeah, our candidates are being given a take home, and a whiteboard.

Exactly! And people still get it wrong.

It's a low-pass filter to weed out programmers who can't even do FizzBuzz, because despite their lack of coding prowess their résumé will still look similar to yours.

> and not feel like there's some degree of insult involved.

That's just reading far too much in to it.

Try to remember, this is the country where a range check function resulted in a lawsuit:

    private static void rangeCheck(int arrayLen, int fromIndex, int toIndex {
         if (fromIndex > toIndex)
              throw new IllegalArgumentException("fromIndex(" + fromIndex +
                   ") > toIndex(" + toIndex+")");
         if (fromIndex < 0) 
              throw new ArrayIndexOutOfBoundsException(fromIndex);
         if (toIndex > arrayLen) 
              throw new ArrayIndexOutOfBoundsException(toIndex);
    }

Anyway, it is just the first question and we are usually past it in five minutes. Then we discuss, in general terms, the types of problems we are solving and the related computer science topics.

It certainly isn't meant to insult. I hope I haven't insulted anyone and, if I have, they've never made it known to me. I will say that it'd be a huge red flag to me if a candidate acted like this was beneath them. The reality is that, while we will be solving some cool and hard problems, there will be lots of problems that are beneath us, too.