Protein interface – how to change aproach to building software?(trojanczyk.eu)
trojanczyk.eu
Protein interface – how to change aproach to building software?
https://trojanczyk.eu/are-software-engineers-protein-interface/
6 comments
You sound like you have a really valuable experience and skillset. In your opinion, how would you go about technical interviewing in a way that makes sense?
Interviewing is outside my skill set, so take this with a grain of salt, as it's just the sort of question I'd like to answer:
"We have an application that needs to run inside a vehicle, which means the power will be killed at regular, but unpredictable, intervals. How would you design this to ensure data integrity?"
It's weird enough that few people will have solved it before, but it can be solved at every layer between circuit and application, so you can actively brainstorm with the candidate to draw out some of their solutions into more detail.
And if they start with, "well, I'd build a react app," you can go straight into the trash can with their resume, because you can have that whole discussion without deciding on so much as a language, much less a framework, so you can see who jumps too hastily to wrong assumptions.
"We have an application that needs to run inside a vehicle, which means the power will be killed at regular, but unpredictable, intervals. How would you design this to ensure data integrity?"
It's weird enough that few people will have solved it before, but it can be solved at every layer between circuit and application, so you can actively brainstorm with the candidate to draw out some of their solutions into more detail.
And if they start with, "well, I'd build a react app," you can go straight into the trash can with their resume, because you can have that whole discussion without deciding on so much as a language, much less a framework, so you can see who jumps too hastily to wrong assumptions.
(Parent comment did mention the grain of salt, so my response below is to the spirit of the comment itself and not directed at the person).
> And if they start with, "well, I'd build a react app," you can go straight into the trash can with their resume, because you can have that whole discussion without deciding on so much as a language, much less a framework, so you can see who jumps too hastily to wrong assumptions.
So you would reject someone based on the first thing they say? That’s called prejudice - maybe they don’t have the systems programming lingo in place to describe the ideas you are looking for, but might actually have some ideas trending in the right direction given some nudging. Also, that sounds like you gave a systems programming problem to someone who may have specialised in react the last two years - did you read their resume?
Seeing how complex this discussion gets every time on what is the “right” way to interview and how biased people can get (things haven’t changed in a generation - it used to be about picking the wrong Java library I heard) - no wonder Leetcode has emerged as a “fair” standard-bar that everyone in computing has an actual shot at clearing.
That said, Leetcode-style does bias towards people who have time, resources, and not many responsibilities, especially with problems trending to ever more esoteric algorithms. I don’t know the solution.
> And if they start with, "well, I'd build a react app," you can go straight into the trash can with their resume, because you can have that whole discussion without deciding on so much as a language, much less a framework, so you can see who jumps too hastily to wrong assumptions.
So you would reject someone based on the first thing they say? That’s called prejudice - maybe they don’t have the systems programming lingo in place to describe the ideas you are looking for, but might actually have some ideas trending in the right direction given some nudging. Also, that sounds like you gave a systems programming problem to someone who may have specialised in react the last two years - did you read their resume?
Seeing how complex this discussion gets every time on what is the “right” way to interview and how biased people can get (things haven’t changed in a generation - it used to be about picking the wrong Java library I heard) - no wonder Leetcode has emerged as a “fair” standard-bar that everyone in computing has an actual shot at clearing.
That said, Leetcode-style does bias towards people who have time, resources, and not many responsibilities, especially with problems trending to ever more esoteric algorithms. I don’t know the solution.
I perhaps explained poorly in two cases:
I'd knock serious points for anyone who mentioned any languages (except in the context of talking about low-level features of that language that would help solve the problem),
and I don't see it as "systems programming" because it absolutely could be answered at the application level. It could also be solved with a battery pack (systems level) or immutable storage (hardware level), to name a couple others. The point is giving folks an opportunity to talk in the areas of their experience, and the strongest devs have taken a break from VSCode to do other stuff which adds value to solving problems holistically.
I'd knock serious points for anyone who mentioned any languages (except in the context of talking about low-level features of that language that would help solve the problem),
and I don't see it as "systems programming" because it absolutely could be answered at the application level. It could also be solved with a battery pack (systems level) or immutable storage (hardware level), to name a couple others. The point is giving folks an opportunity to talk in the areas of their experience, and the strongest devs have taken a break from VSCode to do other stuff which adds value to solving problems holistically.
Clearly, you need a bank of magnetic core memory.
I can:
A) Relate to the GP, and
B) Answer the question
For (B), my experience was that LeetCode was worthless, as I was looking for a senior-level engineer, to come into an established team, and start being a contributor, ASAP.
I spent 25 years, hiring experienced coders, and ran an established team, that was part of a much larger, established organization. Headcount was really difficult for me to get, and the company was cheap. They were a huge name, and assumed that everyone was fighting to join the company.
If you were a photographer, that was the case. If you were a programmer, that was definitely not the case.
So I had a challenge.
I suspect that the low-end salary chased away most people that were only looking to hop onto a short-term, salary multiplier gig. Pretty much everyone that I interviewed was serious about getting involved in some extremely interesting work (C++ image processing pipeline development).
I got folks to talk about their passions and projects. The best way to figure out how folks work, is to ask them to wax eloquent on problems they've solved, and projects they wrote.
I would have killed for large GitHub portfolios. I loved long résumés, and would definitely have spent a lot of time, reviewing them, if they were offered.
I think I basically made good choices. There was never a technical misfit. In a couple of cases, the person couldn't integrate too well into the team. I had a very relaxed environment, and each team member had their own proclivities and workflow. We made it work; I suspect the fact that they all had decades of experience, helped.
I kept people on board for decades (not an exaggeration). Remember I said that headcount was such a bitch to get? That was a big reason for me wanting to keep people. Also, the Japanese team would barely acknowledge their existence, until they had been at the company for at least a year.
In my experience, someone who is good at interview tech questions, is good at interview tech questions, but that does not give me any clue, as to how they will be, when they hit some of the rather hairy (often threaded) algorithms we had.
I had to take risks. If an employee did not work out for at least a couple of years, I got grief. So I got highly competent, experienced C++ engineers to join, for low-ish salaries, and I kept them, for many years. I guess that's not a valuable skill, in managers, anymore.
I think I did OK.
[UPDATE] I made it more about me, to try to make the comment a bit less abrasive.
A) Relate to the GP, and
B) Answer the question
For (B), my experience was that LeetCode was worthless, as I was looking for a senior-level engineer, to come into an established team, and start being a contributor, ASAP.
I spent 25 years, hiring experienced coders, and ran an established team, that was part of a much larger, established organization. Headcount was really difficult for me to get, and the company was cheap. They were a huge name, and assumed that everyone was fighting to join the company.
If you were a photographer, that was the case. If you were a programmer, that was definitely not the case.
So I had a challenge.
I suspect that the low-end salary chased away most people that were only looking to hop onto a short-term, salary multiplier gig. Pretty much everyone that I interviewed was serious about getting involved in some extremely interesting work (C++ image processing pipeline development).
I got folks to talk about their passions and projects. The best way to figure out how folks work, is to ask them to wax eloquent on problems they've solved, and projects they wrote.
I would have killed for large GitHub portfolios. I loved long résumés, and would definitely have spent a lot of time, reviewing them, if they were offered.
I think I basically made good choices. There was never a technical misfit. In a couple of cases, the person couldn't integrate too well into the team. I had a very relaxed environment, and each team member had their own proclivities and workflow. We made it work; I suspect the fact that they all had decades of experience, helped.
I kept people on board for decades (not an exaggeration). Remember I said that headcount was such a bitch to get? That was a big reason for me wanting to keep people. Also, the Japanese team would barely acknowledge their existence, until they had been at the company for at least a year.
In my experience, someone who is good at interview tech questions, is good at interview tech questions, but that does not give me any clue, as to how they will be, when they hit some of the rather hairy (often threaded) algorithms we had.
I had to take risks. If an employee did not work out for at least a couple of years, I got grief. So I got highly competent, experienced C++ engineers to join, for low-ish salaries, and I kept them, for many years. I guess that's not a valuable skill, in managers, anymore.
I think I did OK.
[UPDATE] I made it more about me, to try to make the comment a bit less abrasive.
It’s ridiculous to say that the go to hiring strategy for most of the highest paid positions in the world is useless. The only trend I see that I agree with from leetcode dissenters is that it doesn’t make sense when you have issues maintaining headcount. I’m a newb, and I definitely have no experience hiring, but it doesn’t take ANY intelligence to know that leetcode makes sense when you have a long list of halfway decent applicants.
Whether or not it’s ethical. I don’t know. Having to take the time to practice for an interview is going to select privileged folks.
Whether or not it’s ethical. I don’t know. Having to take the time to practice for an interview is going to select privileged folks.
> leetcode makes sense when you have a long list of halfway decent applicants
It lets you build a team of people who are good at leetcode, but I won't be on that team. Which is a shame, because my t-shape is wider and deeper than most engineers. I just can't solve fake problems about how many ways there are to combine a string quickly.
Why isn't there a refactoring section of the tech screen? Hand me 5,000 lines of garbage code and let me figure out what it does, why it does it, and how we can improve it. Those are the kinds of problems I actually have practice solving.
It lets you build a team of people who are good at leetcode, but I won't be on that team. Which is a shame, because my t-shape is wider and deeper than most engineers. I just can't solve fake problems about how many ways there are to combine a string quickly.
Why isn't there a refactoring section of the tech screen? Hand me 5,000 lines of garbage code and let me figure out what it does, why it does it, and how we can improve it. Those are the kinds of problems I actually have practice solving.
The companies that use dsa puzzles in their interviews wouldn't do it if it wasn't reasonably good at avoiding false positives.
Does it test for enthusiasm? Of course not. My company isn't big enough to use dsa puzzles in interviews, and I wish we were. Unfortunately, I've been on teams with a developer who couldn't crunch strings. Leetcode interviews get the job done of avoiding those people (at the cost of also cancelling people like yourself). It's just like tests in college. They suck, and everybody hates them, but they're around because they get the job done.
Your example of 5000 lines is laughably to my point. That's a totally unrealistic filtering process.
Does it test for enthusiasm? Of course not. My company isn't big enough to use dsa puzzles in interviews, and I wish we were. Unfortunately, I've been on teams with a developer who couldn't crunch strings. Leetcode interviews get the job done of avoiding those people (at the cost of also cancelling people like yourself). It's just like tests in college. They suck, and everybody hates them, but they're around because they get the job done.
Your example of 5000 lines is laughably to my point. That's a totally unrealistic filtering process.
> I've been on teams with a developer who couldn't crunch strings. Leetcode interviews get the job done of avoiding those people
My main objection is that it's _timed_ crunching. The juniors can solve three toy problems in two hours because they've been drilling them nonstop for six months. I can finish any Medium and some Hard questions, but the Hards may take me 4 or 6 hours.
And yet, in the real world, I close tickets twice as fast as they do, because I grok the problem space quickly, don't head down as many dead ends, and know before I start when to escalate because this ticket isn't a ticket, it's an epic.
My point is solely that any test where a fresh graduate can reliably outperform someone with decades of experience is objectively not a very good test. I'd go so far as to say the universal reliance on LeetCode is a big part of why greybeards are underrepresented in dev teams.
My main objection is that it's _timed_ crunching. The juniors can solve three toy problems in two hours because they've been drilling them nonstop for six months. I can finish any Medium and some Hard questions, but the Hards may take me 4 or 6 hours.
And yet, in the real world, I close tickets twice as fast as they do, because I grok the problem space quickly, don't head down as many dead ends, and know before I start when to escalate because this ticket isn't a ticket, it's an epic.
My point is solely that any test where a fresh graduate can reliably outperform someone with decades of experience is objectively not a very good test. I'd go so far as to say the universal reliance on LeetCode is a big part of why greybeards are underrepresented in dev teams.
You’re just a crotchety old grumpy greybeard is what you are. (Teasing)
I think it’s plain as day to both of us that the new grads are outperforming experience because of practice. You could practice to get your solve times down below new grads.
I posit that the dsa puzzle interviews have become prominent as a solution to a very specific problem: lots of very qualified applicants. When done correctly (with many rounds and equally qualified evaluators), the interviews produces few false positives (when it comes to being able to code effectively).
Does it find people who are passionate about software? Does it find people who are good at refactoring complicated codebase? No and No, but the people it finds can stay afloat in a scrum.
Finding the real gems is extremely difficult.
I think it’s plain as day to both of us that the new grads are outperforming experience because of practice. You could practice to get your solve times down below new grads.
I posit that the dsa puzzle interviews have become prominent as a solution to a very specific problem: lots of very qualified applicants. When done correctly (with many rounds and equally qualified evaluators), the interviews produces few false positives (when it comes to being able to code effectively).
Does it find people who are passionate about software? Does it find people who are good at refactoring complicated codebase? No and No, but the people it finds can stay afloat in a scrum.
Finding the real gems is extremely difficult.
But it's totally realistic. LeetCode reflects academia, a world in which all problems are solved in 100 lines or less, thread collisions don't exist, and the context is stable.
My first major software job, which I went into, with almost zero experience, was to maintain 100,000+ LoC of FORTRAN IV code, 1970s vintage, in one file; accessed via 300 baud VT-100 terminals, and line printers that sounded like an M60. No documentation, and stepped on by every junior engineer before me. It was awful, and taught me the value of writing good code, and leaving a legacy[0].
This is the cloc output for the Swift iOS project I'm working on now:
BTW: That's only about half the code. I have thirteen dependencies (that I also wrote -except for one small one). They are non-small projects, each in their own right.
My understanding for the reason for LeetCode tests, is because there's a big problem with total fakes presenting as qualified software engineers, and the tests are just there, to make sure they can even code.
I never encountered anything close to that, in my career. Quite a few folks presented résumés that claimed skills they didn't have well-developed, but it was pretty easy to figure that out, in a quick conversation.
I actually hired some of those folks anyway. The stuff we worked on wasn't something they taught in school. Everyone is starting from scratch. I looked for enthusiasm, eagerness to learn, and problem-solving skills.
[0] https://littlegreenviper.com/miscellany/leaving-a-legacy/
My first major software job, which I went into, with almost zero experience, was to maintain 100,000+ LoC of FORTRAN IV code, 1970s vintage, in one file; accessed via 300 baud VT-100 terminals, and line printers that sounded like an M60. No documentation, and stepped on by every junior engineer before me. It was awful, and taught me the value of writing good code, and leaving a legacy[0].
This is the cloc output for the Swift iOS project I'm working on now:
54 text files.
54 unique files.
0 files ignored.
github.com/AlDanial/cloc v 1.92 T=0.06 s (863.2 files/s, 477430.9 lines/s)
-------------------------------------------------------------------------------
Language files blank comment code
-------------------------------------------------------------------------------
Swift 54 3961 11281 14626
-------------------------------------------------------------------------------
SUM: 54 3961 11281 14626
-------------------------------------------------------------------------------
BTW: That's only about half the code. I have thirteen dependencies (that I also wrote -except for one small one). They are non-small projects, each in their own right.
My understanding for the reason for LeetCode tests, is because there's a big problem with total fakes presenting as qualified software engineers, and the tests are just there, to make sure they can even code.
I never encountered anything close to that, in my career. Quite a few folks presented résumés that claimed skills they didn't have well-developed, but it was pretty easy to figure that out, in a quick conversation.
I actually hired some of those folks anyway. The stuff we worked on wasn't something they taught in school. Everyone is starting from scratch. I looked for enthusiasm, eagerness to learn, and problem-solving skills.
[0] https://littlegreenviper.com/miscellany/leaving-a-legacy/
> It’s ridiculous to say that the go to hiring strategy for most of the highest paid positions in the world is useless.
Hey, be nice. I was talking about my experience, in my career, which was fairly unique.
I managed to make some very picky people fairly happy, for a long, long time.
Hey, be nice. I was talking about my experience, in my career, which was fairly unique.
I managed to make some very picky people fairly happy, for a long, long time.
Need to work on my writing. Was annoyed at your leetcode dissentism and and wasn’t able to contain the annoyance. My b, dog.
Hope to have a similarly long and satisfying career.
Hope to have a similarly long and satisfying career.
Have a conversation with someone who can recognize the experience, and not be threatened by it. Look for the candidate to tell war stories about technical challenges, leadership challenges, interpersonal challenges and how they solved them and what they learned. Read their resume and recognize multiple stints of increasing responsibility at quality companies means something.
Have people worked in such a place where "on deck" engineers are hired out? Why wasn't there enough work to assign? How long were you contracted out for? I'm having a hard time imagining how this would work. It seems to me like it won't be very long until there's work people will need your help with, and that by the time you've gotten up to speed on things with this other company, you'll be parting ways.
I have to imagine there are some interesting relationships and circumstances that align for such things to happen.
I have to imagine there are some interesting relationships and circumstances that align for such things to happen.
It's bizarre and the article is vague about it, but if I had to speculate:
Tech-first companies always have more software work that can be done; if not, they come up with new work to expand the business (features, scaling, etc)
But maybe this could happen at companies where software just supports the primary business? If the software isn't the product, and it's currently doing everything it needs to do for the business, I could imagine a scenario where IT people might become idle
Tech-first companies always have more software work that can be done; if not, they come up with new work to expand the business (features, scaling, etc)
But maybe this could happen at companies where software just supports the primary business? If the software isn't the product, and it's currently doing everything it needs to do for the business, I could imagine a scenario where IT people might become idle
The market is quite different in different countries. It seems that where the OP is located (Poland?) the job market is dominated by "IT companies" as in large contracting shops, not "IT companies" as tech product companies employing huge numbers of in-house developers.
I've never encountered anything like that, myself, but I have been in sort of a "silo," for most of my career.
The author may be in a contract outsourcing shop.
The author may be in a contract outsourcing shop.
Yeah. This situation is entirely alien to my career, though I've also never worked at a non-tech company (hence the speculation)
I have nothing against being called a resource and treated as such. It's a clear deal for me. I do my stuff and bear as much responsibility for your business and care for it as much as lump of iron.
Any other arrangement seems to me like different flavor of "we are a family" dishonest.
Any other arrangement seems to me like different flavor of "we are a family" dishonest.
>Good software engineers are characterized by determination and persistence, thanks to which they can deliver effective and intuitive solutions to end users. They must have a rich imagination, be up to date with industry trends, read a lot, stretch their knowledge to the limit, challenge the status quo, and go beyond their comfort zone every day.
Now do the other roles around software and you'll quickly realize this is heavy idealism. And sometimes those roles are even paid more.
Now do the other roles around software and you'll quickly realize this is heavy idealism. And sometimes those roles are even paid more.
The only thing I ever had to be "up to date on" was my deadline, the valued knowledge was always product specific.
Idk why all this "shake things up" brogrammer Mr. Robot persona keeps buzzing by my ears, but never in my past 4 jobs have I heard "on the bench".
I haven't worked at the most exciting places, but for every Google there are 10,000 DoD, Health Insurance, Asset tracking legacy-ware firms. They're workin hard, but I wouldn't quite say "challenging the status quo" lol.
Idk why all this "shake things up" brogrammer Mr. Robot persona keeps buzzing by my ears, but never in my past 4 jobs have I heard "on the bench".
I haven't worked at the most exciting places, but for every Google there are 10,000 DoD, Health Insurance, Asset tracking legacy-ware firms. They're workin hard, but I wouldn't quite say "challenging the status quo" lol.
Total fiction. In over two decades I've never seen engineers on the bench or hired out.
maybe in scummy agencies, but not in proper companies.
maybe in scummy agencies, but not in proper companies.
I read this article recently. It fell into my hands by accident and I found this quote there:
-- Assuming that we should launch many pilot projects, let’s consider for which of them it is possible to build minimally viable products – and then try (where possible) to use low-code and no-code tools. With these, we can get less technical people prototyping quickly (of course, more complex integration pieces may still require the help of an engineer). Thanks to the fast implementation, managers or people responsible for the functioning of the process in the company are able (within a few weeks) to check and analyze the sense of an idea. They can test it in a natural environment, and if everything works, they can create a dedicated solution developed by an experienced team. --
One of my close friends, whom I advise in the field of digitization, owns a factory. I can't convince him for anything to try this approach, which I think is absolutely right. The client believes that only their IT department and CTO can change anything in automation. Or only they can be responsible for data analysis. How to change this, how to convince him?
-- Assuming that we should launch many pilot projects, let’s consider for which of them it is possible to build minimally viable products – and then try (where possible) to use low-code and no-code tools. With these, we can get less technical people prototyping quickly (of course, more complex integration pieces may still require the help of an engineer). Thanks to the fast implementation, managers or people responsible for the functioning of the process in the company are able (within a few weeks) to check and analyze the sense of an idea. They can test it in a natural environment, and if everything works, they can create a dedicated solution developed by an experienced team. --
One of my close friends, whom I advise in the field of digitization, owns a factory. I can't convince him for anything to try this approach, which I think is absolutely right. The client believes that only their IT department and CTO can change anything in automation. Or only they can be responsible for data analysis. How to change this, how to convince him?
IT and the CTO have tried very hard to convince them of this because IT and the CTO have seen the hell-sewer that shadow IT creates.
The hell-sewer is real, but banning shadow IT is not the right answer.
---
Above is the answer to your question, but it raises the question - what is the right answer to shadow IT?
The problem with this question is that it sounds like ONE question, when in reality it is a many segmented question. You need a way to characterize the shadow IT in question so that you know what approach you should take.
If shadow IT overlaps with governance, then it should not be shadow IT.
If shadow IT does not, then it's probably fine to stay that way or be replaced at some point by a MVP.
---
That answers the question I raised, but now I've raised another question: WTF does "overlaps with governance" mean???
And this is where the nightmares begin!
The hell-sewer is real, but banning shadow IT is not the right answer.
---
Above is the answer to your question, but it raises the question - what is the right answer to shadow IT?
The problem with this question is that it sounds like ONE question, when in reality it is a many segmented question. You need a way to characterize the shadow IT in question so that you know what approach you should take.
If shadow IT overlaps with governance, then it should not be shadow IT.
If shadow IT does not, then it's probably fine to stay that way or be replaced at some point by a MVP.
---
That answers the question I raised, but now I've raised another question: WTF does "overlaps with governance" mean???
And this is where the nightmares begin!
It's not even that they are supposed to use some solutions without the approval of the IT department. The IT department could, for example, prepare some sandbox for people to play with. They can create separate systems and with their consent and approval people could "play" with ideas. I feel under the skin that there is huge room for innovation.
I don't dispute that at all. This could happen. It should happen.
IT has an allergic reaction to Shadow IT because they know about the times they had to deal with it. Understanding what IT has had to do in the past to fix things helps you understand why they don't think in these terms.
IT has an allergic reaction to Shadow IT because they know about the times they had to deal with it. Understanding what IT has had to do in the past to fix things helps you understand why they don't think in these terms.
Shadow IT happens when the user isn’t getting what they need. I wrote software in excel at one job that did the priority planning for incoming inspection, because we didn’t have anything we could use to do that other than SAP and I wasn’t going to engage with that system due to effort required.
Shadow IT could be seen as ignoring externalities such as security, operational resilience, and process coherence in order to "get things done". Eventually the bill comes due (security incident, key employee exit, incorrect results). Questions are: can you recognize failure? who pays to fix it? what happens while it's being fixed?
I think what you are describing is basically a good development environment.. where you can contribute your insight at depth of skill level appropriate for what you have to offer. From my point of view the path to the eventually persuasive version of this enviornment (i.e. where your friend and the CTO will accept to use it at their factory) starts by setting a common standard for data interchange between the tools. So partial work can be commented on and different options for completing it can be assessed relative to one another. I'm just one person but I am on my way and datalisp.is my starting point ... I am certain that the road goes by your place on the way to prosperity.
Thanks for this vote. Good point with the standardization. I take it.
Maybe changing the expectation that good developers must excel at LeetCode is a place to start fixing the shortage that causes this problem in the first place. I excel at perceiving contexts and understanding when to change approaches, but since you can't test that in a tech screen, it's basically a worthless skill to have.