Anyone who uses a keyboard to navigate their computer (most software professionals worth their salt) hit the escape key often enough to warrant it as a complaint. Try not using your mouse for your computer
Anyone who uses a keyboard to navigate their computer and has not already re-mapped their keyboard to put esc into a more RSI-friendly location is going to be paying for this choice in a decade or so...
I had the same experience. I was straight up lied to by the salesmen. I talked about it to my bank, they were aware of the problem as it happens to a lot of people. BMO offered to open a new bank account, and move all my funds to it and close my account that goodlife tricked me into using.
I was told that I could cancel any time after a free trial. It turns out I was lied to. I went to see the salesman again as it was on my way. Telling him that I switched my accounts made shut up and look defeated. Felt so good.
>I had the same experience. I was straight up lied to by the salesmen.
My appointment was for 2pm... when the rep showed up at 3pm... his first response was literally "oh hey... you're actually 30 minutes late for our 2:30pm appointment so I'm going to have to cancel.."
I told him I had been waiting there since 2pm (and he had seen me waiting there since 2pm) and then he began to take my fraudulent cancellation data of my moving to another country.
When I used to use Facebook, I had it filtered because I avoid any targeted news headlines. I think targeted news headlines are dangerous because they can be used as propaganda devices.
I disagree too. I think that humor should be allowed on hacker news. I mean as long as the jokes aren't at the expense of the ideology of the majority of hacker news's users. In that case, that humor should be downvoted and removed.
Whiteboard problems work great as a general intelligence test if administered correctly. A well designed whiteboard problem will filter out people of lesser intelligence. This means the people you would be working with would generally be more intelligent. This is not a bad thing.
Furthermore, whiteboards are great communication tools. I spend some time on VRChat's whiteboard room teaching people various algorithms, and other abstract things to help me learn. Someone who knows how to use a whiteboard and communicate correctly would be a better hire than someone who doesn't.
If the company you work at uses whiteboard problems to vet interviewees, just drill them. With a little practice, you'll have a better chance.
This is so wrong that it actually hurts my brain. Albert Einstein, a certifiable genius probably could not tell you how to invert a binary tree, this has nothing to do with intelligence and everything to do with how many HackerRank problems you have memorized.
True, but there are also brain-teaser type problems that don't require memorization of obscure algorithms, and those could actually be disguised intelligence tests. (But I suppose if you really wanted to you could memorize most of the brain-teaser problems in existence.)
Obviously, but I was specifically referring to the typical algorithm oriented whiteboard questions found at major tech company interviews. Working a real world problem on a whiteboard I see no issue with.
Whiteboard problems are used to show that you can work through a problem, while communicating well about your thought process. They're also good general intelligence tests, if administered correctly.
I think an obvious reason for this type of interview problems is because developers at work usually talk loudly while solving problems and write code without the help of any external resource while the clock is ticking in the background. Oh, wait...
What both you and the parent post you're deriding are missing is white-boarding (when done correctly) isn't about the problem at all. It's just an easy way to get a candidate in the room and construct a technical conversation.
As an employer I don't care how great your skills are, if you can't walk me through your thought process for 45 minutes you're not going to be overly successful. If you can't incorporate feed back or engage when pressed to change your design you're probably not going to be successful.
Do your recruiting right and you shouldn't need the white board to simulate whether the candidate can code at all (I think white-boarding with the intent of looking for named algorithms is a waste of everyone's time), instead you want to see if they can synthesize information, engage with other people, and otherwise display the soft skills that tend to be much more useful metrics for employee success than coding aptitude.
Granted, my industry is known for not having deep coding problems to solve, this strategy might not be as useful in verticals that require more technology chops.
>As an employer I don't care how great your skills are, if you can't walk me through your thought process for 45 minutes you're not going to be overly successful. If you can't incorporate feed back or engage when pressed to change your design you're probably not going to be successful.
The post you're responding to makes a great point that this isn't the normal working environment for 99% of actually-writing-code developers. I discuss and iterate designs with my coworkers/leads/managers/architects just fine, but a surprise algorithmic problem you have to simultaneously solve, draw on a whiteboard, and constantly present to an audience while being timed isn't something I have been great at. I bet many others aren't either. I got good at it after a few interviews last time I was looking for a job; but if I hit the interview trail again today, I'm confident that I would flounder in that setting for a while.
Imagine if, instead, the candidate worked out a project -- maybe at home, or maybe in an interview room for some time -- then you take time to review and understand their work and then go through this back-and-forth process of discussing their work. This would also benefit the candidate's understanding of how you collaborate to problem solve in your work environment.
The problem with this approach is that it requires the interviewer to actually invest time to understand the candidate's work.
Anyway, I hope you see why many see it as a problem that the process for a candidate to succeed at a job interview is to practice interviewing skills rather than demonstrating their engineer skills.
> As an employer I don't care how great your skills are, if you can't walk me through your thought process for 45 minutes you're not going to be overly successful.
As an investor, I don't care how great your skills are, if you can't come up with your new business idea on the spot and walk me through your thought process as you're doing it, you probably suck.. right?
Nah.
Unless you already have the answer, the first step is to come up with the solution. This could involve time spent alone just thinking, or brainstorming with coworkers, or researching the problem on the net, etcetra. What the right steps are depend on the problem, available resources, your background, even your preferred way of working.
The second step is to present and dissect the solution. I dare say this is the point at which the majority of engineers have no problem whatsoever talking about their thought process.
Do you work in an industry where engineers genuinely have to walk somebody through their thought process while they're trying to think up a solution?
If a problem comes up at a meeting and you don't have a solution on the spot, you take note and discuss it later or add it on the agenda for the next meeting. I think that's how people work.
I don't care about where, when, and how you came up with the idea. I care that you can present and discuss it once it's ready for that.
I think this is why many prefer the take-home test. They can focus on the solution. Then, at the interview, they can focus on the talk about the solution. It's also a great equalizer as e.g. people coming to work in a domain they have less experience with can take more time to research the solution space.
The complaints about homework taking up too much time may be valid, but I'd be most happy to trade 2 hours of interviews for about 75 minutes of homework and 45 minutes of interview.
"When done correctly" is the key here. Alas, in my experience I was usually heavily penalized if I kept my mouth shut for as little as 15-20 seconds because interviewer "couldn't see my thought process". At the same time expecting from me to write syntactically and semantically correct, industrial strength bug-free code with optimum space and time performance for a problem I never ever encountered with the interviewer "helpfully" distracting me 4-5 times a minute.
Divining rods are trusted by many, and have been in use for centuries. If they weren't a good way of locating water, why would so many people use them?
> They're also good general intelligence tests, if administered correctly.
And communism probably redistributes wealth if it is administered correctly.
If companies want to hire based on general intelligence (not personality, team work, communication and so on) then they should administer IQ tests, which are based on a century of rigorous research. That would at least give you a fighting chance of measuring G.
Why do you think white boarding can measure general intelligence?
