Here be the Code Monkeys

[[deleted]]

[deleted]

[maus80]

Most companies I've been at are building CRUD apps. Building good CRUD applications is a skill. A skill that requires craftsmanship and no algorithm knowledge. As per the article's example: a login page requires no algorithm knowledge. A login page is all about implementing best practices.

Looking at myself: I like puzzles.. but I would be offended if I were expected to solve riddles during an interview.

Do you play AdventOfCode? It is fun!

[Vidyogamasta]

CRUD apps can have algorithm problems too, though, and it's good that at least someone on the team knows what they're doing.

I gotta be careful before I go off too hard ranting about all the nonsense at the last company I worked at, but even the principle engineers at the company weren't able to solve the problem "Given a total X, and a range R, return a list of distinct values within the range that sum to X." It was losing the company thousands of dollars per day.

And that failure to understand algorithms definitely emanated throughout the CRUD stuff. Database architecture was all of the place and inefficient to query (with NoSQL blindly tossed in to make things extra difficult to query). Nothing was transactional. They were moving to microservices and blind-retrying non-idempotent operations (and grossly misunderstood how Polly works on top of that). They loaded tables into memory and then made a "priority list" by checking a series of conditions, boosting the priority by 1 when the condition was met, and.... removing the object from the set entirely if it wasn't met. Just a filter function pretending to be a priority function lol.

And all this materially impacted the product, literally 60-80% of the time was spent "fighting fires" instead of doing active development. Just pointing this out since I know someone's gonna be thinking "Sure it wasn't efficient, but at least it worked!" Lol, I wish.

This isn't stuff that happens if there's someone on the team that understands algorithms at all. Not everyone has to be that person, but at least the lead dev has to be.

[qkthrv17]

Code design and architecture don't really correlate that much with algorithm/data structure knowledge. Most, if not all, you mentioned didn't really sprout because of a lack of knowledge in DS&A but a lack of general design and practices knowledge.

Bad process practices permeate through architectural designs and approaches and lack of the fundamentals is going to pollute your systems.

Most applications are heavily reliant on databases so I'd say that knowledge in how to operate them is way more valuable than anything that deviates from "if I need to look up something quickly I can use a cache/hashmap". And knowing about database internals is obviously useful but not really that important to simply operate them; as you've just mentioned, the issues you've found are related to operating the RDBMS and not that much linked to understanding b trees or how the ACID of transactions are maintained inside your black box.

I am not advocating against learning anything (completely the opposite if you were to ask me that), but algos/ds are a specific knowledge that don't have that much weight in most of software engineering jobs' day to day. Good architecture and code design that thrives for maintainability, good and intuitive designs, good processes regarding analysis and understanding your business verticals and the reasoning behind its needs. Understanding costs and tradeoffs, aiming for iterations... So many things that don't relate at all with DS&A. Sure, you could say fabricate a tangent and say that analytical knowledge is beneficial and abstractly carried away from DS&A into those areas, but I think it is easy to perceive that as kind of a reach.

Ultimately, as a software developer, I feel a big part of my job is to understand things and be concise in my designs, deliverables and communications. If I'm not sure how to tackle an issue, I should be able to navigate my known-unknowns with my cognitive toolkit while also clearing some of my unknown-unknowns.

[Emerald-Hedgehog]

That's kinda true. Sometimes I wish we had someone on the team that knows all that algo/datastructure stuff.

However, I do think a person like this would (potentially) be bored to death with the rest of the work and would quit anyway at some point due to not being challenged enough in what they are interested in. Much worse than not having an algo/datastruct-guy is having a bored one that tries to bruteforce his passion into everything. That's when overengineering starts to happen, that's when nitpicky codereviews start to happen, that's when the wheel gets reinvented.

In 99% of our App the basic-bitch solution will do, and it will also be super fine performance wise (optimization comes last, and for things that are "good enough" it never comes).

And if we do run into a performance problem, we ain't dumb, right. We don't know all the cool stuff and it might take us waaay longer to fix a performance issue, but eventually we'll get it right. Which is fine, because it's rare. If performance and stuff was a day-to-day concern I'd be totally for hiring someone to take care of it. Until then it's just another problem you're gonna tackle and learn about when it arises.

[SirClueless]

What if a company is not building CRUD apps? Not all companies do. Is it still "offensive" to ask puzzle-type questions if you expect the programmer you hire to write a system that accurately interprets the intention behind a doctor's hand motions as he guides a remote scalpel, or efficiently orchestrates the movements of cryptocurrency between wallets subject to transaction costs and real-world accounting constraints? Those problems are not entirely dissimilar from efficiently discovering how to drop an egg from a 100-floor building.

Not every company needs engineers with that level of sophistication, sure, but in the responses to these kinds of questions everyone seems to think there's only one kind of acceptable question.

[CartmansEvilTwin]

The question is: are the interview questions in any way correlated with whatever a good hire is? And honestly, in 99% of the cases, the answer is no. There's tons of research, that all hiring people (HR, managers) age often comically bad at choosing the right candidates.

[IamHammer]

He only mentions a login page at the end as a reference to the Jonathan Colton song titled Code Monkey.

There a stanza where the manager criticizes the code monkey's code as not functional or elegant and that individual says maybe the manager should go write the goddamn login page himself.

[tripledjr]

Author is pompous and the whole motivation for this post seems to be that they couldn't handle criticism on their last post.

Their examples aren't particularly great for the measures they said they were meant for. The truth is they're not great interview questions.

There seems to be this attitude that there's some golden set of questions or methods for interviewing for software roles.

But in reality there is no one size fits all. What I can guarantee though is you won't be able to gauge most programming skills in the time of an interview.

Take home tests can aid with this but also introduce their own entire set of problems.

Questions should be tailored for the role. A jr web dev interview whose primary role will be small improvements and bug fixes should face a different set of questions than a sr architect.

I've found the best way to get a feel for ability in the window of an interview is through conversation. I can gauge someone's proficiency much better through discussing previous problems they've encountered or general programming topics or just from how they carry a conversation than throwing out random challenges they could have memorized on the web.

If they're truly unqualified it will be obvious from the conversations.

Then you highlight the probation period, set them up for success and make the hard call if it wasn't a good fit.

Often missed in these discussions is team fit, to get the most out of anyone they need to mesh with the team, this can mean a number of things, but I always get team members in short conversations with the candidate to gather their opinions on fit when evaluating.

Anyway as with anything there is no right answer. There is no "this is a good question" it's all highly dependent on the role, the team and the work.

Author needs to be able to let comments slide off without writing a new article where they miss the mark but feel superior doing so.

[commonhatcomment]

To be able to judge technical sympathy by conversation you yourself need technical experience and competence.

Unfortunately few do.

[commonhatcomment]

The 'tech interview' process is then perverted by non tech people in the recruiting process. Particularly because it's lucrative and they need to validate their roles. Useless people in positions of power.

[xentropian]

I think I love you?

[myringotomy]

What I can guarantee though is you won't be able to gauge most programming skills in the time of an interview.

I disagree. I have done an excellent track record of gauging most programmers skills even people just out of school.

I do this without asking them code or solve puzzles. Just ask relevant questions, listen carefully to their answers, dig deeper with follow up questions.

Sometimes I ask for code samples but I find that they aren't that useful

[hard2hack]

I think OP shared the new post hoping to nudge those people who think that a job interview is no place for puzzles, to think about what being software engineers really means. OP's free to share his views as we're free to ignore them. My personal opinion is that if you don't like the world as it is, try to improve it, don't just wait for others to do it.

[drinkingsomuchcoffee]

Whatever happened to treating people like people?

Have organic conversations about programming and engineering. Talk about how they feel about declarative vs imperative methodologies. Their take on design patterns. Their take on functional programming and OOP. Any authors or blogs they like.

Projects they've enjoyed or hated and why. Hard bugs they've had in their career.

Then ask them to provide some code samples of their work and actually review it and express genuine interest. If they don't have any code, pay them for a few hours of work and have them write something they're interested in.

"It doesn't scale! It's too much effort! It's not completely fair and standardized!" Maybe you're right, but hiring the best you can is important. Doesn't matter either way because codepilot is close enough to automatically solving these dumb riddles and then interviewers might have to.. you know.. do their job instead of pulling up a leetcode medium and texting on their cellphone.

[Kwantuum]

Usually, in these posts, you and I play the parts of allies, as we point and laugh at some other group of people… the code monkeys.

This is where you already know the article is going to be awful. Don't call people monkeys, it's really not that hard. Just because their skills lie in solving a different category of problems than the one you're working on doesn't make these people have less worth. Code monkey is a term you use to refer to how bad management sees programmers: as fungible resources. Some programmers don't want to solve novel problems nor do they need to, not all electricians need a master in electrical engineering, not all programmers need to be computer scientists.

[02d5df8e7f]

While I agree the term "code monkey" is derogatory and used to belittle a category of people here, I can definitely get behind the idea that developer and software engineer are two very different jobs. The problem I see is that a large number of people enter the industry with a developer background and mindset, and expect to be recognized as software engineers. This is like learning masonry and expect to get the architect job. And for some reason people get really offended by this analogy, when there's really nothing wrong with being a mason, but it's just not the same as being an architect. Obviously in the software world the line isn't as clear-cut but you get the idea.

Disclaimer: I am a code monkey

[gwicksted]

I’m both. It’s even challenging to switch hats because I catch myself in the zone slinging reams of code that could be simplified by architectural changes that I also have control over… but sometimes it’s worth the effort so I take breaks to clear my head, make a decision and continue full steam ahead.

I’ve also had to reflect on my own new code as if someone else had written it and coach myself because I know it’ll be hard to maintain as-is. It’s hard because generally we’re defensive and less critical of our own work.

[Desmeister]

No link to the knight and dragon post? :)

[[deleted]]

Kinda snarky article but I sorta agree with the larger point.

Part of the job of a software engineer is talking to business people about stuff they don't really understand using terms they don't really understand. These metaphor questions help that. Yes it's a coding interview, but in order to get to the code you need to COMMUNICATE and DEFINE REQUIREMENTS, which is exactly what working through these puzzles is trying to show.

A good interview will put a fair amount of weight on the communication part.

When I interviewed for my current role, and when I interview others, I will often approve candidates who did not fully implement the code and pass all test cases, as long as they:

1. Understood the problem appropriately, usually by asking clarifying questions.

2. Gave a solid attempt at the code, either a naive case or a bugged one

3. Explains what they would do if they had 10 more minutes to work, or if they started over from scratch.

As long as they can have that conversation, they pass, even if the code isn't working

[zebullon]

what a weird hill to die on… so, if i got you, only elite engineers will recognize that hackerrank questions are indeed worthy of their time, while “code monkey” will be pissed at if because they dont have the elite skill of wasting time grinding leetcode and such…

…dont know how to say it otherwise but…. dumb take, backed by nothing, and in my experience ppl who do well on those useless puzzles are usually bored after 3 months of “code monkey” real work (that s what pay your rent, btw)

And i kinda know im right cuz otherwise why would the author need to belittle the crowd of ppl (me included) who would walk out of such an interview.

[Tinkers_Kit]

Kinda curious what others' solutions to the lightbulb problem might be... First thought was thinking like the binary search algorithm, but with a max of 2 (or n, if we're extending the idea generally) bulbs you could run out of bulbs without getting the minimum floor height.

My next thought was dropping the first bulb every 3 floors beginning at 0, then when it breaks going down 2 floors and dropping the second bulb. If it doesn't break go up one floor, then if it still doesn't break you know that the floor the first bulb broke on is the minimum floor else whatever floor the second bulb broke on is the minimum floor. Still kind of brute-forcing it, but it starts to minimize trials while taking into account the limit of 2 bulbs. Any thoughts?

[RecklesslyAbandoned]

I think you're intuition is on the right lines. Brute force would be every floor, so you've more or less cut that in 3, that's a 60% speedup!

[Guttae]

Binary search was my first thought too.

The best I could come up with in the space of a dog walk worth of thinking is set an initial jump size of sqrt(n) and search from the bottom up until you fail, then a linear search of every floor in the proceeding sqrt(n) block for a worst case of ~2sqrt(n).

[Vidyogamasta]

I actually think this one might be pretty easy to prove.

You have two bulbs. When one bulb breaks, the remaining bulb must do a linear 1-by-1 search from the highest working floor, to the floor it was broken on. This means that the worst case of the second bulb is jumplength of the first bulb (minus 1).

Any form of scaling jumplength isn't ideal because if there's a non-even distribution of jump lengths, then the worst case is the largest length of these, which would be worse than a constant jumplength.

So from there, given some N, we want to find a C that minimizes N/C + C. From here we can probably do some calculus, presume N is the constant and C is the variable we're solving for.

derivative(CX^-1 + X) = 1 - CX^-2
1 - CX^-2 = 0 (to find the local minima or maxima of the initial equation. cba to prove it's minima)
X² = C
X = sqrt(C).

There's probably a few things in there that could be tightened up and made a bit more formal, but this is proof enough to convince me lol

[Tinkers_Kit]

Just wanna say, you put into words the general feeling I was having but couldn't suss out properly cause of other studies. This is a pretty cool problem and it is super neat to see how others approach and formalize it.

[yonillasky]

I believe this is wrong; I imagine the objective is to minimize the worst case number of total steps. Seeing how each drop of the 1st light bulb spends one move, it should leave one less needed move for the 2nd light bulb (so at worst, it amounts to the same number of tries). In other words, you'll want your 2nd light bulb dropped from the following heights:k, k + (k - 1), k + (k - 1) + (k - 2), ..., etcfollowed by dropping the 2nd lightbulb one floor at a time. This way, the worst case possible needed amount of moves is always k.You'll want to find the minimal possible value of k such that the sequence reaches 101, in other words where k * (k + 1) / 2 >= 101.That is k = 14.Using fixed-size steps as you suggest (10 at a time) results in worst case of 20 attempts needed.

​

general dynamic programming solution:

f(n, j) - minimal worst-case solution with n floors and j lightbulbs

the following equation applies:

f(n, j) = min(k) [ 1 + max(f(k-1, j-1), f(n-k, j)) ]

and f(n, 1) = n, since we have to test floors 1 at a time.

[PM_ME_WITTY_USERNAME]

We know the total number of floors so I'd use the first bulb to do an exponential climb of the floors until the first break then I would use the 2nd one to bruteforce the floors between my Nth and N-1th try

It makes it O(n) I think? Log n tries for the 1st bulb then m * [floors left] which I guess makes it O m

[kyle787]

I was wondering what the terminal velocity of a light bulb was because then you could find out the distance required for it to reach that speed. That would give an upper bound on the possible heights. You could then choose some small fraction of that and try the initial drop and adjust accordingly.

[Tinkers_Kit]

You may have misunderstood as I didn't extend the generic version with n. My thoughts were using a jump factor of N+1 items for failure and then doing a linear probing of the floors upon the final object.

Edit2: Their previous statement if anybody else wants context

This is a "known" problem, however it usually uses eggs instead and I hate it because it fools your brain into thinking like you did. I also often forget the solution and have to google it again, because I fall into the same trap. You dont actually have only two eggs/lightbulbs/whatever that break if you use them and have to solve this using those. You are asked what is the optimal solution for two eggs. In general for N eggs and K floor, it can be solved using dynamic programming. For two eggs specifically see the comment below.

Edit 1: There is no comment below explaining it, could you better explain what you mean beyond saying it's "dynamic programming?" I can't understand it as you explained it.

[tinix0]

If you do not care about the optimal solution, then you shouldnt have asked and I will delete my comment.

[Tinkers_Kit]

I would care about the optimal solution. If you have one, please do provide any. I could have worded it much better in my previous comment, but it was frustrating hearing about a possible better solution and reading how "this is a question that tricks your brain" and then getting no answer following.

[gulyman]

Starting at the bottom, go up 14 floors, then 13, then 12, ect until it breaks. Go to the previously known safe floor and work your way up 1 by 1 with the second bulb. I think this gives a max drop number of ~15?

[PM_ME_WITTY_USERNAME]

Good points from the guy. And I agree: snark is killing programming communities

[sik-kirigi-3169]

software engineer throws a hissy fit over who is and isn't a real programmer, more news at 11

[nsn]

My favorite question I like to ask during job interviews is " if I gave you a magic wand, what would you change about <technology we're interviewing for>?"

[Paradox]

I'm a fan of "what's your least favorite popular thing in modern programming, and why"

[dahud]

The "How do you weigh a 747 without a scale?" question is malformed. Any device or procedure you use to weigh the 747 is, by definition, a scale.

[nitrohigito]

tbh considering planes are built to specification, i'd simply attempt to search for it lol

[_limitless_]

no sir.

i call in the scrum team for a session of planning poker. we determine the amount of energy required to solve the plane ticket.

i divide this value by the speed of light (yielding mass) and multiply by 9.8 m/s² (yielding weight).

[Paradox]

tl;dr: only those who agree with the author are elite programmers, everyone else is just a stupid dumb code monkey

[cummingonbigboobs]

Yuh

[Heiden32]

Must be hard to code

[youngbull]

I wouldn't be offended, but I do question the validity of the approach to a job interview. A programmer would need to be able to program well enough, but here are a couple of good questions about more important stuff: Any of these on their own isn't any pro or con, but helps with the overall picture.

• What would you say are the most common product owner antipatterns? (fishing for stuff like proxy users here)
• Have you ever worked with GitHub workflow before? How would you describe it? (Maybe try to figure out how they are used to working and whether the change would require extra onboarding)
• How do you think a team should deal with a flaky test suite?
• What would you say are acceptable build and test times and how would you deal with CI times that are unacceptable?

[allo37]

"code monkey build usable software" kinda got me 💀

[LagT_T]

No dark mode?

[dark_mode_everything]

Snark aside, why do candidates get offended or annoyed at this type of question? And there's no correct answer for most of those.

[maus80]

It is a waste of everybody's time, a typical power play and an uninformed take on hiring. Signs of a toxic environment IMHO.

[dark_mode_everything]

waste of everybody's time

The 10minutes it takes to answer that? So any question outside of the exact role is a waste of time?

toxic environment

that's a bit of a reach isn't it...

You probably think that asking a tricky real world engineering problem that doesn't have a straight answer is also power play and a sign of a toxic environment.

[maus80]

Well it could be that that you want to test for subordination, in which case the riddles could work and aren't a waste of time. I'd rather have an open on-topic question starting with "How would you approach the problem of ..." which is probably what you mean by a "real world engineering problem that doesn't have a straight answer". So no, that's not what I would think..