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

181–190 of 203 posts

Re: A hiring test I'd like to run

#181

Post by perl4ever »

Insanity wrote: post #32
war1025 wrote: 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.

You can often progress via reading wrong answers.

“I have not failed. I've just found 10,000 ways that won't work.” -Thomas Edison

...and it's so much better to learn from others' failures.

Re: A hiring test I'd like to run

#182

Post by andrewfong »

Honestly, I wish more companies would just tell you in advance of the interview what the specific prompt is going to be (and perhaps the evaluation criteria too).

Sure, you could "cheat" by Googling the answer in advance or asking someone for help. But if the question's sufficiently open-ended, it's not that hard to suss out in follow up questions whether you have a deep first principles understanding of the subject area or you're just repeating something you read.

Re: A hiring test I'd like to run

#183

Post by baddox »

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

> 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

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.

Re: A hiring test I'd like to run

#184

Post by LoSboccacc »

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

> This actually might not be so nuts if it were clearly a way to evaluate how you handle unfamiliar problems 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.

everyone is looking for their flavour of 'full stack' because in the mind of middle managers human resources need to be fluid across organisational projects.

Re: A hiring test I'd like to run

#185

Post by Swizec »

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

> This actually might not be so nuts if it were clearly a way to evaluate how you handle unfamiliar problems 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.

Because even if you're familiar with all the tech we use, you're not going to be familiar with the business domain, our cobbled-together solution on top of the tech stack, and the tens or hundreds of thousands of lines of code we nurtured over the past N years.

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

Re: A hiring test I'd like to run

#186

Post by LoSboccacc »

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…

we only got half of the story here, but if the workplace has a history of switching technology and trying new things often interviewing a specialist was still their mistake, not the specialist's, that wastes everyone time.

Re: A hiring test I'd like to run

#187

Post by _AzMoo »

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…

Couldn't you just jam a multimeter into it?

Re: A hiring test I'd like to run

#188

Post by bagacrap »

andrewfong wrote: post #182

Honestly, I wish more companies would just tell you in advance of the interview what the specific prompt is going to be (and perhaps the evaluation criteria too). Sure, you could "cheat" by Googling the answer in advance or asking someone for help. But if the question's sufficiently open-ended, it's not that hard to suss out in follow up questions whether you have a deep first principles understanding of the subject…

I'm pretty sure if you give me a subject I know nothing about and a couple days to study I can teach myself about it, at least to the level of someone who has real experience in the subject which may be a couple of years out of use. So then how does a hiring manager know to filter me out?

Re: A hiring test I'd like to run

#189

Post by brigandish »

plughs wrote: post #122
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 had a 2 hour coding project in a language I'm familiar with - entirely based around a sub module that I've never used before. 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…

I'd be more impressed if they had a mock code review as a discussion afterwards where you could explain your decisions and they could question/challenge parts of it. Not only would that give you time to settle, it'd give both parties some real insights into expectations, skills and work practices.

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.

Post reply on HN