For technical leadership roles (Eng Dir, Staff Eng/Arch, Principal Eng/Arch, etc) we're seeing internal technical bar programs -- eg Amazon's Bar Raiser. It's frustrating for seasoned engineers to take a coding test but there needs to be a way to filter out unqualified candidates from a very large applicant pool. I've heard pretty negative things about outsourcing to #Karat. Who do you think is doing this very well? #interviews #technicalinterviews #Adobe #Airbnb #Dropbox #LinkedIn #Intuit #Oracle #Salesforce #Slack #Facebook #Square #Stripe #Twitter #Uber #Chase #AmericanExpress #GoldmanSachs #CapitalOne #google #Apple #BankofAmerica
India
Yesterday
541
Who are these retards asking for dictatorship in India?
India
Yesterday
418
Modi is a legend, will be remembered for centuries to come
Tech Industry
Yesterday
1162
The end of Backdoor Roth?!
2024 Presidential Election
Yesterday
531
Heartwarming peaceful protests
Tech Industry
2d
7786
Binance founder is going to PRISON
How will you debug an issue in complex maze of 10 sync and async services calling each other, if you can't solve a self-contained 20-minute toy algorithmic problem? Joel describes it brilliantly at https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guide-to-interviewing-version-30/ "For the first interview of the day, I’ve started including a really, really easy programming problem. I had to start doing this during the dotcom boom when a lot of people who thought HTML was “programming” started showing up for interviews, and I needed a way to avoid wasting too much time with them. It’s the kind of problem that any programmer working today should be able to solve in about one minute. Some examples: Write a function that determines if a string starts with an upper-case letter A-Z Write a function that determines the area of a circle given the radius Add up all the values in an array These softball questions seem too easy, so when I first started asking them, I had to admit that I really expected everyone to sail right through them. What I discovered was that everybody solved the problem, but there was a lot of variation in how long it took them to solve. That reminded me of why I couldn’t trade bonds for a living. Jared is a bond trader. He is always telling me about interesting deals that he did. There’s this thing called an option, and there are puts, and calls, and the market steepens, so you put on steepeners, and it’s all very confusing, but the weird thing is that I know what all the words mean, I know exactly what a put is (the right, but not the responsibility, to sell something at a certain price) and in only three minutes I can figure out what should happen if you own a put and the market goes up, but I need the full three minutes to figure it out, and when he’s telling me a more complicated story, where the puts are just the first bit, there are lots of other bits to the story, I lose track very quickly, because I’m lost in thought (“let’s see, market goes up, that mean interest rates go down, and now, a put is the right to sell something…”) until he gets out the graph paper and starts walking me through it, and my eyes glazeth over and it’s very sad. Even though I understand all the little bits, I can’t understand them fast enough to get the big picture. And the same thing happens in programming. If the basic concepts aren’t so easy that you don’t even have to think about them, you’re not going to get the big concepts. Serge Lang, a math professor at Yale, used to give his Calculus students a fairly simple algebra problem on the first day of classes, one which almost everyone could solve, but some of them solved it as quickly as they could write while others took a while, and Professor Lang claimed that all of the students who solved the problem as quickly as they could write would get an A in the Calculus course, and all the others wouldn’t. The speed with which they solved a simple algebra problem was as good a predictor of the final grade in Calculus as a whole semester of homework, tests, midterms, and a final. You see, if you can’t whiz through the easy stuff at 100 m.p.h., you’re never gonna get the advanced stuff. But like I said, the good programmers stand up, write the answer on the board, sometimes adding a clever fillip (Ooh! Unicode compliant! Nice!), and it takes thirty seconds, and now I have to decide if they’re really good, so I bring out the big guns: recursion and pointers. 15 years of experience interviewing programmers has convinced me that the best programmers all have an easy aptitude for dealing with multiple levels of abstraction simultaneously. In programming, that means specifically that they have no problem with recursion (which involves holding in your head multiple levels of the call stack at the same time) or complex pointer-based algorithms (where the address of an object is sort of like an abstract representation of the object itself). I’ve come to realize that understanding pointers in C is not a skill, it’s an aptitude. In first year computer science classes, there are always about 200 kids at the beginning of the semester, all of whom wrote complex adventure games in BASIC for their PCs when they were 4 years old. They are having a good ol’ time learning C or Pascal in college, until one day the professor introduces pointers, and suddenly, they don’t get it. They just don’t understand anything any more. 90% of the class goes off and becomes Political Science majors, then they.. "