[rebootthesystem]

I think you are looking at this wrong. I have zero problems with someone presenting themselves this way and would definitely consider hiring the person.

Here's reality: Someone who knows their stuff is able to dive into details of their work in a way that an impostor can't.

My response to the above would be to have the person bring in some of their work and take an hour or two to take a deep dive into it. I want to see code, documentation, examples of trade-offs and a discussion of the reasoning, challenges, what could be made better, what should not be touched and why, project history, etc.

A conversation with someone who knows what they are doing and is very actively involved in their work is very different from a conversation with someone who might be trying to bullshit you or simply doesn't know enough.

I hate puzzles. All I learn from them as an employer is that someone might have devoted a month to memorizing a whole bunch of them for the interview.

I would imagine that at the scale of a company like Google, resorting to puzzles as a first filter might be an inevitable reality. If you have to interview people en masse you almost have no choice. It's like Stanford having to filter through 40,000 applications a year to accept 2,000 students. You have no choice but to go algorithmic on that problem.

[bskap]

The problem with your approach is that it excludes anyone who spends most of their time writing code for a business. I legally can't provide you with the code that I have written over the last several years. You're limiting your applicant pool to people who have been paid to work on open source, freelance web developers, and people with very little life outside of work.

I agree that puzzles aren't all that great of a measure of ability, but at least anyone can do them without writing about thorny legal issues over IP or spending all of their free time on spare projects.

[rebootthesystem]

Not entirely sure how you might have reached that conclusion. Anyone dedicated to their craft will naturally --out of sheer interest-- devote time and effort to getting better at it.

For example, as a young EE I was constantly reading data books (yes, physical data books) and application notes. I had hundreds of data books and probably went through all of them twice and some several times. I could, at the time, talk about almost any chip from any of the major manufacturers and knew where relevant application notes existed for most problems. My employers did not mandate that at all. I was truly interested in what I was doing.

Someone interviewing me at the time would have learned a heck of a lot more about me if they asked me something as simple as "Can you tell me about a few interesting chips and how you would use them?" rather than asking me to design a low pass filter with a given frequency response using a specific op-amp.

The deep dive I am talking about does not require anyone disclosing code done for their existing employer. Nobody wants that.

Frankly, I would also want to know about life outside of work. However, given our laws you have to be very careful about how you might probe for such information. I feel very strongly that our legal system has, to one degree or another, sapped all humanity out of our work life. I've worked in other cultures where it is perfectly normal for people to greet each other with a kiss on the cheek and a hug or pat on the back in the morning. In the US almost any physical contact can land an employer in court and a manager in serious legal trouble. But I digress.

[throwaway9475]

So here's the thing: not everyone is you, not everyone is passionate about technology, and it's not reasonable to expect people to do more of their job outside of work for free. You might like, and that's great, but people have families and hobbies and interests that sometimes have nothing to do with the 40 hours they churn through for their bosses. I'm so sick of interviewing for companies who want "passionate" developers, which translates to "doing more work for free".

If you're curious about why we have workplace harassment laws, talk to basically any woman with a job and then rethink your sweet nostalgia.

[rebootthesystem]

> not everyone is you, not everyone is passionate about technology, and it's not reasonable to expect people to do more of their job outside of work for free

I am not sure how you would twist personal development and remaining up to date with "do more of their job outside of work for free".

Let's get away from technology for a moment.

You need to go to the doctor.

Would you rather go to a doctor who is passionate about their work and constantly devoting personal time to remain up to date on the latest research, drugs, studies, techniques and technology?

Or would you rather go to a doctor who has not devoted a single day in ten years to stay up to date?

I'd pick option #1 every time. Same with engineers.

Look, if you are not interested in remaining current, that's OK. Just don't expect to have access to the same opportunities. It's as simple as that.

> talk to basically any woman with a job and then rethink your sweet nostalgia

Wow. Not sure how you made the jump to harassment there. Gender has nothing to do with it.

[throwaway9475]

> I am not sure how you would twist personal development and remaining up to date with "do more of their job outside of work for free".

Well, unless you're doing personal development at work during the 40 hours (or so) that you're required to be there, then you're probably not getting paid for it. I mean, I'm willing to tinker on my own, but you can be a good developer without doing it (you can also be a bad developer in spite of doing that).

> Would you rather go to a doctor who is passionate about their work and constantly devoting personal time to remain up to date on the latest research, drugs, studies, techniques and technology?

I want to go to a reasonably friendly, competent doctor. I really don't care how passionate they are about being a doctor, because I don't view passion as a proxy for quality (because it isn't).

> I'd pick option #1 every time. Same with engineers.

So my friend is a brilliant chemical engineer, and yet she doesn't sit around designing plants at home on the weekends. No, she hangs out with friends, sings in a choir, watches TV shows, travels, etc. I don't particularly understand the tech industry's fetish with eating, sleeping, and breathing code, and it's a damn shame that we're pushing away really fantastic nine-to-five developers.

> Look, if you are not interested in remaining current, that's OK. Just don't expect to have access to the same opportunities. It's as simple as that.

So it turns out that most software isn't created in Silicon Valley, and more money is made by crufty old Java and Perl enterprise systems than the next sexy JavaScript framework (which is probably just a poor rehash of a computer science concept Alan Kay developed in the '60s).

> Wow. Not sure how you made the jump to harassment there. Gender has nothing to do with it.

Gender has nothing to do with it if you don't experience the kind of issues that women in the workplace face, sure. If you're a man, you're not particularly affected by issues that affect women.

[pc86]

> You're limiting your applicant pool to people...with very little life outside of work.

Imagine that.

If your company exists solely to write CRUD apps in whatever JavaScript framework came out in March, you don't need to spend hours doing a deep dive into someone's side project todo list app. Unless, of course, you're looking for someone who will work 16 hours a day, 6 days a week, for one tenth of one percent.

[pc86]

> My response to the above would be to have the person bring in some of their work and take an hour or two to take a deep dive into it.

So another interview and another day off work? Another set of interview approaches/questions that immediately eliminate people who don't spend their free time doing the same thing they do at work 8+ hours a day?

This is not solving the problem.

[rebootthesystem]

Sure it does. A huge problem.

Here's reality: 100% of the technologies I work with today did not exist when I was in school. The only thing that has remained constant, useful and relevant is basic science, math, physics, etc.

What, then, make an engineer a good engineer in any domain? This applies to all aspects of engineering, from software to manufacturing engineering?

If I had to pick one thing I'd say their ability to remain current, learn and apply new unknown technologies through self study. Their flexibility and willingness to do so. Almost their drive to do so.

What I am interested in is someone who has the right approach and attitude for the job, an ability to solve problems creatively and a significant enough desire to learn. I am not looking for a robot that can memorize a hundred coding solutions in a month.

Part of the discrepancy here might lie in a difference in environment and stated goals. I have never worked in Silicon Valley but I have a feeling it is a dog-eat-dog mercenary environment where people are chewed-up and tossed out as quickly as others are hired.

If you are looking for quick hires and you are not looking at the idea of adding a team member for a long term relationship with the company and the goals of the business, yeah, sure, filter them through some quick "can you code this shit fast" puzzles and move on. Great! You are hired. Here's your desk. Here's your ankle chain. Now code away!

If, on the other hand, your industry and approach is such that you view people as a long term investment you really should not care about those skills. Anyone with decent ability can memorize coding problems. And it is worthless. What you are looking for is to bring someone on-board who will become a true asset for the business. I see it as almost short of looking for a partner. I don't care about memorized performance, I care about the ability to problem solve and the creativity, culture and thinking they can bring into the business.

These are two very different views. One is hiring cattle. The other is hiring people.

[pc86]

> If you are looking for quick hires and you are not looking at the idea of adding a team member

> filter them through some quick "can you code this shit fast" puzzles and move on. Great! You are hired. Here's your desk. Here's your ankle chain.

> One is hiring cattle. The other is hiring people.

You seem to be arguing against several points I never made. I took issue with your insinuation that you can just bring someone in for two hours and talk at length about some of their code that they bring it. That cuts out most of the hiring pool, which might be okay if you're Google, but for most companies isn't a smart move at all.

> What I am interested in is someone who has the right approach and attitude for the job, an ability to solve problems creatively and a significant enough desire to learn.

This has no correlation with programming as a hobby or having a wealth of freely reviewable code. Plenty of people love their job, are great at it, very creative, and fantastic technically and never write one line of code that isn't closed source or behind one or more NDAs. They go to work, do an amazing job, then go home after 8 hours and don't write any code or even touch a computer until the next work day.

[rebootthesystem]

If they don't have any code or project whatsoever they are able to discuss I have zero interest in interviewing them.

I have never said this is a universal formula for all to adopt. This is what I do. And it has worked very well for over thirty years across a range of engineering disciplines. Google and others can't take this approach because they need to hire people by the thousands. Not me.

Another interesting thing is to talk about someone's hobbies and passions outside of work. This is where you can learn so much about a person. People are passionate about one or more things and that is a reflection of their personality.

We do a lot of work in aerospace. There are very obvious legal barriers to disclosure there. Yet, I have always found that most engineers who are truly engaged with their craft have enough interesting things to talk about outside of work that you can really get a sense of who they are and how they will approach work.

An interesting example was when I needed someone to work on some Python code. I brought in people who had zero experience with Python. I could not care less about that. I wanted someone with some of the qualities I have already mentioned. I ended up hiring a programmer with lots of C++ experience and no Python chops at all.

The first three months were dedicated to taking a deep dive into Python while getting up to speed on the project. After that the focus shifted to the project itself. This person has been with me for many years and doing an amazing job with various technologies we didn't even know we would touch when I hired him.

I know this person can pick-up any technology we might need to utilize and do an excellent job of it.

The investment is in the person, not the technologies or the ability to memorize coding puzzles.