5 ms·
As a senior engineer who already has a good job, here's how I've adapted to the stupid tech interview and plan on doing for future jobs: - Stay at my job longe
by bit_logic 10y ago
As a senior engineer who already has a good job, here's how I've adapted to the stupid tech interview and plan on doing for future jobs:
- Stay at my job longer and push for more raises/promotions. So far this has worked well. I may not get more in raw $ amount vs job hopping, but when risk adjusted (the risks of any new job such as bad manager, etc.) it's worked out ok so far. I think some job hopping is still good early career, but at this senior level, job hopping loses most of its advantages. Also, being senior at a company (not just in title, but also tenure), has other benefits such as more influence and connections within the company.
- For future job searches, companies that don't have the algorithm/data structures interview will get a big boost in my list. They will get first attention.
- If I find an interesting job that still has the bullshit process, then my investment in the process will be very low. Basically, one or two evenings refreshing my memory on basic algorithms/data structures and that's it. If the interviewer asks a question expecting me to know some exact algorithm or trick, then they are a very poor interviewer and the problem is them, not me.
- meowlicious 10y agoI am in the same boat, I have over a decade of experience doing all sort of thing. But I was recently rejected by netflix because I used java 7 instead of java 8 in their coding interview because 'it shows them that I don't keep up with latest tech'. Full details of the ridiculous charade here https://medium.com/@meowlicious99/my-software-engineer-interview-at-netflix-259bb94e5f46#.qqp95gfcg https://medium.com/@meowlicious99/my-software-engineer-inter...
- AnimalMuppet 10y agoIf you have a job with decent pay, sane management, and reasonably good co-workers, do not casually walk away from it. I've been too many places that didn't have one or more of those. All three in one place... well, think twice before leaving that.
- mtberatwork 10y agoAgreed, and I think this is a lesson learned far too late in life. I had a job early in my career that gave me immense satisfaction which I gave up to live a life in a bigger city and a bigger salary. If I could talk to my younger self, I would tell myself to stay put for as long as possible. Sanity at your job is worth its weight in gold. Fortunately after many years and a few more job changes, I've found a spot that gives me the same satisfaction again. Sure, I may not make the huge salaries as some of my friends do, but the pay I have is decent by any measure and comes with great benefits and a high quality of life. I plan on riding this one out until I retire and that feels pretty good.
- bsvalley 10y agoI like your first point, though your 2nd and 3rd points tell me you haven't applied for a while :) They've all adopted the google model, small or big companies it doesn't matter. You start with a 45 minute technical phone screen (algorithm/data structures), sometimes a second tech phone screen, an onsite of at least 5 hours with at least 3 to 4 45-minute technical screens (algo/data structures) as if it wasn't enough... let's repeat the same exercise 10 times to make sure you'll fail at least once... Finally, an additional "culture fit" 45 minute chat with a director or VP at the end of the onsite. An additional home assignment is given to you when they have too many candidates to chose from. So it's not just about skipping companies who ask stupid questions and definitely not about working only one or two evenings on algo stuff. Trust me I've been through this process recently with 15 companies! I worked for a bunch of top companies in the past and I can attest, it is extremely painful. They want robots now and interviewers are lazy and annoying. How naive I was when I carefully selected the only company and job I was interested in at the beginning. Then I went through the process and got smashed in the face. I had to align another 20-30 companies to get at least 10 to 15 tries, then an offer. An offer from choice #15?? That sucks... it's 2017 and things have dramatically changed.
- noir_lord 10y agoThat sounds pretty awful. I've been programming for half my life and I'd fall over on that stuff.
- louthy 10y agoI've been programming 3/4 of my life and I'd fall over on that stuff. I'm a CTO of 12 years and I'd fall over on that stuff. I have a successful open-source project [1] which is all algorithms and data-structures, and I'd fall over on that stuff. At some point interviewers must get it, that these artificial test environments bear no relevance to how we write code in the real world, and putting these false constraints on a candidate just creates stress, and in no way communicates their competence. Luckily for me (as an interviewer) I do get it. And I suspect that's part of the reason why I've not had a developer leave my company in the 12 years we've been running. I do a first interview, which I keep super chilled and chatty, just trying to get the candidate to relax. I'll focus on projects on their CV, asking high-level questions. Again, no stress. Then if they say anything interesting about a part of a project I may drill down a bit more to make sure they understand the subject they're talking about. Which is slightly more stressful, but if they're competent, they'll know. I very rarely go into algorithms and data structures. It'll usually be if I'm concerned about a junior dev not having enough CS knowledge. I then send them an email post interview (if I think I want to see them again for the second interview). The email will have a link to a partially complete project, I ask them to finish it based on a written spec. It shouldn't take more than 45mins - 1hour. The request in the spec is intentionally a bit obscure. I put at the end of the spec that "If you have any questions or problems, please email me. You won't be marked down for this." The obscureness of the test is to see who emails me to ask for help. That for me is a real positive sign. So I'm trying to create a real world test: * A spec to follow * Programming in a comfortable environment * Access to dev resource (Google/Stack Overflow/Their friends) * Access to their boss for advice And to avoid anybody trying to game it and blag their way with code that they didn't write, I quiz them about their decisions in the second interview. It works amazingly well. My dev team is something I'm super proud of. A good team of people who collaborate well and believe in the product. No hierarchy or in-fighting. It's a happy place to be. So I endorse this method :) [1] https://github.com/louthy/language-ext https://github.com/louthy/language-ext