451–460 of 471 posts
Earlier quoted context omitted.
How do you stop people from "getting help" on the take home problems.
Why would you penalize an employee for getting help on a problem? Stack overflow away. Troubleshooting is an essential skill.
Earlier quoted context omitted.
We are a remote company. I give take home projects too. Mostly I give them couple of days but mention they shouldn't work more then 4 hours on it. Our test is actually quite simple and everyone that did any kind of development should have done these basic things. But it tells me a log of the current state of the candidate. Most code samples on internet are not production ready code. Security and error handling are mo…
> they shouldn't work more then 4 hours on it So you're saying spending 3 and a half hours on the assignment is fine. It's not. Take-home assignments have little to no value for the candidate, they're only feasible if you are jobless or in college. The last thing I want to do in my spare time is to stay focusing on a bogus problem that may end up discarded.
Talking on-site or on the phone? Is that better spent time
Earlier quoted context omitted.
I had a former coworker re-write a library we had open sourced as their own. They had used the original version at work so knew it well, knew the internals by asking lots of questions while working for performance reasons. They renamed things and changed pointers around to their preference. They did this right before they left and had it on github as their work. They could meet all of your questions. They didn't real…
One question is, if someone is doing elaborate deceptive work like this, gets hired and has no problems performing the job, does it actually matter? Some people mostly or entirely code at work, so this looks like a legitimate way to get a "good" project in GitHub that he knew well. It sucks that it's deceptive (which could be a major red flag), but it's also clear enough that he understood a large codebase well enoug…
I live in Sweden and we seem to have a very different interview culture. I've never heard of whiteboards or trivia questions, here. I've only gone to four interviews (across eight years), and been lucky to get an offer each time (three of which I've accepted). They have all been primarily discussions about personal experience, hobby projects, personal interests, would-be responsibilities, benefits, and company cultur…
I saw both sides in Sweden. Including being the interviewer who discovered that senior applicants with over 15 years of experience could not for the life of them figure out how to reverse a string. Not something that I could have found out during our casual conversation about past experiences, of course.
(Nothing against whiteboards or laptops or paint brushes, just wondering)
What type of job were they applying for?
Another tech interview thread. For the side that supports these types of interviews, I've never gotten a good answer to a simple question: in the year 2020, why are we expecting people to write compilable code on a whiteboard? It's just stupid at this point. Even a laptop that boots into some micro linux distro and has nothing but nano open would be better. Or just a fresh install windows laptop with nothing but note…
In my (bitter) experience, in the pre-covid days, they had a laptop in the meeting room and you got to choose between it and the whiteboard.
Oh God, here we go again. Coding on a whiteboard in an interview is not "broken". What is "broken" however is making the problem the candidate needs to solve "hard". I can't stress this enough: a whiteboard coding test is nothing more than a negative filter . It's to filter out people who can't turn a simple idea into code as these people exist. This is why FizzBuzz was such a simple problem. But interviewers fall in…
I interviewed a FAANG company and made to the whiteboard interview. The interviewer asked me to implement an algorithm to extract words from arbitrarily long string, which do not include any separators, using a dictionary, within 30 minutes and a code that compiles into $PROGRAMMING_LANGUAGE on the spot. Pseudo-code is not allowed. Yeah, I tanked the interview but I really did not care if I pass when I got to that po…
how would you have liked that?
Oh God, here we go again. Coding on a whiteboard in an interview is not "broken". What is "broken" however is making the problem the candidate needs to solve "hard". I can't stress this enough: a whiteboard coding test is nothing more than a negative filter . It's to filter out people who can't turn a simple idea into code as these people exist. This is why FizzBuzz was such a simple problem. But interviewers fall in…
I agree with this. I work at a FAANG that does whiteboard coding interviews (opinions my own, etc etc). When I interview people, I give pretty straightforward questions. My goal is not to run some algorithm guessing game. If I'm interviewing for a senior FE position, I make sure they know enough about async patterns in JavaScript that I feel confident that they could build an event handler without dropping promises o…
Id take a look :-)
Earlier quoted context omitted.
I'm not sure why you're being downvoted for asking about their previous work and watching how they treat people.
Eh. I don’t care about downvotes. But yeah if people want to throw the same ten dozen puzzles at each other and then wonder why the people don’t work out, it’s definitely not time to try anything different :)
> service workers ...
> watching how they treat people
They are not people though. But yes, agreed that we should treat them well
I agree that the cliché whiteboard interview is just awful – I've had my share of terrible ones. However, there is one form of whiteboard interview that I really like – it's where the interview is about system design and architecture rather than coding problem nonsense. I think the first time I saw this was at Google, where the question was pretty much "We are going to design Google Maps from scratch – what does it l…
> a system that we want to build. We let the candidate lead the design
They never got upset and thought they were working for free?
If you were to use their designs and ideas, then what if they later claim you've infringed on their IP?
Earlier quoted context omitted.
In other words the companies that 99% of the world's developers work for. What they are "resorting" to is a hiring process that finds good developers at a reasonable cost. "We can't pay you what FAANG pays but we don't put you through a shitty and lengthy interview hazing" is a pretty good proposition to the vast majority of us.
Most companies don't even have spare billions of dollars to waste playing these games. Your normal companies, with normal budgets, have normal projects, which need people who can get work done. If you want some one who can build web sites using React JS you are better off hiring people who know and have built things using React JS. There is little logic in hiring people who can do some obscure fashion-of-the-week alg…