My policy, before finding a place I like and plan to stick around at, is no programming tasks. There's plenty of companies desperate to hire than you can be picky if you know your stuff. I also will walk out if they start up with those 'clever' programming questions that have nothing to do with the job.
You took out the time to go to some office. You just spent an hour talking about your hobbies and attitudes and the company's working culture etc. Then, a programmer asks you to balance a red/black tree. You do.. what? You angrily throw the marker on the ground, cry insult, and run out the building? No, right? So then what?
I see this repeated a lot on HN and I'm not sure I'd have the guts to walk out of an interview. To be honest, I doubt many people do.
In the current market there’s abundance of junior or mid-level developers from body shops applying to senior level positions. If you cannot stand from this crowd and shine by balancing the tree right, why someone would care hiring you? I can tell you plenty of stories about people who had impressive background and great soft skills, but in the end barely can do their job.
> If you cannot stand from this crowd and shine by balancing the tree right
I don't think memorization of an algorithm is what should make a senior level candidate stand out. Senior people need to be able to lead, mentor, self manage (this is a huge one IMO), and understand the bigger picture. "How do we avoid having to balance this tree at all?"
The role of the senior Engineer isn't to tell you how to balance the tree. You, or anyone you instruct to, can simply ask google that or use a library.
Their role is to ask why we need to balance the tree. You very definitely can't ask google that, and that's why you need to hire a senior Engineer.
It’s one of the ways, for sure. But it is really interesting to me how a person without deep knowledge of fundamentals can lead or mentor anyone while being on a non-management position? They are supposed to gain authority from their professionalism, but without theoretical knowledge they won’t be able to justify their decisions, and then what? What exactly they can teach anyone?
As a senior/lead developer with years of broad experience you don't need to remember details of every algorithm in existence. But you should keep information scrap in your head to guide you or your apprentice to relevant source of information.
"Hi <dev name>! I think we may need to optimize memory consumption of this distinct element counting code a bit; I remember there is some HyperLogLog algorithm which should help here... let's check how it goes... (reading Wikipedia page)[0]"
On a first date you don't do boring everyday stuff becouse you don't want to spend time on that.
My experience is that hireing descicion is so noisy that there are no reason to invest too much since the rate of sucess is barely increased anyway.
The more picky the employer seems the less reason to apply. It might be a internal candidate allready chosen or they are just hoarding resumés to keep recruiters occipied.
The decision is allready made from the from the first minutes ... but you can ruin it of course.
The last time I applied to a company, I ask them all of this. Something in those lines "Hello, I use your product FooBarTools everyday and it help me a lot. I really like it. It is nice piece of software. bla bla bla. I see that you have some opening positions in your careers page. bla bla bla. I would love to be a part of the improvement of FooBarTools. bla bla. What is your hiring process? What do you expect a senior/midlevel/junior should be able to do? bla bla. Thank you for your time. Have a nice day."
> I don't think I'd have the guts to walk out of an interview either, especially for a job I applied to first.
Have you no common courtesy? I terminate the process as soon as I find out I'm not a good fit for the company or vice versa, no matter who initiated first. Continuing with an interview when I'm sure I'm going to decline is just wasting everybody's time.
Not really in this case. If you go to the job you like saying that the shitjob offered you 2x the salary... and they call your bluff? Now what? Take the shit job you are not going to take? For that you could have bluffed with an empty hand anyway.
I was condoning lying about offers or salaries on offer, just that having more offers signals a perspective employer that you're a desirable candidate.
I've heard of companies asking for proof of other offers so saying so and so offered me 2x is a very risky play if untrue.
I just use recruiters to do all the leg work and tell them my requirements. Always had made sure to still bring it up during the phone screening. Only once had they brought me in and started with the quiz nonsense.
I have walked out of interviews as well. Sometimes the interviewer and I discover together that the recruiter we worked with didn't know their job, at all!
More often, though, it sort of was clear from the start of the interview that the company would not be a good fit for me. I would tell them so, and my reasons why I thought so, and leave after thanking them for their time.
If they ask me to do some simple programming task, I ask them if they have looked at my Github repository and what they think they will learn during the simple task they could not from my repository. If they do would have a good answer for that, for example they want to get to know my thought processes while coding, I am happy to oblige. But if they clearly have not looked at my Github repositories, nor have any inclination to customize the interview process, I tell that I do not believe in the validity of the process.
I have also walked away twice during the one-month trial period. Once the company was unable to find a project for me, even though they kept on promising there would be one for me soon. The other time I discovered I was unable to combine working full-time with finishing writing my PhD thesis.
Anyway, I also found that in half of the cases I walked out,
the other party did understand and accepted why.
Of course, it is easy to walk away when you know you will find a job soon anyway and even if you would not you will get some support from the government anyway.
I did. I walked into the hiring manager's office and he barely looked up while asking me to decode the complex declaration on the white board that wrapped twice. My departing words were along the lines of: if you and your team write code like that, this is not a match. So I left.
A cute thing to do whenever someone sandbags you with trivia is to suggest going over to the developer desks and asking everyone in turn if they know the answer. If you find someone that does, you answered the question. If you don't, then you suggest doing a web search, and you have also shamed your interviewer.
If they don't wave you off at the suggestion, you also get to meet everyone and see their work environment.
I remember an interview at Coinbase I should have walked out of. The first question was "what is the angle between the hour and minute hands of an analog clock at 3:15?" It went downhill from there.
I think you're totally right to walk out on puzzle questions. But if you avoid companies that make sure you can program, aren't you worried about the skills of your colleagues?
There's other ways to evaluate if someone can program. A "4 hour" take home test for example isn't a good one as they could easily cheat or spend more time on it. In person tests are often setup to test your memorization which let's be real, how many of us don't google stuff on the daily?
What I feel is more important is a persons thought process on how they approach a problem and come to a solution.
