vikingcaffiene

I have an OP-1 and love it. Its a mainstay in my recording and live performances and honestly my "main" synth despite it looking like a toy. I keep finding new uses for it. Example: I needed backup vocals for a part and none of my bandmates could do it. I sampled the backup vocals and just play them while I sing lead in that spot. Really cool.

As for this mixer, I would love this bit of gear but I just can't justify spending that kind of scratch for what essentially amounts to a mini mixer (which I already have). It seems really great though and it being battery powered and tactile like that is great.

Fair enough. I still think people should read stuff like this with a healthy measure of skepticism.

Gentle reminder to anyone reading this that your problems are probably not FAANG problems. If you architect your system trying to solve problems you don't have, you are gonna have a bad time.

Yeah you have to use the appropriate strategy for the interviewee. In the case of a junior, you are looking for potential and teachability as you said. You tailor your questions towards that angle. I've yet to see any take home or live coding challenge that answered those type of questions for me. All it told me is what I already knew: they were more junior and needed mentoring.

This is the right way to go. If I were looking for a job right now I'd be hitting you up. I've said as much in a few other threads but it's not only the right thing to do, its a competitive advantage.

I'm not sure a lot people know that Albini ended up washing his hands of his work with Nirvana. After the recordings were wrapped and the mixes were done, Kurt was really unhappy with some of the sounds. If memory serves it was the vocals and the bass. They ended up doing some overdubs and sharpening things up in the low end in mastering. The very thing Albini specifically said he didn't want them to do. I personally think the results speak for themselves. In Utero is a FANTASTIC rock record. I can't help but wonder what the original would have sounded like though...

While I see where you are coming from but respectfully disagree with your conclusions.

> My point is that there's less need to test people during their interviews for occupations with licensing, because they've already been tested before they even showed up for the interview.

I mean past job experience and education are pretty good indicators? Is there some facet to the accounting certification process I am unaware of that filters out under performers? If my past few accountants are any indication, then no. :)

All of that aside, I've not seen any data that suggests the hiring practices common in our field produce better outcomes than that which I am evangelizing for. Furthermore, those practices are common FAANG type companies which can offer much higher compensation packages than a typical startup. I assert that it's not only the right thing to do, it is also a _competitive advantage_ to have a streamlined, humane, hiring process.

> Hiring managers are timid about letting people go and it can take an extraordinary amount of time to part ways with unproductive people.

With respect, it sounds like you had a bad manager. Underperforming teammates are your managers responsibility. They should be working to address that issue with said teammate or part ways. Sucks. Not fun. It's the job though.

> generic backend principles are very easy to spew correct answers for without actually knowing how to code

I'm not sure I agree with this. IMO trying to get someone to explain the ins and outs of a particular facet of the technology your team works in is less effective than getting a sense of how a candidate architects their code and manages complexity. That type of "art more than a science" craftsmanship is not something you can easily fake in my experience. Maybe I'll be proven wrong. We shall see. So far I've had pretty good luck with the approach and gotten some really great teammates.

> Yea because we live in a place where everyone is super honest and no one is going to try and take advantage of that to make 500k a year.

You are right that there is more risk with this approach. I honestly think that its a better, more humane way to do things though. Anecdotally, I've hired a couple _really_ solid developers via this methodology. At least in my case, it's been working out well. As always, you try stuff and iterate.

> I'm an introvert, I suck at communicating orally.

I get it. So am I. Its actually very hard for me to reply to these comments b/c of my general aversion to putting myself out there! I don't think there's a one size fits all solution. At my company at least, being able to communicate effectively both orally and written, is important. We do a lot of pairing and documentation etc. Thats not for everyone. YMMV.

> Accountants have occupational licensing.

Forgive my ignorance, but is this during every interview? If I am reading this right this is a certification they'd need to get which would be on their resume. Do they need to re-prove those skills every time?

Thanks! So, I'll say that we are still tweaking and trying to get things just right but, as of the time of me writing this, here is the process:

- HR call 30 min.

- Talk to hiring manager (me) 30 min. Get to know each other and feel out if there is a mutual fit.

- Technical panel 1hr. Speak with several engineers on the team who share your discipline (front end or back end for example). Again no live coding. We just talk through stuff.

- Talk to the team PM. 30 min. Get a sense of how you collaborate with our product team partners to build new features in our application.

After that it's the usual comp negotiations, background, and reference checks. Assuming all that works out then hired!

We're hiring so, if anyone is interested in finding out more, contact info is in my bio.