A hiring test I'd like to run • Hacker News Board

Re: A hiring test I'd like to run

#101

Post by hinkley » Wed, Dec 18, 2019, 10:06 PM UTC

ditonal wrote: 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…

The last two times I went through an interview cycle (one on each side) it struck me how dependent your success was on your chosen tools and whether the coding question dovetailed with those choices or not.

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.

Re: A hiring test I'd like to run

#102

Post by badfrog » Wed, Dec 18, 2019, 10:07 PM UTC

ses1984 wrote: post #19

Some of the tests in my current company work like this. We don't expect you to have everything memorized. We give you a problem and then say, "feel free to use any reference you want, help, man pages, google, stack overflow, whatever." Some people still stubbornly refuse to look for help. Some people act on the first google search result even though it's obviously wrong. Some people don't know how to read a man page.…

I've seen the opposite issue. I'll tell a candidate "I don't care if you know the exact function name and parameter order for the library function the get a sub-array; just make up something reasonable and focus on solving the bigger problem." And they still look up the actual function definition.

Re: A hiring test I'd like to run

#103

Post by organsnyder » Wed, Dec 18, 2019, 10:10 PM UTC

city41 wrote: post #99

At my previous company, the technical interview was 2 hours long. The candidate was given a choice of about 10 very small, simple projects. Then we sat at a pairing station and paired on the problem. The candidate can use google, their favorite editor, write tests, anything they want. The goal is not to finish the project, but just code with them for 2 hours. It's the best technical assessment I've yet seen in an int…

I did an interview once at a company that is religious about pair programming. I found the exercise unsettling: would they evaluate technical ability or culture fit more? If they were focusing on the former, I should take the wheel and try to demonstrate my chops (perhaps making me appear arrogant); if the latter, I should try to demonstrate how I can collaborate with the other developer to make both of us better (perhaps at the expense of me not demonstrating as many skills within that brief window of time).

It turns out that they were really focusing on how I interacted with the fake "client" and whether I had the proper "consultant mindset". Didn't see that coming (perhaps that's my fault). Though I feel I ended up dodging a bullet in not getting an offer from them.

My suggestion is to try to give candidates specific times to demonstrate various competencies (technical, colleague interaction, customer-facing), and tell them which ones are the focus of each exercise. Yes, that's not how the real world works (you need to utilize them all at the same time, of course), but an interview setting is hardly the real world. And you'll still see glimpses of their overall capabilities in each stage.

Re: A hiring test I'd like to run

#104

Post by hinkley » Wed, Dec 18, 2019, 10:14 PM UTC

rimliu wrote: post #46

shantly wrote: post #36

Earlier quoted context omitted.

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

> "to evaluate how you handle unfamiliar problems" The only problem here is figuring out why would anyone work for a company with these practices. Unless I am missing something and it is common practice to build a product without any thinking, research and design.

I think next time I'm just going to ask them if they merge a lot of PRs that look like what they're asking me to write, and if they say yes, thank them for their time and leave.

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.

Re: A hiring test I'd like to run

#105

Post by city41 » Wed, Dec 18, 2019, 10:18 PM UTC

organsnyder wrote: post #103

city41 wrote: post #99

At my previous company, the technical interview was 2 hours long. The candidate was given a choice of about 10 very small, simple projects. Then we sat at a pairing station and paired on the problem. The candidate can use google, their favorite editor, write tests, anything they want. The goal is not to finish the project, but just code with them for 2 hours. It's the best technical assessment I've yet seen in an int…

I did an interview once at a company that is religious about pair programming. I found the exercise unsettling: would they evaluate technical ability or culture fit more? If they were focusing on the former, I should take the wheel and try to demonstrate my chops (perhaps making me appear arrogant); if the latter, I should try to demonstrate how I can collaborate with the other developer to make both of us better (pe…

That's a really good point. I honestly don't remember if we gave the candidate a heads up in that regard. In general interviewing is extremely imprecise. It's an unsolved problem unfortunately, but I feel most companies "fix" the problem by just over-interviewing and being ok with false negatives.

Re: A hiring test I'd like to run

#106

Post by hinkley » Wed, Dec 18, 2019, 10:24 PM UTC

dillondoyle wrote: post #88

notkaiho wrote: 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…

This is such a valuable skill. For our work we've found this ability to google or find answers without incredibly specific step by step instructions to be lacking from many younger workers. I've wondered if others have found this for many smart people under 30 as well?

I really believe there are too many important things to know at this point, and so I instead concentrate on memorizing the bounds of the Realm of the Possible. I know what my tools can do, I know where the pitfalls are, but I don't always recall the exact details of those boundaries. I often have to look up why, and I'm perfectly okay with that.

Where that doesn't work well is in interviews, and in places where people think it's perfectly reasonable to have technical discussion meetings where laptops are banned. We're really going to make architectural decisions without looking at any code? Who thought that was a good idea?

Re: A hiring test I'd like to run

#107

Post by GreenJelloShot » Wed, Dec 18, 2019, 10:26 PM UTC

hinkley wrote: post #101

ditonal wrote: 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…

The last two times I went through an interview cycle (one on each side) it struck me how dependent your success was on your chosen tools and whether the coding question dovetailed with those choices or not. 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,…

Most interviews seem to weigh heavily in favor of "sprinters" over "marathoners". That is, they select for people who can go from nothing to working code in a short period of time.

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.

Re: A hiring test I'd like to run

#108

Post by zebraflask » Wed, Dec 18, 2019, 10:28 PM UTC

ScottFree wrote: post #72

BiteCode_dev wrote: post #50

Earlier quoted context omitted.

I don't know. I'm very comfortable in JS, valilla, jquery, react and vue. And apparently my customers think I do a decent freelancer work since they keep hiring me back. 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 requirem…

I've done a similar test. I didn't finish it in the time allotted, but a few other candidates did and they hired one of them. The fact companies can do these kinds of demanding frontend tests and still hire people is what makes me think there's a glut of web developers and not a shortage like people keep saying.

There's a glut of resumes that have something web dev on them, and a scarcity of reliable ways to filter for the candidates who legitimately have the skillset(s) needed for the job.

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.

Re: A hiring test I'd like to run

#109

Post by GreenJelloShot » Wed, Dec 18, 2019, 10:34 PM UTC

avip wrote: post #96

tristor wrote: post #79

Earlier quoted context omitted.

If you can't read someone's resume without rejecting them based on age, gender, marital status, education or lack thereof, or for their non-sw work history, then it sounds like you're not a very good person to be interviewing candidates. The concept of "unconscious bias" might be true in an academic sense, but in a very real way you should be treating people with respect regardless of their characteristics, especiall…

>it sounds like you're not a very good person to be interviewing candidates 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.

I would honestly love to take a job that was 100% focused on interviewing and hiring technical people. I have been through so many bad interviews (on both sides of the desk) that I think it really should be a dedicated position staffed by people who actually understand the major defects in the industry.

Re: A hiring test I'd like to run

#110

Post by [deleted] » Wed, Dec 18, 2019, 10:36 PM UTC

foota wrote: post #95

athenot wrote: post #65

Earlier quoted context omitted.

> 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 conc…

Man, this reminds me of the story about the person that gets a position at a new company and it turns out they have a ridiculous tech stack where it's a custom language. The new person comes in and adds comments which breaks everything and somehow files have like a version history which affects how they run? Anyone have the link to that? There's some individual that developed all of it and gets the new person fired f…

[deleted]