Job Interview : switch(char) again! Twenty years on!

I've spoken about some of the strange interviews I've enjoyed over the years; notable engineering highlights were having test driven development spooned to me, when I simply didn't know the particular syntax they were demanding, or having StringBuilder suggested for a C# task where they actually needed to cross-core thread their problem, or pointing out that the CI solution being described would lead to an alien environment of folks being paralysed by fear of red flags; only to witness their development floor being paralysed by exactly those issues as I walked out the door.

Today however, I'm going to go way back and talk about one of the very early development interviews I had; this maybe like the third interview I ever had after graduating, it was with a rail rolling stock company, in a very bright and sunny room with three guys who seemed to know their entire universe was correct and they'd take no new information into their sphere of understanding.

I share this one as a friend of mine was in touch over the weekend, he had an interview, and strangely he had the exact same conversation I had... THE EXACT CONVERSATION, twenty something years later.

Let us start by sharing some perfectly valid C++ code:

bool validate(const char& value)
{
switch (value)
{
case 0: return true;
case 'x': return true;
default: return false;
}
return false;
}
int main()
{
const bool isValidOne{ validate('a') };
const bool isValidTwo{ validate('x') };
const bool isValidMe{ validate(12) };
}

Read this code, we should see an output (if we output the bools) of "false", "true" and "false"... I think we can all agree.  This is perfectly valid C++.

It isn't very clean nor pretty, we're relying on the compiler standard decaying char to int and vice versa; which is not very nice and I wish compilers would complain here, that we're comparing int to char in the first case and we're converting the integer 12 to char, I think it should really strong type this.

But that is not the point, the point is that both in my friends case and mine all those years ago the interviewers got really uppity about that "switch" statement.  They insisted that you can not "switch" on a character type...

Just flat insisted.

I remember in my experience they had me write up what they wanted on a blackboard, with chalk, and they wanted me to go through the code line by line; I wrote more or less the above, they insisted they had a character not a byte (uint8_t: though there was no standard for this at the time) and then they went off on this tangent amongst themselves about the value of the if-elseif-else stanza's they insisted would work over my solution above.

Now I was talking to these guys in the early 00's, my friend however was talking to them in 2023.  He jumped on this with the point of "well if the character is known at compile time, yes then constexpr maybe of use" and he showed them:

if constexpr(foo) and if consteval(bar) examples.

He described their faces screwing up and two of the chaps he was talking to staring at each other before making subtle notes on their paper.

It was very clear at this point that the CTO performing the interview was not keeping his knowledge up to date, the group seemed to cluster onto the idea of just maintaining what they have, stagnation like this in our joint experience can be problematic.  Both team morale and high turn over of engineers always happens when things stagnate.

I have to say in my interview I actually sat it out from beginning to end and just knew I was not interested in the role; and I did not hear from them again.

My friend however, he was genuinely concerned he'd done a good interview and they'd be offering him a role, they kept him talking for over an hour and a half!

He's a late 40's engineer of 25+ years experience, just like me; the three chaps interviewing him, including the CTO, were ten or more years his junior, it seemed they were looking to back up their team with an older head to lend legitimacy to things; and they had lost two original engineers of their project to literal retirement without replacing them.

He saw the issues and he thanked them for his time and left, with a negative to whether he would be interested in going further.  This stunned them.

It has to be said, so many interviewers forget that though they are interviewing you, you are also interviewing them like most all human interaction it is a two way street and it's crucially important to remember that in a job interview.  We spent a significant amount of our time at work, if you are not comfortable there or feel you are going to be acting out a role instead of filling one and making it your own.

Technology CV's and Me

I've a small gripe with technology recruiters, if any of you out there are reading this (which since I just cast my CV around, you should be).

And this is their penchant for skills lists... I have a very minimalist CV, one page of A4, it covers the primary software languages I like (C++, C, C#) makes mention of my favourite working styles (Agile/Scrum) and it has my history and pertinent academic background.

That's all... Minimal, just me, my page one shot done.

Anymore and it never, ever, gets me anywhere.  It apparently comes across as "hey look at me" attempts to garner and keep attention with the right buzz words, which I myself despise.  Or it comes over as not having a lot to talk about in the interview, as everything you want to know might very well be in this tome of a CV, and I myself reading them find that I want to ask every question I can in the interview stage, so having it all there you disengage, hurting both your interest in the candidate and their chance to explain themselves to you.

So a long CV, in someways, is counter intuitive.

But then the skills list raises it's head, no my CV does not have a specific skills list, at the top is says Software Engineer.  That tells you everything you need know.

You don't got for brain surgery and stop the surgeon to ask whether they've the right skills to use a bone saw, did they spend two years in orthopedics first, did they complete their GCSE's.  No they're a brain surgeon.

So why when I present I'm a software engineer do you get these niggly folks asking "Do you know Java?"... "Hows your skills in C#"... or "You don't have enough experience on XboxOne"....

I literally laugh, I'm a software engineer, a good one, I live for tech, I can, have and will pick up any new language, machine or skill-set desired and very quickly.  I set out in the mid 90's to train for this, I was sitting up all night long tinkering on my computers and programming long before that official water-shed moment.

Therefore I have to ask,why do you need to put down these skill sets?  Why do you need to use the right buzz words?  Well, I think there's a two fold reply to that very question, first of all you may not be speaking to the most tech savvy of individual, they might just have a check-list of the right words, or the right fit to get you over the threshold and passing that initial interview.  Phone interviews are a bit of a blessing in this way, as you get to lay down your own proof of worth quickly.

The second reply being that the folks doing the hiring don't actually know what they are hiring, either because they remain the non-tech-savvy, or more commonly (more sadly) they've never met or worked with an engineer who has a genuine passion for their topic.  Yeah sure you can program, but are you interested in it?  Quite often the answer is no.

Many programmers I meet today are below that level of going in their own time to hack around with things, they're too busy life having grown out of what they see as the adolescent pass-time of tinkering.

I however value my tinkerers, they're the soul of the literally machine, driving innovation, improvement and even just evangelizing about new-ways and approaches to enhance their colleagues.

Such individuals are rare, I consider myself to be one, and hate when I'm asked to pour my soul into soulless lines on a page, get to know me, you never know... You might learn as much from me, as I might learn from you.

Development : No Great Shakes at SQL

I was just handed a technical test, this was for a job interview, and I was a little... well I'll say surprised, but then shocked, by the reply, lets take a look...

I was handed these SQL statements, in several questions, and then told to summarise what I should see on any output of the various instructions....

create table customers (id INTEGER PRIMARY KEY, name Text, age INTEGER, weight REAL);

insert into customers values(73, "Brian", 42, 33);

insert into customers values(1, "Helen", 12, 12.5);

select * from customers;

SELECT name, CASE WHEN age > 18 THEN "adult" ELSE "minor" END "type" FROM customers;

create table orders (id INTEGER PRIMARY KEY, customer_id INTEGER, desc TEXT);

insert into orders values (0, 73, "Apples");

insert into orders values (1, 73, "Oranges");

insert into orders values (2, 1, "Bananas");

select * from orders;

SELECT customers.name, orders.desc FROM customers JOIN orders ON customers.id = orders.customer_id;

I drew up the two tables, their info, the results of the selects and the listing of each order by the last point.

The final question was then, "alter the final query so that only orders by customers named "Brian" are displayed.

My answer was this:

SELECT customers.name, orders.desc FROM customers JOIN orders ON customers.id = orders.customer_id where customers.id = (select id from customers where name = "Brian");

Now, I'm no great shakes at SQL, it's a tool to be used, not a mantra to adhere to, so I understood that I could also solve this problem thus:

SELECT customers.name, orders.desc FROM customers JOIN orders ON customers.id = orders.customer_id where customers.name = "Brian";

Both are valid results, and yes I admit mine results in another query (within the parenthesis) however, in my mind I wanted all parameters directly in a query to be the result of other queries, meaning I could place "Select customers where name is 'Brian'" into a function elsewhere for ease of maintenance, rather than have "Brian" hard coded into the query here.

I discussed this when myself and the technical reviewer went over my suggested solution, I explained "The query in the bracket should be stand along, either as a separate query or stored procedure".

He made a note on his clip board, and I thought nothing more about it.

Fast forward a fortnight, and this morning I heard back from this job, they said I was a very good candidate, but failed the technical test on one key point.  I looked at my notes, nothing looked that key.

I left it there, and went back to the recruiter but asked them for specific technical feedback.

The feedback I received, just an hour ago...

"Over thinks the solution to a problem" and they cited the above answer.

I am flabbergasted, it seems people really would rather my not give a valid answer, or perhaps don't want to discuss the decisions I passed through in order to reach my conclusion.

Either way, I think my solution is valid, my point about being able to move the latter query into its own location is valid, code maintenance is important to me, so being able to break down none-nonsensical ordering things like SQL statements is high on my radar, but to be told I am essentially "too verbose"... I'll be frank, it's pissed me off.

But hey, what do I know?... I'm no great shakes at SQL.