Live data from Hacker News

A hiring test I'd like to run

shkspr.mobi

61–70 of 203 posts

Re: A hiring test I'd like to run

#61
post #6

This reminds me of the story of the young intern that went around a few years ago. They sheepishly admitted to their boss at the end of their summer internship that they had just googled all the Excel things that were required, that they hadn't actually known any of it. "But your generation KNOWS to look for help, and knows where to find it! That's where you were doing it right," was the boss's response. And that's h…

One of the biggest differences between school and business is that in business no one really gives a shit how you got something done, within reason. You just knew it? Cool. You had to do the whole thing with the manual open on the desk next to you? Is it done? Fine, don't care, that's great, not even really sure why you told me that. You enlisted someone else to help? Is it done? Good, want to be a team lead?

Of course there are constraints imposed all over, but fundamentally how you work is way less important and much more open-ended than all of school.

Re: A hiring test I'd like to run

#62

Well this is exactly like a test I went through at one time. It even used the same reasoning pretty much. The job was fullstack node and react, I went in and they said we want you to look at this game written in Python which is really slow and tell us what is wrong with it (I hadn't done python in years and back then wasn't very good at it). We will sit with you. I said I was game, they said lots of people weren't -…

Don't feel bad. I completely lost the word "virtual" in a C++ interview once.

Yet another interview where I looked like an idiot.

Re: A hiring test I'd like to run

#63
post #53
post #25

I interviewed at Twilio. My resume and phone chats made it abundantly clear that my professional experience was 95% backend in languages like Java and Go. I looked at their Glassdoor where people wrote they were heavily biased to the algorithm type questions, for better or worse. In reality I was given only a single coding interview my whole onsite, and it was to build a JavaScript SPA, including routing/linking, wit…

I don't do much hiring, but when I do I make an active effort to avoid reading candidates resumes. I've found it's not possible for me to enter an interview with an unbiased mind having read a resume.

This feels weird to me.

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.

Re: A hiring test I'd like to run

#64
post #29

This is very specifically a terrible idea. I passed an analogous interview to this once when I was much younger, and then subjected several applicants to it thinking it was a useful filter. It's not, it's abusive psychological torture that rewards sadistic amateur psychologists and interview administrators. The only way to succeed is to submit to the interviewer by asking for help. It filters for people who know to i…

From the article: > I'd tell them that at the start, obviously. This isn't The Secret Rules For Getting Hired. > "I know you've never used Blender*," I'd say, "And this job doesn't require it. But we want to see how quickly and accurately you can learn to use something unfamiliar while under pressure."

I don't think I've ever had to learn something very complex under the same short time constraints and high do-or-die pressure as an interview. Tiny things (think: new-to-me unixy commands), yeah, but nothing very complex. With as many unknowns as that introduces, should it ever come up in a real job situation with a very short time window available, my expert (I'm quite serious using that term here) advice would be that we should count on having it take quite a while, and immediately begin whatever mitigation is required to allow for that, rather than waiting to begin planning for and mitigating the harm that'll do and simply gambling that this complex thing won't surprise us and end up taking longer than we'd hoped (likelihood that it will: extremely high).

Re: A hiring test I'd like to run

#65
post #36
post #25

I interviewed at Twilio. My resume and phone chats made it abundantly clear that my professional experience was 95% backend in languages like Java and Go. I looked at their Glassdoor where people wrote they were heavily biased to the algorithm type questions, for better or worse. In reality I was given only a single coding interview my whole onsite, and it was to build a JavaScript SPA, including routing/linking, wit…

> In reality 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. > 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 u…

> 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.

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.)

Re: A hiring test I'd like to run

#66
This reminds me so much of Vernor Vinge's story "Fast Times at Fairmont High". It's set in the near future, and one plot point is that high school tests cover this skill--to read through the manuals quickly and get things done with new tools. I recommend it, and the related book "Rainbows End".

Re: A hiring test I'd like to run

#67
I don't know about this. I don't think I should spend most of my time learning completely new tools.

If people spend most of their time learning tools, that encourages tools which are easy to learn but lack deep and powerful functionality. I think it's fine, and even good, for tools to require focused learning to understand, and in exchange have a worldview and tool use that is really powerful. Like Emacs or vim or Excel, for example.

Re: A hiring test I'd like to run

#68
post #26

Earlier quoted context omitted.

I've never found anything of actual use on StackOverflow in my ~decade of doing this professionally. The only time StackOverflow provided useful answers to my questions was during my first year of programming courses in university.

StackOverflow is fine when learning a new language. But indeed, hardly seems to help in real-world problems.

It's pretty nice for "is this thing I've encountered in this (API/library/SDK/tool) with no public issue or bugtracker a bug, or am I screwing up?" sorts of questions.

Re: A hiring test I'd like to run

#69
I partially agree, and it depends on what you are interviewing for. In the end, getting a job done, on time, without error/bugs is generally most important to the people you are going to be working for.

As for algorithm questions at some FAANG or wannabe startup, it can be rough. Personally I tend to blank on a lot of terminology, similarly on names a lot of the time. Some trivia games kill me, I can see the answer's face, the movies they've been in, but just blank on the name.

All the same, in my life and career, I've managed to learn, adapt and create both simple and complex systems in new languages and platforms.

On the other side of the table, I tend to ask maybe 3-5 trivia like questions only to gauge where a person is at, and let the conversational parts determine if the person would be a good fit. I think you need some of both. I feel drive accounts for more than even skill, knowledge and experience.

Re: A hiring test I'd like to run

#70
post #60
post #49

Earlier quoted context omitted.

From my perspective, a big part of the problem is that companies don't let you know they'll be doing something like this (a simple "the 1:00 section of the interview will involve giving you a task using some tech you're not familiar with"), so it's a surprise (interviews are already stressful in ways that real work pretty much never is, "surprises" are deeply unhelpful for evaluating candidates outside very rare and…

So what would you like to be interviewed on? If it's not based on your CV/experience, general CS best practices, neither known nor unknown technologies, nor general problem-solving questions... 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…

I don't think I've directly ruled out much in the way of interview questions on in my comments on this thread, I basically just think not telling people the sorts of questions to expect and in which sections of the day, and not making it very clear what you're evaluating and why you're asking the questions, is harmful and inhumane.

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?

Post reply on HN