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

111–120 of 203 posts

Re: A hiring test I'd like to run

#111

Post by GreenJelloShot »

nkrisc wrote: post #87
avip wrote: post #73

Earlier quoted context omitted.

It is rude. People put lots of effort into resumes. But it's ruder to reject a candidate based on age, gender, martial status, education or lack thereof or doing non sw jobs in the past. I always talk on the phone before and that's where we both make sure the interview is of relevance.

> age, gender, martial status What resume has this information? This is all stuff you can infer from the interview itself.

Yeah, age I can understand. People usually list their college degree along with the date of graduation, so you can usually make a good guess about their age.

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

Re: A hiring test I'd like to run

#112

Post by foota »

clusmore wrote: post #97
foota wrote: post #95

Earlier quoted context omitted.

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…

https://thedailywtf.com/articles/the-inner-json-effect

Yes, thanks :) I thought the TLs name was Tom.

Re: A hiring test I'd like to run

#113

Post by mjevans »

tomp wrote: post #60
shantly wrote: 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 think I'd like something like this.

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.

Re: A hiring test I'd like to run

#114

Post by hinkley »

reallydontask wrote: post #54
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.…

> Some people still stubbornly refuse to look for help. The thing is that some people might feel that they will get assessed lower if they look for help rather than come up or even luck into a solution. Despite making it abundantly clear to candidates that they should take the test(s) as a pair programming sessions, we had candidates struggle with some basic stuff and not ask questions. They just kept trying things w…

We did a bulk interviewing round a couple years ago and the person I fought hardest for thought she flunked the interview because she had to dump into the debugger to figure out why her code was broken.

Going into the debugger is precisely why I picked her over several other people. People struggle with crap there is no value in struggling with and it doesn't make you a stronger coder to keep banging your head against the wall. It makes you stupid or a masochist. And I hate dealing with code written by masochists. Stupid people usually write code that is broken in obvious ways. Masochists prefer torture.

Re: A hiring test I'd like to run

#115

Post by vanusa »

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…

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

Re: A hiring test I'd like to run

#116

Post by learnstats2 »

This made me laugh - I first applied for temp jobs around this time and there was a typing test.

"Wow," said the person who had left me alone with a computer that felt old in the 1990s, "I've never seen anyone score 50WPM before."

"Uhh... I could type a lot faster, but the letter T is sticky and I had to delete a lot of Ts"

She looked mortally offended by this.

I was given a job as a dishwasher which I was sacked from after one shift.

Re: A hiring test I'd like to run

#117

Post by detaro »

avip wrote: post #73
josephorjoe wrote: post #63

Earlier quoted context omitted.

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

It is rude. People put lots of effort into resumes. But it's ruder to reject a candidate based on age, gender, martial status, education or lack thereof or doing non sw jobs in the past. I always talk on the phone before and that's where we both make sure the interview is of relevance.

Then don't have the interviewer read the resume, but have another person reading the resume give them the basic information about the expected skills.

Re: A hiring test I'd like to run

#118

Post by baumy »

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…

Chiming in to agree with you - where I work there are different coding competencies that are assigned per interviewer (e.g. good understanding of data structures and algorithms, good problem solving when dealing with ambiguity, knows how to write code that's readable/maintainable/extensible for future use cases without overengineering, etc).

I explicitly tell the candidate what I'm looking for at the very start of the technical portion of the interview. I'll say something like "this is a difficult problem and you might not finish, but that's intended since I want to see your problem solving skills", or "this problem is meant to be a little simpler so don't overthink it, I'm focusing on how you structure your code to be readable and easily modifiable if we want to change behavior or add a feature". I suspect that knowing exactly what I'm evaluating, instead of thinking they need to excel at everything, takes a bit of pressure off and allows the candidate to perform better.

Re: A hiring test I'd like to run

#119

Post by james_s_tayler »

pc86 wrote: post #47
rimliu wrote: post #46

Earlier quoted context omitted.

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

The goal is to see how you approach thinking about it and conducting your initial research. The solution is irrelevant, and falling back to "well we won't do that at work!!" is missing the point. 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…

There's a big difference between spending 50 minutes fiddling with that stuff when you're employed and evaluating it as part of the research phase for a project vs. in an interview with a gun to your head.

Re: A hiring test I'd like to run

#120

Post by hinkley »

shantly wrote: post #64
dlkf wrote: post #29

Earlier quoted context omitted.

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

I end up doing a lot of technology selection and so I have to have these skills and the ability to ask hard questions.

I don't for a second believe this should be the skillset of every member of a team. A team where everyone is adding new tools all the time is chaos. Learning new tools isn't really a goal. Getting better at your job is the goal, and learning new tools is either a means to that end or just moving the goalposts over and over so nobody knows what's going on.

Post reply on HN