In article <a6f7dc91-e7cd-4b62-9ad9-680914a82dd6n@googlegroups.com>,
Herman <herstx@yahoo.com> wrote:
>You don't seriously think he's into programming or writing software,
>or even has a job, do you?

I don't know if he has a job now, but that he spent substantial &
formative time in Silicon Valley certainly rings true. Those
companies are full of people who "believe" various liberal-type
sentiments, but whose everyday behavior comes straight from the
far-right types who founded & still dominate the project. After
all, regardless of what SV types tell themselves, the project is
about concentrating wealth & eliminating the elite's need to rely
on workers.

On Monday, July 3, 2023 at 7:19:36 PM UTC+2, Todd M. McComb wrote:
> In article <a6f7dc91-e7cd-4b62...@googlegroups.com>,
> Herman <her...@yahoo.com> wrote:
> >You don't seriously think he's into programming or writing software,
> >or even has a job, do you?
> I don't know if he has a job now, but that he spent substantial &
> formative time in Silicon Valley certainly rings true.

I'm not spending a second thinking about this.
Why should I care?

In article <d55e869e-2e19-45bf-8707-c94c7800ce69n@googlegroups.com>,
Herman <herstx@yahoo.com> wrote:
>I'm not spending a second thinking about this.
>Why should I care?

I don't know. Why'd you post about it?

On Monday, July 3, 2023 at 5:26:08 AM UTC-7, Owen Hartnett wrote:
> On 2023-07-03 04:37:54 +0000, Dan Koren said:
> >
> > You have no idea how many graduates from top tier schools failto solve
> > my level 0 programming exercise. I see this at all levels, including
> > PhDs from the likes of Stanford, Berkeley, or Hackvard.
>
> I'm not a big fan of programming tests.

I am no fan of programming tests either.

Unfortunately, many tech companies
define their interview protocols to
include whiteboard "programming".

Individual managers decide which
problems to use from a company
approved repository, but cannot
override the protocol completely
without landing in extremely hot
water. I learned this first hand.

> When you hire a plumber, do you
> give him a test first?

No, but the analogy is not appropriate.
If the plumber screws up there may be
damage to your water pipe and to your
home or apartment. If a programmer
screws up, space ships may blow up.

> I'd rather show you my working apps
> or my existing source code.

Doesn't work. Let's say an engineering
manager at Tableau is interviewing an
engineer looking to leave Microsoft or
Oracle. They can't show their code, as
the code is confidential, protected by
trade secret law, and their "app" is a
20 million LOC database server. They
person is one among thousands of
developers who work on that product.
What do you do?

> There's books written about example
> programming test questions.

I don't use textbook problems. All my
interview problems are real programming
life problems myself or someone in my
team has encountered and solved. They
cannot be found in textbooks or on the
internet. I also ask candidates to take
the problems home and solve them in
their own time without time pressure.

> I would occasionally get asked one of
> them. If I had bought the book I could
> look up the answer and get the job.

Good luck!

> Questions like how can you tell if a
> linked list has circled back on itself.

That's below kindergarten level.

> All of them are esoteric and not likely
> to come up in real life.

How can textbook problems be esoteric?

> I'd rather hire someone who can write
> good, solid, readable, understandable
> code.

You appear to ignore the insignificant
requirement for domain knowledge.

All the coding best practices won't
help a bit if one does not have the
relevant domain knowledge. I look
for domain knowledge as well as
programming skills -- not just the
latter.

dk

On 2023-07-04 00:52:55 +0000, Dan Koren said:

> On Monday, July 3, 2023 at 5:26:08 AM UTC-7, Owen Hartnett wrote:
>> On 2023-07-03 04:37:54 +0000, Dan Koren said:> >
>>> You have no idea how many graduates from top tier schools failto solve
>>> my level 0 programming exercise. I see this at all levels, including> >
>>> PhDs from the likes of Stanford, Berkeley, or Hackvard.
>>
>> I'm not a big fan of programming tests.
> I am no fan of programming tests either. Unfortunately, many tech
> companies define their interview protocols to include whiteboard
> "programming".
>
> Individual managers decide whichproblems to use from a companyapproved
> repository, but cannotoverride the protocol completelywithout landing
> in extremely hotwater. I learned this first hand.

Instead of a test, I usually ask a candidate about what problems he had
in writing code for something on his resume, and how he was able to
solve it. If you're good at your work, you like to talk about it, and
it gives me a chance to evaluate your reasoning processes.

>> When you hire a plumber, do you> give him a test first?
> No, but the analogy is not appropriate.
> If the plumber screws up there may bedamage to your water pipe and to
> yourhome or apartment. If a programmerscrews up, space ships may blow
> up.

There are plumbers who work on spaceships, and there are a whole lot of
programmers who write bugs with little consequence.

>> I'd rather show you my working apps> or my existing source code.
> Doesn't work. Let's say an engineeringmanager at Tableau is
> interviewing anengineer looking to leave Microsoft orOracle. They can't
> show their code, asthe code is confidential, protected bytrade secret
> law, and their "app" is a20 million LOC database server. Theyperson is
> one among thousands ofdevelopers who work on that product.What do you
> do?

Most of the hiring done is not under this rigor, but if this was the
case, I'd generalize. If their resume mentioned database, I'd ask them
about their hardest concurrency or race condition issues. There has to
be something in the resumes you can ask them for.

>> There's books written about example> programming test questions.
> I don't use textbook problems. All myinterview problems are real
> programminglife problems myself or someone in myteam has encountered
> and solved. Theycannot be found in textbooks or on theinternet. I also
> ask candidates to takethe problems home and solve them intheir own time
> without time pressure.
>> I would occasionally get asked one of> them. If I had bought the book I
>> could> look up the answer and get the job.
> Good luck!
>
>> Questions like how can you tell if a> linked list has circled back on itself.
> That's below kindergarten level.

It's also a case that if you have a linked list so large that it's
difficult to detect circularity, then it's probably the wrong place to
store that data.

>> All of them are esoteric and not likely> to come up in real life.
> How can textbook problems be esoteric?

Not a textbook, but rather a compilation of classic programming
questions and answers. I know I was asked at least twice when I was
out looking for work problems straight out of the book.

https://www.amazon.com/Cracking-Coding-Interview-Programming-Questions/dp/0984782850/ref=sr_1_1?crid=3IRFG22SI1W0T&keywords=cracking+the+coding+interview+189+programming+questions&qid=1688491049&sprefix=interview+questions+for+progr%2Caps%2C97&sr=8-1

>> I'd rather hire someone who can write> good, solid, readable,
>> understandable> code.
> You appear to ignore the insignificantrequirement for domain knowledge.
> All the coding best practices won'thelp a bit if one does not have
> therelevant domain knowledge. I lookfor domain knowledge as well
> asprogramming skills -- not just thelatter.

You wouldn't expect to hire a java programmer for, say, a job coding
iOS. The culture is all wrong.

-Owen

On 7/4/2023 2:01 PM, Owen Hartnett wrote:
> On 2023-07-04 00:52:55 +0000, Dan Koren said:
>
>> On Monday, July 3, 2023 at 5:26:08 AM UTC-7, Owen Hartnett wrote:
>>> On 2023-07-03 04:37:54 +0000, Dan Koren said:> >
>>>> You have no idea how many graduates from top tier schools failto solve
>>>> my level 0 programming exercise. I see this at all levels, including> > PhDs from the likes of Stanford, Berkeley, or Hackvard.
>>>
>>> I'm not a big fan of programming tests.
>> I am no fan of programming tests either.      Unfortunately, many tech companies   define their interview protocols to include whiteboard "programming".
>>
>> Individual managers decide whichproblems to use from a companyapproved repository, but cannotoverride the protocol completelywithout landing in extremely hotwater. I learned this first hand.
>
> Instead of a test, I usually ask a candidate about what problems he had in writing code for something on his resume, and how he was able to solve it.  If you're good at your work, you like to talk about it, and it gives me a chance to evaluate your reasoning processes.
>
>>> When you hire a plumber, do you> give him a test first?
>> No, but the analogy is not appropriate.
>> If the plumber screws up there may bedamage to your water pipe and to yourhome or apartment. If a programmerscrews up, space ships may blow up.
>
> There are plumbers who work on spaceships, and there are a whole lot of programmers who write bugs with little consequence.
>
>>> I'd rather show you my working apps> or my existing source code.
>> Doesn't work. Let's say an engineeringmanager at Tableau is interviewing anengineer looking to leave Microsoft orOracle. They can't show their code, asthe code is confidential, protected bytrade secret law, and their "app" is a20 million LOC database server. Theyperson is one among thousands ofdevelopers who work on that product.What do you do?
>
> Most of the hiring done is not under this rigor, but if this was the case, I'd generalize.  If their resume mentioned database, I'd ask them about their hardest concurrency or race condition issues.  There has to be something in the resumes you can ask them for.
>
>>> There's books written about example> programming test questions.
>> I don't use textbook problems. All myinterview problems are real programminglife problems myself or someone in myteam has encountered and solved. Theycannot be found in textbooks or on theinternet. I also ask candidates to takethe problems home and solve them intheir own time without time pressure.
>>> I would occasionally get asked one of> them. If I had bought the book I could> look up the answer and get the job.
>> Good luck!
>>
>>> Questions like how can you tell if a> linked list has circled back on itself.
>> That's below kindergarten level.
>
> It's also a case that if you have a linked list so large that it's difficult to detect circularity, then it's probably the wrong place to store that data.
>
>>> All of them are esoteric and not likely> to come up in real life.
>> How can textbook problems be esoteric?
>
> Not a textbook, but rather a compilation of classic programming questions and answers.  I know I was asked at least twice when I was out looking for work problems straight out of the book.
>
> https://www.amazon.com/Cracking-Coding-Interview-Programming-Questions/dp/0984782850/ref=sr_1_1?crid=3IRFG22SI1W0T&keywords=cracking+the+coding+interview+189+programming+questions&qid=1688491049&sprefix=interview+questions+for+progr%2Caps%2C97&sr=8-1
>
>>> I'd rather hire someone who can write> good, solid, readable, understandable> code.
>> You appear to ignore the insignificantrequirement for domain knowledge.
>> All the coding best practices won'thelp a bit if one does not have therelevant domain knowledge. I lookfor domain knowledge as well asprogramming skills -- not just thelatter.
>
> You wouldn't expect to hire a java programmer for, say, a job coding iOS.  The culture is all wrong.
>
> -Owen
>

I once was debugging someone elses's Fortran program in inserted a DEBUG SuBCHK statement, which evaluates every array reference and alerts you if the reference goes out of bounds. Fortran doesn't (or didn't, this was like 40 years ago0. Well, I forgot to remove the DEBUG statement and noticed in several years later. I did a test comparing this program's speed with and without it. IIRC it was an order of magnitude difference. This was in the days where projects had budgets and my error cost several project a bunch of money until I corrected it.

Even I can make an error now and then, hard as it is to believe.

On Tuesday, July 4, 2023 at 11:01:30 AM UTC-7, Owen Hartnett wrote:
> On 2023-07-04 00:52:55 +0000, Dan Koren said:
>
> > On Monday, July 3, 2023 at 5:26:08 AM UTC-7, Owen Hartnett wrote:
> >> On 2023-07-03 04:37:54 +0000, Dan Koren said:> >
> >>> You have no idea how many graduates from top tier schools failto solve
> >>> my level 0 programming exercise. I see this at all levels, including> >
> >>> PhDs from the likes of Stanford, Berkeley, or Hackvard.
> >>
> >> I'm not a big fan of programming tests.
> > I am no fan of programming tests either. Unfortunately, many tech
> > companies define their interview protocols to include whiteboard
> > "programming".
> >
> > Individual managers decide whichproblems to use from a companyapproved
> > repository, but cannotoverride the protocol completelywithout landing
> > in extremely hotwater. I learned this first hand.
>
> Instead of a test, I usually ask a candidate about what problems he had
> in writing code for something on his resume, and how he was able to
> solve it. If you're good at your work, you like to talk about it, and
> it gives me a chance to evaluate your reasoning processes.
> >> When you hire a plumber, do you> give him a test first?
> > No, but the analogy is not appropriate.
> > If the plumber screws up there may bedamage to your water pipe and to
> > yourhome or apartment. If a programmerscrews up, space ships may blow
> > up.
>
> There are plumbers who work on spaceships, and there are a whole lot of
> programmers who write bugs with little consequence.
>
> >> I'd rather show you my working apps> or my existing source code.
> > Doesn't work. Let's say an engineeringmanager at Tableau is
> > interviewing anengineer looking to leave Microsoft orOracle. They can't
> > show their code, asthe code is confidential, protected bytrade secret
> > law, and their "app" is a20 million LOC database server. Theyperson is
> > one among thousands ofdevelopers who work on that product.What do you
> > do?
>
> Most of the hiring done is not under this rigor, but if this was the
> case, I'd generalize. If their resume mentioned database, I'd ask them
> about their hardest concurrency or race condition issues. There has to
> be something in the resumes you can ask them for.

I always construct questions and programming exercises that relate to
the work candidates claim to have done (verbally or on paper).

> >> There's books written about example> programming test questions.
> >
> > I don't use textbook problems. All myinterview problems are real
> > programminglife problems myself or someone in myteam has encountered
> > and solved. Theycannot be found in textbooks or on theinternet. I also
> > ask candidates to takethe problems home and solve them intheir own time
> > without time pressure.
>
> >> I would occasionally get asked one of> them. If I had bought the book I
> >> could> look up the answer and get the job.
>
> > Good luck!
> >
> >> Questions like how can you tell if a> linked list has circled back on itself.
>
> > That's below kindergarten level.
>
> It's also a case that if you have a linked list so large that it's
> difficult to detect circularity, then it's probably the wrong place to
> store that data.

As I said, kindergarten level. Linked lists are toxic at all levels.

The mere fact that you keep singing about linked lists tells me
you do not understand how systems work. The performance of
modern day computer hardware is predicated on good cache
and TLB performance. Nothing can be worse that linked lists
because every time one chases pointers to the next element
in the list one risks missing in the cache, and possibly in the
TLB. Industry and academia have spend the past 3 decades
designing data structures and algorithms that are far more
efficient and cache/TLB friendly than linked lists.

> >> All of them are esoteric and not likely> to come up in real life.
> > How can textbook problems be esoteric?
>
> Not a textbook, but rather a compilation of classic programming
> questions and answers. I know I was asked at least twice when I was
> out looking for work problems straight out of the book.
>
> https://www.amazon.com/Cracking-Coding-Interview-Programming-Questions/dp/0984782850/ref=sr_1_1?crid=3IRFG22SI1W0T&keywords=cracking+the+coding+interview+189+programming+questions&qid=1688491049&sprefix=interview+questions+for+progr%2Caps%2C97&sr=8-1
> >> I'd rather hire someone who can write> good, solid, readable,
> >> understandable> code.
> >
> > You appear to ignore the insignificantrequirement for domain knowledge.
> > All the coding best practices won'thelp a bit if one does not have
> > therelevant domain knowledge. I lookfor domain knowledge as well
> > asprogramming skills -- not just thelatter.
>
> You wouldn't expect to hire a java programmer for,
> say, a job coding iOS. The culture is all wrong.

That is how the industry operates, more or less. The
emphasis on specific programming languages is
unfortunate in my view.

I don't work, and have never worked, in that part
of the industry. I work on performance critical,
safety critical, mission critical systems, such
as operating systems, database servers, file
systems, etc... I do not hire "programmers".

I hire system developers, not "programmers". I do
not care what particular programming languages
they know when they interview, as they would be
expected to learn new ones anyway. The tests I
use during interviews (or to take home) are all
stated in language independent fashion and
can be solved using any language they like.

I would never waste my time interviewing
someone who describes himself/herself
as a "programmer". Relating this back to
your plumber analogy, I never hire plumbers.
I hire engineers who can build houses (systems).

If you are interested in discussing CS
topics in more detail, please follow up
by email. We do not want to cause
Herman, Andy or Marc to become
entangled in a linked list.

dk

On 7/4/2023 8:46 PM, Owen Hartnett wrote:
> On 2023-07-04 22:21:02 +0000, Dan Koren said:
>
>
> On Tuesday, July 4, 2023 at 11:01:30 AM UTC-7, Owen Hartnett wrote:
>
> On 2023-07-04 00:52:55 +0000, Dan Koren said:>> > On Monday, July 3, 2023 at 5:26:08 AM UTC-7, Owen Hartnett wrote:> >> On 2023-07-03 04:37:54 +0000, Dan Koren said:> >> >>> You have no idea how many graduates from top tier schools failto solve> >>> my level 0 programming exercise. I see this at all levels, including> >> >>> PhDs from the likes of Stanford, Berkeley, or Hackvard.> >>> >> I'm not a big fan of programming tests.> > I am no fan of programming tests either. Unfortunately, many tech> > companies define their interview protocols to include whiteboard> > "programming".> >> > Individual managers decide whichproblems to use from a companyapproved> > repository, but cannotoverride the protocol completelywithout landing
>
> in extremely hotwater. I learned this first hand.>> Instead of a test, I usually ask a candidate about what problems he had> in writing code for something on his resume, and how he was able to> solve it. If you're good at your work, you like to talk about it, and> it gives me a chance to evaluate your reasoning processes.
>
> When you hire a plumber, do you> give him a test first?> > No, but the analogy is not appropriate.
>
> If the plumber screws up there may bedamage to your water pipe and to> > yourhome or apartment. If a programmerscrews up, space ships may blow> > up.>> There are plumbers who work on spaceships, and there are a whole lot of> programmers who write bugs with little consequence.
>
>
> I'd rather show you my working apps> or my existing source code.> > Doesn't work. Let's say an engineeringmanager at Tableau is
>
> interviewing anengineer looking to leave Microsoft orOracle. They can't> > show their code, asthe code is confidential, protected bytrade secret
>
> law, and their "app" is a20 million LOC database server. Theyperson is> > one among thousands ofdevelopers who work on that product.What do you> > do?
>
>
> Most of the hiring done is not under this rigor, but if this was the> case, I'd generalize. If their resume mentioned database, I'd ask them> about their hardest concurrency or race condition issues. There has to> be something in the resumes you can ask them for.
>
>
> I always construct questions and programming exercises that relate tothe work candidates claim to have done (verbally or on paper).
>
> There's books written about example> programming test questions.> >> > I don't use textbook problems. All myinterview problems are real
>
> programminglife problems myself or someone in myteam has encountered> > and solved. Theycannot be found in textbooks or on theinternet. I also> > ask candidates to takethe problems home and solve them intheir own time
>
> without time pressure.>> >> I would occasionally get asked one of> them. If I had bought the book I> >> could> look up the answer and get the job.>
>
> Good luck!> >> >> Questions like how can you tell if a> linked list has circled back on itself.>> > That's below kindergarten level.
>
>
> It's also a case that if you have a linked list so large that it's> difficult to detect circularity, then it's probably the wrong place to> store that data.
>
>
> As I said, kindergarten level. Linked lists are toxic at all levels.
>
>
> The mere fact that you keep singing about linked lists tells meyou do not understand how systems work. The performance ofmodern day computer hardware is predicated on good cacheand TLB performance. Nothing can be worse that linked listsbecause every time one chases pointers to the next elementin the list one risks missing in the cache, and possibly in theTLB. Industry and academia have spend the past 3 decadesdesigning data structures and algorithms that are far moreefficient and cache/TLB friendly than linked lists.
>
>
> The linked list problem was one question I was asked in an interview. That's why I remember, that's all.I can't remember last time I used a linked list, but I have used tries and DAGs.
>
>
> All of them are esoteric and not likely> to come up in real life.> > How can textbook problems be esoteric?
>
>
> Not a textbook, but rather a compilation of classic programming> questions and answers. I know I was asked at least twice when I was> out looking for work problems straight out of the book.>> https://www.amazon.com/Cracking-Coding-Interview-Programming-Questions/dp/0984782850/ref=sr_1_1?crid=3IRFG22SI1W0T&keywords=cracking+the+coding+interview+189+programming+questions&qid=1688491049&sprefix=interview+questions+for+progr%2Caps%2C97&sr=8-1
>
> I'd rather hire someone who can write> good, solid, readable,> >> understandable> code.
>
>
> You appear to ignore the insignificantrequirement for domain knowledge.> > All the coding best practices won'thelp a bit if one does not have
>
> therelevant domain knowledge. I lookfor domain knowledge as well> > asprogramming skills -- not just thelatter.
>
>
> You wouldn't expect to hire a java programmer for,> say, a job coding iOS. The culture is all wrong.
>
> That is how the industry operates, more or less. Theemphasis on specific programming languages isunfortunate in my view.
>
> I don't work, and have never worked, in that partof the industry. I work on performance critical,safety critical, mission critical systems, suchas operating systems, database servers, filesystems, etc... I do not hire "programmers".
>
>
> You're correct - we're in different ends of the industry.I write apps for iOS mobile, with concerns about user interface, sudden network dropouts, performance vs. battery life, crypto, man in the middle attacks, etc., implementing new features and Apple's latest technology.
>
>
> If you are interested in discussing CS
>
> topics in more detail, please follow upby email. We do not want to causeHerman, Andy or Marc to becomeentangled in a linked list.
>
>
> I think we're good-- for now anyway.
>
>
> -Owen
>

I always believed in drafting for talent more than for position.

On 2023-07-04 18:32:47 +0000, Frank Berger said:

> I once was debugging someone elses's Fortran program in inserted a
> DEBUG SuBCHK statement, which evaluates every array reference and
> alerts you if the reference goes out of bounds. Fortran doesn't (or
> didn't, this was like 40 years ago0. Well, I forgot to remove the
> DEBUG statement and noticed in several years later. I did a test
> comparing this program's speed with and without it. IIRC it was an
> order of magnitude difference. This was in the days where projects had
> budgets and my error cost several project a bunch of money until I
> corrected it.
>
> Even I can make an error now and then, hard as it is to believe.

I once worked in a "Multi-platform" shop (the one with all the MIT
guys). Our software ran on Windows, Mac, and many versions of Unix. I
debugged an issue where someone wrote a parser for a 1512 byte file
that ran in milliseconds on every other platform except Mac, where it
took several hours! I found the reason was that the unix guy who wrote
the parser used the word Handle as a typecast for a pointer. But
Handle was a keyword in the Mac OS at the time, which defined Handle as
a pointer to a pointer (allowing it to be moved as needed). So, on the
mac, for every character in the file, his code would define a new
Handle, causing memory (in the old Mac system before OS X) to be
reshuffled and all the heap memory moved to eliminate gaps. He was
generating thousands of reshuffling calls and each call was reshuffling
a thousand object. Replacing his Handle typecast to Pointer made it
all better.

Apple says don't make assumptions on performance issues -- test real
world scenarios! It's good advice.

-Owen