131–140 of 384 posts
The only real problem here is that some interviewers ask questions that are too difficult to be solved in 40 minutes unless you've already seen the question before.
I understand the attraction of simple decision metrics, more so if you're in the unfortunate position of having to make a technical hire with no experience of your own to guide you. But consider the referenced tweet that implied 250 resumes were too many to read. You're going to hire someone to do a highly complex job, spend months getting them up to speed, probably work with that person for at least a few years, and you can't come up with a way for your company to at least scan 250 resumes? I mean it's like pretty close to the one main thing you're there to do: find and hire the right people.
Knowing how to do something before I've done it hasn't ever stopped me from doing it, or doing it right. The important skill to learn is figuring out how to do it. Coding is no different. For example, I've yet to use React to build an app, but I have taken the time to learn the basics of how it works. If I needed to use it I could, and would, and it wouldn't slow me down much, if at all. I think what's important is d…
TripleByte has a very clear process which leads to a two-hour frontend interview, an hour of which will be dedicated to building something with React.
Give it a try: https://triplebyte.com/iv/NKCtNG2/it
You’ll surely learn something.
I did.
Data point: A friend of mine with 20+ years of experience in programming and security (she's been a code-level security analyst for the past decade plus) was asked in an interview the other day to implement a binary tree. Why the fuck is someone asking a lead-level expert with over two decades of experience a first-year CS question? Because that's the process? It's a total failure. Asking senior people to do basic th…
Why don’t learn this thing for once? It is not difficult, and everybody will benefit from doing that at least once, even the most senior and accoladed engineers.
It's not that it's difficult. It's that it's stupid.
edit: Let me put it this way... if you're hiring a senior/lead level code security analyst, the odds that they will be implementing (or even reading for comprehension) a binary tree are effectively nil. The odds of having to show how to mark false positives in a Fortify scan are very, very high. Can they explain buffer overflows, html encoding, etc? Can they write a description of unsafe practices in plain English, for both developers and managers? Do they have experience in conducting training classes for developers to reduce security problems? Do they have a working knowledge of HIPAA, SOX, or other relevant industry regulations? Can they do good Powerpoint presentations on this stuff?
Being a security analyst isn't about writing homework assignments from freshman year of college. It's about regulations, about training others, about using high end tools that aren't taught in college, and a bunch of other stuff. Ask questions about the actual job.
Earlier quoted context omitted.
Sometimes you really do need particular skills and experience that take decades to learn. Otherwise you don't even know what you don't know and you don't know what mistakes are usually made in a given area.
Not knowing what to do or what others did can be an advantage. Einstein developed his theory of relatively by simply discarding all the known theories about how physics worked. In my own experience at IBM, I solved a bug that had been repeatedly opened over a series of 9 years by simply asking the question, "Is this number a hex or a decimal?"
That's ludicrous nonsense. The primary breakthrough of the theory of relatively was taking what the math had been telling physicists about the universe for years seriously. In hindsight, everything necessary was there before Einstein, it just was very deeply assumed not to be reasonable. Relativity builds on numerous pre-existing foundations and is very much in the "standing on the shoulder of giants" tradition.
https://en.wikipedia.org/wiki/Theory_of_relativity#Developme... , first paragraph
I interviewed ~500 people in a fairly large (~2000 devs) company. Interviews used to take about 6-8 hours of my week, and I was usually completely destroyed by the context switch. I remember many days when a deadline was very close, and I absolutely did not want to do the interview, but had to. In general some days I was in good mood, some in bad mood and even though I tried to make the interview as objective as poss…
We need to admit that the interview process isn't about determining the relative qualifications of the applications in the pool, because we all know that 3 hours and whiteboard can't tell anything you need to know about whether or not that person will perform over the years. We need to acknowledge that we perform this pantomime in order to satisfy layers of management that are unable to accept that you can't hire for…
‘Culture fit’ (without clearly specifying what that means) is such an enormous backdoor for all manner of bias and personal prejudice I’m surprised the concept is even legal.
I don't blame them for not wanting to hire someone pushing 50. They just don't know if they're going to get the cool 50-year-old or the grumpy old troll who won't listen to anyone.
Of course they can never come out and say that for obvious reasons.
Earlier quoted context omitted.
‘Culture fit’ (without clearly specifying what that means) is such an enormous backdoor for all manner of bias and personal prejudice I’m surprised the concept is even legal.
So if I make a startup, I should be forced to hire some brilliant programmer whose personality I clash with over over a slightly less brilliant programmer who I can tell will become a fast friend just because the former has demonstrated more technological prowess?
If your hiring criteria excludes groups like that by a "fast friend" proxy test, then yeah, you should be taking the better programmer.
Earlier quoted context omitted.
Absolutely untrue. Whiteboard problems absolutely do work. The vast majority of applicants cannot code at all. And I mean that literally: they're at a loss at how to write a function that adds two numbers or counts the number of elements in a list. Worse is that these guys can be employed as developers (even 'senior' ones!) for years and years in 'serious' enterprises. How, you ask? By using copy-paste and cleverly n…
+1. I’ve interviewed senior guys, with medium to high salaries, who couldn’t do fizzbuzz. What’s worse, a lot of them were fully confident in awful solutions, and didn’t even want to test them. Talented people frustrated at the process just don’t get how bad bad coders are. I would never have believed it myself until I experienced it.
People who would ace the entire interview would look at me funny when I asked the first question, and I just said, "I mean, look: about 25% of the candidates fail this first question." Lots of others got partway through it.
It is very true that you need to qualify someone's ability to write code at all.
I think there's usually a lot less utility in some of the "clever" coding challenges that require you to remember some difficult-to-derive-from-first-principles data-structure or algorithm. But on the other hand, if we literally just give fizzbuzz to everyone, we'll eventually see people who have memorized fizzbuzz but can not create any other program.
There's a real challenge to creating a coding problem that hits the sweet spot between "doesn't just test that you had a particular intuition," "does actually test real coding skills" and "isn't so common that people have memorized the solution."
Earlier quoted context omitted.
Absolutely untrue. Whiteboard problems absolutely do work. The vast majority of applicants cannot code at all. And I mean that literally: they're at a loss at how to write a function that adds two numbers or counts the number of elements in a list. Worse is that these guys can be employed as developers (even 'senior' ones!) for years and years in 'serious' enterprises. How, you ask? By using copy-paste and cleverly n…
+1. I’ve interviewed senior guys, with medium to high salaries, who couldn’t do fizzbuzz. What’s worse, a lot of them were fully confident in awful solutions, and didn’t even want to test them. Talented people frustrated at the process just don’t get how bad bad coders are. I would never have believed it myself until I experienced it.