Location: SF Bay Area
Remote: Preferred, but not required
Willing to relocate: No
Technologies: AWS, Go, JavaScript, Python, Node.js, React, Ruby, Serverless
Skills: Executive leadership, technical architecture, engineering mentorship, people systems, product strategy, recruiting and hiring, org structure design, internal communications, growth, vendor management
Resume: https://www.linkedin.com/in/danielerickson/
Email: techwraithpdx@gmail.com
Looking for: VPE, CTO, or engineering executive position, full time
I was previously VP of Engineering at Eaze, CTO at Getable, an early engineer at Yammer and Storify, and ran a web application development agency for a few years. I'm just throwing this out there to break my bubble and widen the potential matches. See this thread on twitter for more about what I'm looking for: https://twitter.com/techwraith/status/1178738333490368513
Eaze's mission is to improve lives by providing safe, secure access to the highest quality cannabis products at the lowest prices with the utmost convenience. We are seeking passionate, talented and innovative leaders to join our world-class team and help shape history.
To learn more about who we are, our engineering culture, and whether this is the right place for you, read our Key Values profile: https://www.keyvalues.com/eaze
Clear and respectful communication is one of the most important skills for an engineer to have.
If you read the second half of my answer in the article I go into the communication side of things. In my experience there are better ways to evaluate a candidate's emotional intelligence and social skills than asking them to code in front of someone.
I'd say you should stick to your guns - I like your approach. Interviews are inherently adversarial: "are you good enough for us to hire you?", "are you better than the other 5-10-1000 candidates". As a result there's a built-in bias which makes whiteboarding a bad fit.
I've written code on white boards at work, and I've discussed about code on white board with colleagues or managers. It's not the same thing as during interviews. The schedule is never as tight, scrutiny is way laxer and the overall mood is completely different when I'm working with colleagues or even bosses.
I kind of understand why the BigCo's do it (they need a super rigid filter since they have so many candidates), but in their case they could select for people with the best pink leotard on interview day and they'd still get decent programmers, because their companies are in such high demand and they generally already control their markets (software, natural monopolies, etc.) and can afford to pay a ton so the competition would be cutthroat anyway.
VPE at Eaze here (the original author of the quote above) -
You're 100% correct. We give our candidates the choice between working through a problem at the office (on the spot as you say) or doing a take home project asynchronously. Not everyone has the time to do homework, but not everyone wants to do an in person coding interview either. We try to stay flexible.
Thank you for the response. I appreciated your take on the situation in the original article and I am glad to hear that you accommodate developers like me that don’t perform well for strangers on the spot. This type of thing really pushes a company up the ranks if I’m interviewing with them.
I think this is a great approach. It keeps the company flexible to hire a broad array of talent under differing circumstances while also letting the interviewee play to their strengths.
How do you compare the resulting apples & oranges? I can do a lot more at home (especially if I cheat on time, which everyone who really wants your job and can afford to do will do)
We're less concerned with the resulting code than we are about your ability to explain the code that you wrote and your ability to prove to us that you have good judgement when making technical decisions.
Also, we're growing fast enough that we're rarely comparing candidates. If we can hire both the apple and the orange (assuming both candidates are evaluated to be good for the role), we will.
I'm actively looking/interviewing and really like the "cut of your jib". (both your answers here, plenty of aspects of Eaze as a company, the prospect of moving back to SF...)
For both the sr backend and devops positions, how important to the roles is familiarity/experience with your technical stack? I might have some of the skill set/experience you're looking for -- sr backend engineer, sr systems engineer, devops are all positions I've held -- but honestly I don't know JS, .NET, or Chef. Bluntly, I don't want to waste your (or my) time. ;)
<tiny>Also, I wish HN supported private replies</>
Do you want to work for PlayStation Network team? We have plenty of open positions from DevOps to server or client side developers. And variety of work also there - commerce, social, video streaming, distributes databases, big data, ml.
We care less about your particular technical skills than we do about your generalized engineering skills. Specific stacks are easy to teach; fundamentals, emotional intelligence, and social skills are harder to teach.
In fact, if someone is too into their stack, we see that as a bad sign.
So I'd be super excited if you decided to apply :)
