Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A hiring test I'd like to run

shkspr.mobi

Post reply on HN
Print view View original

171–180 of 203 posts

Re: A hiring test I'd like to run

#171

Post by perl4ever »

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'm old enough to be covered by age discrimination laws and think I'm better than a lot of people at finding things, and I believe a key reason is that Google deliberately, and perhaps many other types of search accidentally, tries to turn every search into a few results from a single cluster. The only way you can find a different cluster a lot of times is by already knowing it exists, or knowing that the garbage cluster you get is garbage and then you can modify your search terms, or read additional pages of results.

What experience provides is not knowing everything about everything, but the meta-knowledge whether there is an answer out there, and whether you've found it yet. Inexperience results in stopping too soon in your search, either giving up or settling for something flawed.

Really, who can expect people to solve the halting problem fresh out of college?

Re: A hiring test I'd like to run

#172

Post by perl4ever »

reallydontask wrote: post #71

> 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." > Or whatever. The main problem is that the level of pressure that people feel under interview conditions will vary dramatically. Pers…

If someone says there was a lack of culture fit, it stings and certainly could be some type of illegal discrimination. But at the same time, it's necessarily true! Unless your culture is discriminating unfairly...

Re: A hiring test I'd like to run

#173

Post by iliketosleep »

GreenJelloShot wrote: post #107
hinkley wrote: post #101

Earlier quoted context omitted.

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

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

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.

Re: A hiring test I'd like to run

#174

Post by Merad »

numlock86 wrote: post #33
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…

> 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. The point of such interviews is to see how you handle a situation with limited time and - like in this example - mostly new tech and paradigms to you. Usually you are not expected to output anything.

What exactly would you be hoping to see the candidate do in such an interview? I’m moderately experienced on the front end (mostly jQuery and React, a bit of AngularJS) but if the task is making a SPA in vanilla JS I’d barely know where to begin. It’s pretty likely that I’d do hours of reading and researching before writing a single line of code. It would be one thing to talk about how you’d approach the task, but the GP specified their interview was apparently expecting workable code to be produced during the interview.

Re: A hiring test I'd like to run

#175

Post by perl4ever »

shantly wrote: post #85
mcguire wrote: post #62

Earlier quoted context omitted.

Don't feel bad. I completely lost the word "virtual" in a C++ interview once. Yet another interview where I looked like an idiot.

You're not alone. At this point I'm pretty sure the majority of reports that there are lots of people lying on résumés and also being able to convince people in conversation that they know how to write software but who can't actually do [basic programming task] or answer [basic programming trivia question] are just cases of interview-stress-induced stupidity in otherwise competent devs being taken for savvy and insan…

Well, there also might be a selection effect in that most people who are competent and bad at that style of interview find other ways to get hired, so grifters could be at least overrepresented somewhat in those who bang their head against the wall.

I have never been hired via a process that involves a technical quiz or in person programming, and the last time around, one such farce was my limit. If I was competent and not able to pass that sort of filter, then I kind of had to find another way.

Re: A hiring test I'd like to run

#176

Post by perl4ever »

cushychicken wrote: post #147
scrooched_moose wrote: post #40

I'm a mechanical engineer by training and still occasionally do some entry level hiring in it. My favorite question in recent years has been posing an advanced project - not unreasonably difficult, but one I know they won't have covered in school. Make it clear I don't expect them to have the answer, but have them talk through their approach to this project with me. "How would you get started?" "What would you need t…

I'm an electrical engineer, and I have a similar question that I ask my entry level candidates - "How would you measure the voltage coming out of a wall socket?" It's familiar enough to be accessible, but technically just far enough out of their reach that they don't know exactly how to do it. We talk about approaches, tools they could use, some potential problems or issues they'd need to overcome. If they get fluste…

Is a religious certainty you need a true RMS meter a plus or minus?

Re: A hiring test I'd like to run

#177

Post by LanceH »

jedieaston wrote: post #138
notkaiho wrote: post #129

Earlier quoted context omitted.

... But why?

To see how they respond under pressure.

Today's changing markets demand employee's who can adapt quickly.

Or static old companies seem to want employees who don't notice change around them.

Re: A hiring test I'd like to run

#178

Post by perl4ever »

tracker1 wrote: post #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…

Maybe you just can't figure a person out in an interview. I got my current job as a contractor/temp, and thinking back to a previous company, one of the people that was the best and stayed the longest was a contractor that "graduated" to permanent. The simplest way to prevent people from keeping up a facade is just time.

Re: A hiring test I'd like to run

#179

Post by astrofinch »

oarabbus_ wrote: post #89
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…

Great anecdote, thanks for sharing. I myself have some stories about poor tech hiring all over the place. 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.

What poor hiring practices does Google have?

Re: A hiring test I'd like to run

#180

Post by perl4ever »

edent wrote: post #20
commandlinefan wrote: post #12

> Are they able to read a manual? Uh, I can read a manual (in fact, I enjoy reading software documentation), but it's going to take me longer than an hour...

Let me amend that. Are you able to look up information in a manual - either using the index or hitting CTRL+F?

There is enormous variation in the quality of different indexes (indices?) The whole concept of an index, at least since computers have been around, should be that it's better than a full text search, but that's not something you can automatically generate.
Post reply on HN