> I was allowed to Google whatever but 50 minutes is still a crazy time crunch to figure out a lot of the stuff that needed to be figured out.

This actually might not be so nuts if it were clearly a way to evaluate how you handle unfamiliar problems and they made it clear they didn't really expect you to finish the whole thing in 50 minutes, I guess.

Part of the problem is that most companies seem to be complete dogshit at communicating:

1) what they're going to quiz you over—they seem to think it must be a pop-quiz with absolutely no way for you to know what might be on it or specifically prepare for it, sourced from literally all of your past experience, all of CS, all of software engineering practices, and maybe even stuff you never claimed to know, which is plainly, to be blunt, fucking bullshit and goddamn insulting, and that's not even getting into how many of these questions/challenges rely on recalling (rarely on formulating or discovering, that's just impractical and unlikely) some very specific "ah-ha" insight to not look like a complete dumbass while trying to solve them—and,

2) why they're giving you certain challenges or asking certain lines of questions, what they're trying to evaluate, or how you'll be judged, leading to stressful, pointless guessing games like "should I risk not completing this challenge to write very complete tests, because they'd rather see good tests than a working solution, or am I just completely fucked and a getting a definite 'no' if I don't have a working solution anyway, so I should not write any tests that don't increase the likelihood of my finishing in the time allotted?"

[EDIT] "why don't you just ask questions to resolve point #2?" Yes that can work, but a lot of this is so damn vague that then you've got the meta-guessing-game where there's a real chance you'll "lose some points" if you ask valid-in-context but "wrong" questions, because any "real" developer should know the answer ("of course you must write extremely complete tests for all code ever! Ugh, this guy must suck.")

This happened to me. I once interviewed at a place where they presented me with a language I had never seen. Very different concepts than your typical C/Algol flavored languages. They went over the basic concepts, with a handy reference sheet for me, then gave me a few tasks to complete in that language.

Towards the end, after completing the tasks, I congratulated them for inventing a ficticious language in order to test candidates on a more equal footing. Cute, clever, creative, even though it's probably far-removed from the real world...

Their response? Oh this is not a ficiticious language, this is what we use daily. It's our proprietary language and we're quite proud of it.

Me: ...

(I ended up getting the job and learned a lot in the domain of wheel reinvention.)

And yet, an entire SPA in vanilla JS in 50 minutes seems a lot to me.

I guess it depends of the size of the SPA, but user input + rendering + routing + whatever logic they ask you for the app is a lot of work.

I guess it depends a lot of the requirements: you could skip the routing, make a dirty innerHTML rendering, deal with one browser only for the input events, etc. Still...

Besides, I hate being rushed when I code. I never speed code IRL, the deadlines are in days/months, hours for crisis, never minutes.

I built out the entire backend prior and took copious notes because getting stuck looking up things like “how do I initialize a postgresdb” (something I do maybe once a year, if ever) would eat up time.

I think I did pretty well at that onsite because of the fact that I prepped before hand and they didn’t seem to mind that.

It’s weird to me because in general most engineers are rarely if ever creating an entire stack from scratch and it can be very easy to want to do such a thing methodically and with best practices in mind.

How would I enable hot code reloading? How do I set up PostGres so I’m not just connecting as super user which is obviously a security risk? Etc etc.

To be able to do these tasks under pressure with an engineers mindset is tough and you either have to really drill down and focus and stress that in a real setting you wouldn’t be connecting as superuser but for the sake of time in this particular toy exercise you will be.

Being able to prep was essential, and even so, I still stumbled here and there with unfamiliar syntax.

Interviewing is not a solved problem.

I've done a lot of these tests and interview projects, passed plenty, didn't pass a few, didn't bother finishing a few, but - weirdly - every place I've been hired didn't use them in the first place.

I've started to view them as a sign of a company you probably don't want to work for.

Similar here. Strangely, the places that don't do them pay about the same as the ones who do (in the same market—not talking FAANG versus Bob's Printer Service & PC Repair in Madison, WI).

After my latest search my new policy for future searches (at least until the downturn or it otherwise stops being super easy to find jobs) is at least not to do any kind of project or evaluation before a real interview, that is, without a real person from the company taking the same time I am, at the same time. The kind where they send you to some "coding challenge" website or give you some "take-home" project before even talking to you. If they're asking me to burn a bunch of my time to save some of theirs, it means I'm too far down the slush pile and/or they're too bad at interviewing for it to be worth my time.

Compare this to what we did previously, which was to get one of our engineers on the phone and on a pair coding website to ask brain teasers. The candidate got no followup feedback if they didn’t do well. On top of that, because the people doing the interviews knew that if they said “no hire” it would stop the process in its tracks and the person would never get an on-site, we had something like a 95% pass rate. We evaluated several third parties for this, and felt the one we chose was the most useful and the most respectful of candidates’ time.

I understand that the process isn’t for everyone (no process is), but we’ve gotten generally good feedback from applicants so far about the company we chose (Woven, for the record).

Edit: also just noting that we don’t do any sort of hard cutoff for the scores they send us. We try to evaluate each candidate’s performance in light of their experience, looking at what they were and weren’t able to get done, etc. We had someone recently do amazingly on the first half but not even finish the second: presumably they ran out of time, but we brought them on anyway because we felt like their performance on the first half deserved earned them some further consideration, even though their overall score was quite low.

Plus, I mean, I'm not as good at coding challenges as I am at actual development work (which is a lot of stuff, some of which is tappy-tappying code into an editor) so if that's the first gate I have to pass before anything else, that lottery ticket I'm buying with my hour typing at a robot ain't likely to pay out anyway, even if I'm actually the best candidate for the job itself, which isn't guaranteed. Luckily there are so many fish in the sea (job offers paying roughly the same) that it's not an issue for now. Hopefully I've fully "leveled up" into titles for which coding challenges aren't the norm in hiring before the next downturn, otherwise I guess I'll be spending some time drilling to preen those peacock feathers, which is what I'd have had to do this time if it weren't such a seller's market for devs.

You might have seen the same thing, but any title that sounds managerial in some way - even if in the day to day work, it's completely meaningless - goes a long way toward jumping the line and convincing non-technical people involved in the process that you're a good bet.

Some indication that you have the soft skills and social skills to get along well with non-technical staff helps short circuit the whole thing, as well as convince the type of technical staff that put too much emphasis on coding challenge questions, etc., that they need to cool it and consider the whole candidate, not just a score on a quiz.

Meanwhile, during the act of writing code, I crib off existing code to remember how the hell method invocation looks in the current language I'm writing and similar important details. If I haven't touched a language in 3 months I very likely can't FizzBuzz without syntax errors or using the wrong function somewhere or whatever. I put Go on my résumé because I have written quite a bit of it, and can talk to someone fluently about the parts that are likely to seem odd to a newcomer and some of its strengths and weaknesses, but without some cramming ahead of time or a cheatsheet I probably can't demonstrate a bit of that in code. I'll likely mess up keyword order and all kinds of basic things just trying to "hello world".

In short: I've realized, later than I probably should have, I need to get the fuck out of development per se and into something that's still basically developing software since I'm actually pretty good at that, but doesn't judge me on whether I can, in the moment, recall what a print statement looks like in a language I was writing literally yesterday (it's entirely possible I'll blank on stuff like that!). In my defense I've been easily landing jobs doing this stuff since I was 15 so my blinders were, I feel, well justified—it'd just not occurred to me previously that I might shine better, at least in interviews, which is kinda important, by seeking roles a bit adjacent to development rather than in the thick of it, until I got mumble mumble years in the field and started to think about what I'll be doing when I'm, you know, not even sort of young anymore.

[EDIT] and yeah, of course I could put together Anki decks and do daily drills to get better at the parts I'm bad at and it'd certainly help, but another part of this series of mid-career revelations I've had is that if you find yourself wondering why other people are having trouble with something that's easy to you, that's what you should put your effort into, and conversely, if you can find some way to ignore the parts you find harder than most people seem to (not always possible and sometimes you just have to work on things you suck at, sure, talking about ideally) then you should do so, to free up more time for the easy-to-you-but-not-others stuff.

    > "to evaluate how you handle unfamiliar problems"

I think the answer is often 'no' and they've just never thought about it that way. My favorite interview question has a credible business story I can give for why we're doing it this way.

If you're the type of person who freaks out when we discuss the possibility of using a new tech you're unfamiliar with, I don't want to work with you. There's a certain level of pressure in saying "I know we've never worked with $TECH before, but we're going to use it for $IMPORTANT_PROJECT_WITH_A_DEADLINE" and if 50 minutes of fiddling around with JavaScript is enough to psych you out, you're probably not going to handle the new tech well either when you barely even know what to search for when looking for tutorials.

People ask all of these for good reasons. You can write literally anything on the CV, so people ask about your experience to check you're not lying (you'd be surprised how many people do lie and at least misrepresent). People ask coding challenges because they expect you to code (and we've all heard horror stories about like the head of IT security not actually knowing how computers work). They ask you general problem-solving questions to test your intelligence, mental models, and behavior under stress/adversity (again, you'd be surprised how many people just suck here, or worse, get insulting etc. ALSO - note that I'm not saying that all such questions are good, they're mostly bad, but with a little bit of thought and planning you can design a good question). People test for basic CS knowledge because it's important in almost all situations (would you hire a brain surgeon that didn't know what a spleen was?).

(Not discounting all the actually terrible interviewing practices, e.g. people asking impossible questions to feel good about how smart they are, etc.)

A simple "this part of the day will be algo questions, we do expect actual solutions for at least some of the questions, but we're happy to talk through your process with you as you solve them, and none will be more involved/complex/deep-lore than [a couple examples]" would go a long way. For one thing it'd let people just "nope" out of interviews they know they aren't prepped for ("well they should just know they can't do the job in the first place and not apply" that'd work if interview practices/questions and actual work-on-the-job—let alone what's asked for in job postings—mapped even somewhat closely to one another, across the industry, but they very much do not).

I don't think mystery-interviews and having no clue whatsoever what might be covered in the oft-featuring pop-quizzes probably does much for improving the quality of passing candidates, but it does waste a bunch of time (for everyone) and make the whole thing way more stressful.

[EDIT] tangentially related, I find it really weird that most every company says they want people who can learn new things and get shit done more than ones who just know lots of stuff, but act like if they provide enough information that a candidate might conceivably be able to even kind of study or prep for their interview process, that'll ruin it somehow. WTF? If the candidate is not capable of doing much with red-black trees in an off-the-cuff kind of situation because they're rusty or whatever, but then you tell them a week out that you'll be asking some questions about tree and graph structures more complex than simple binary trees, so they brush up over the weekend then ace the interview including some red-black tree stuff which they couldn't have done under those conditions a week earlier, isn't that precisely what you claimed you wanted in a candidate? How is that harmful?

The company has a given technology stack and rather than asking for anything which would directly benefits the company asks you to do some task that might be similar to their tech stack, but instead for the public domain / some open source project.

Programming: We've picked 10 problem tickets from various open source projects that are similar to things that might happen at work, show us what you can do in an hour.

DevOps: There's a local charity that needs a small version of infrastructure similar to what we have in house. Here's some old hardware we're donating and the things we'd like to see on it.

etc.

I was on a python/javascript team that transitioned to kotlin -- everything went well, better than I would have expected tbh given only 1 of us even had any production java experience, but 50 minutes would not have been enough time to figure out how to usefully set up the IDE, let alone build anything beyond FizzBuzz.

Why not seek applicants who are familiar with the problems they’ll be regularly encountering for the position you’re trying to fill? And as an employee I’d rather interview for positions that will require me to solve problems I’m familiar with.

That’s kinda like the whole point.

How you handle unfamiliar stuff is critical when evaluating an engineer. That's like the whole job.

Unless your goal is to churn out copycat CRUD apps and marketing pages your whole life. Then carry on :)

I was given only a single coding interview my whole onsite, and it was to build a JavaScript SPA, including routing/linking, without the use of any framework, just vanilla JS.

This is of course both completely ludicrous, and incredibly disrespectful. Thanks for pointing this out so that we know to add that company (Twilio) to our list of companies to pass on, the next time they come our way.

One bad experience can turn many engineers away from your recruiting pipeline.

For instance if I'm working on a hard problem I usually need tests (whether I initially admit that to myself or not), and despite the fact that I'm often the one who sets up and/or defines our testing strategies, every time I set things up is an adventure, because I set it up once and run that way for years. I have zero muscle memory for the installation process and anyway the decisions might be a little different in 3 years. And more to the point, I want people to copy what I've done, so I do the same thing (which gets me an experience of what others are having to put up with/enjoying about my solution).

For the app server the situation isn't much better.

In an interview taking the time to set any of that up would be crippling, even though I'd come out even on a 2-3 day story and ahead on anything longer.

I have thought many times about setting up a blank application with testing, logging, and production-reasonable overrides for all the defaults for the app server, etc. Just so I have an easy starting point for quick prototyping, which is essentially what an interview often is.

Generators probably work for an interview, but for real projects, re-applying the generator with each release is kind of a bear. I propose that it would be much easier (possibly trivial) to do on an empty shell project and then merge downstream.

I kind of think one of the things we are missing about DVCS is that the ability to maintain permanent forks gives us other options for arranging cross-cutting concerns. Maybe one more generation of merge tooling is necessary for that to be A Thing.

I am one of those people who takes a while to get rolling, especially when starting from scratch. Interviews generally give you 30 minutes or an hour to produce something. I will easily take an hour to think about the problem, do some research, and then create some notes before writing any code.

This is, of course, not what most companies want. Unless you are asking me to do something trivial or something that I have claimed to do many times in the past, you can't expect me to come up with the "right" answer instantaneously.

I never jump right into editing code, unless I am already intimately familiar with it.

This is a great way of putting it. As a "marathoner", I think the only way to pass these things is to condition yourself for the sprint. Which means being familiar with the types of questions that might be asked and practicing coding solutions until you can code them off the top of your head (and even on a whiteboard if necessary!!) The investment of required to achieve this is ridiculous, and there's no guarantee you'll be asked a familiar question.

It's absurd because in some software engineering jobs, a marathoner might be preferable to a sprinter but they'll most likely hire the sprinter.

Hiring remains an unsolved problem. The company who can truly solve the hiring problem will be a unicorn.

When put on the spot with a time crisis I tend to go too deep down a rabbit hole before realising the shortcoming of the approach I chose to take.

This leads to me usually doing great in take homes, compared to these recent in-person assessments. Also, confounded by having to work on an unfamiliar machine without any of my usual tooling which I'm not a fan of, especially as a keen fan of having a decent debugger set up.

My advice to someone in a similar situation is to start talking and ask about what we want to really achieve here. Not what the task description literally says (SPA or whatever - that's "how" but not "what for"), but what's the real business purpose for it. For the interview purposes - what do they want to see during or after those 50 minutes.

Then making a guess whenever this objective can be realistically delivered within the provided constraints, and communicating how do you feel about it.

If they provide their real expectations (e.g. "we want to see how you tackle a problem outside of your immediate expertise domain, we recognize harsh time constraints and it is okay if you won't complete it, although we'd appreciate trying your best") it's all fair game. If they don'tjust insist they want this specific JS SPA done in 50 minutes - well, that says something about their project management habits. In such case, I'd start asking questions about the role responsibilities.

Maybe 2 hours should have been enough? I don't know - with the stress of writing under time pressure ( I had a new sympathy for contestants in cooking shows ) and complete unfamiliarity with the module, I was pretty impressed that I submitted something that passed the unit tests.

Then I got rejected with the implication that I wasn't using good OOP principles. OK, my decision to store JSON data as a byte array was unorthodox - but it worked without a lot of coding overhead. I thought it was pretty clever frankly.

Something like: "Why did you store it as a byte array?" and then "How can you reconcile it with OOP principles?" as follow up questions would be far more productive.

"Which principles do you mean? If I write an object then it only matters to the caller what the API is, not the underlying storage, right?" and before you know it you're in an interesting conversation where you both have the opportunity to learn something.

It'd probably be quite enjoyable, regardless of whether you got the job in the end.

I do not want the latter.

I've found it's not possible for me to enter an interview with an unbiased mind having read a resume.

If you have advertised a job and I've given you my resume, it is to give you some information you can use to avoid wasting your time and my time.

Just like I would hope your advertisement is accurate and useful enough to let me decide if it is a good use of time for me to send you a resume (e.g., saw an ad for "react developer" -- got to the interview and they were looking for a "server side java dev" -- I mean -- wtf?).

Not reading a resume before an interview feels... rude. It feels like the path that leads to you asking a Java/Go programmer to do a Javascript coding challenge in 50 minutes, which is a waste of everyone's time.

I always talk on the phone before and that's where we both make sure the interview is of relevance.

I take a completely different approach, because I have been on the receiving end of disrespectful interviews and I won't stand for it and I don't expect the candidates I interview to accept it either. I carefully read the resume and research the candidate far in advance to the interview. I only ask questions during the interview which are open-ended, not trivia questions, and are directly related to either the content of the candidate's resume or things we're actually doing day-to-day on my team.

The dog and pony show interview style is intensely disrespectful and so is the idea that you won't even read a candidate's resume. I've walked out of interviews where both have happened, and I hope everyone on HN gets the personal confidence to do the same. I'm a professional, I expect to be treated like a professional, and I return that by treating those I interview like professionals. End of story.

We agree on that one, but the alternatives are worse. Would you like to take my place interviewing? It's a time consuming task I'd love to delegate to someone more experienced.

<disclaimer: my affiliation with triplebytes is that they've rejected my application twice - possibly cementing parent suggestion that I'm underqualified to interview developers>

I guess I’m a terrible interviewer, but so far the candidates we hired have worked out.

It sounds like you've had some combative interviews in the past (it sucks - I've had them too) but that's not the same as being aware of biases.

The parent is disrespectful to the candidates they interview and I am being charitable in taking their explanation about bias at face value.

What resume has this information? This is all stuff you can infer from the interview itself.

But, I have no idea how you gather gender or marital status from a resume.

It’s fairly common in my experience for CVs from European candidates to have marital status/other family information (and often a photo!) on them. I don’t know why and I just ignore it.

Pictures on resumes? That's a new one for me.

Depends, we always give someone a super small coding challenge (literally write 4 lines if you know how to, and the longest I’ve seen is something like 15), and any decent Java/Go dev could do that even if they had to learn JS on the spot (probably not necessary, but...).

But yeah, I agree with your main point. Not reading a resume is rude.

Resumes are a carefully crafted signal paper targeted at getting past an algorithm, recruiter, and into an interview. They're chock full of brand names (both education and company) and keywords. There's also unconcious bias based on the person's last name, locations that they've lived in the past, and so on.

I've found the best thing to do is skim their past job roles, to set expectations for where you can start with the level of difficulty in questions.

In what way I could see some edge cases, which one where you thinking of ?

Btw that's the PC way of saying blacklisted.

As a counterpoint/to play devil's advocate - it doesn't actually seem like these companies are any worse off for this, are they? In other words, it doesn't seem like poor interviewing practices (Google is offender #1) are negatively affecting these companies.

OK but that's like 4 lines of code:

Line 1: Get the URL of the current page

Line 2: Get the path part of the URL

Line 3: Using the path as a key, retrieve some chunk of text from an object

Line 4: Write that chunk of text to the DOM

I wouldn't know the syntax for any of that without googling, but that doesn't seem excessively crazy even as a question for someone who doesn't know the language.

Yes they are? Gift baskets, personal emails/calls from the CEO, offers of travel just to meet the team (not an interview), offers to fly out and meet with them. The whole nine yards. The number of people who get this treatment is small compared to the number of engineers, but it's not zero.