Live data from Hacker News

A CTO should be technical

blog.southparkcommons.com

341–350 of 367 posts

Re: A CTO should be technical

#341
Of the top-tier best CTOs and Product Visionaries I've worked with, exactly NONE of them are competent coders. They know enough about coding to discuss implementation architecture, but actually writing code is not something they do, nor should they, since that requires keeping up with a zillion fiddly things they left behind to be able to see and properly guide the "big picture" product vision.

Someone who ties themselves to that level of detail thinking and keeps their expertise current (nearly a full time job in itself, these days!) can never develop truly great chops at product vision/conception, design, and the ability to build and inspire those teams to think in a way that leads to "insanely great" products. They are very different skillsets - there's a difference between a coder and a developer, and a developer and a product visionary and tech team inspirer.

BTW, as a 6-12 time (depending on how you count) CTO myself (including two venture backed with acquisition exits), coding interviews are a complete WOMBAT: Waste Of Money, Brains, And Time. I care about HOW you think about the problem and its relationship to the real world, since THAT is what makes simple, fast, "just works" software that people love to use.

Re: A CTO should be technical

#343

Earlier quoted context omitted.

I wasn't trying to write a business book but what you wrote is fine usually for the senior level employees that get how business works and probably took the job with the understanding of the weight of their position. However you will also have fickle entry/low/mid level employees that don't have the maturity to accept the realities of the business world.

> However you will also have fickle entry/low/mid level employees You need to read that sentence again. Your comments are very revealing about you and not about CTO level work as you are imagining.

My comments are very revealing about the reality of the work world at mediocre aka most companies.

If you get a big enough group of people there are going to be some people with machiavellian tendencies or at least some that read bad advice on the internet about how to get ahead at work and try to apply it with clumsy gusto. You will look like a real fool to your boss the CEO if you are giving information to these type of people and they try to use it for their benefit.

I may be painting too dark a picture due to the focus the comments have on a single sentence. Overall I had good relationships with the vast majority of people that worked for me. I know this because I still have contact with most of them even though we have almost no chance of ever working together again. You are deluding yourself if you think there are no bad apples out there or that people having problems in their personal life may try to pull manipulation at work to get ahead or however they see may solve their problems.

Re: A CTO should be technical

#344
post #252

> So let me put it plainly: the CTO/VPE/Engineering Director candidate should pass your coding interview. In fact, they should excel. People who work full-time as developers spend hundreds of hours practicing leetcode and hackerrank so that they can pass the interview, but a CTO who's 5 levels above and hasn't logged to Github for 3 years should excel at it? Come on. I agree with the premise of the article, CTO shoul…

Developers spend hundreds of hours practicing leetcode and hackerrank? Are they actually good coders? And that's required to pass an interview? I feel so out of touch. I haven't interviewed very many candidates, just a couple dozen maybe, but I've never heard anyone mentioning leetcode or hackerrank. If they'd admitted they'd admitted they spent that much time on there, I'd be seriously questioning why they didn't sp…

I also hate leetcode as a measure of "coding competence." I don't think they're "worthless" but totally depends on your job. I notice that if I'm rusty at leetcode, it takes about a week to get ramp back up... but we're talking 10x better.

I don't at all believe I magically got 10x better at coding though... just 10x better at recognizing and remembering patterns.

I think the best type of interview for everyone is the "walk me through X" type. You can almost always spot BS in those and if you can't... should you even be interviewing? I would 100% rather have someone that knows how to glue pieces together vs someone that is good at leetcode... don't get me wrong, I'm amazed at how awesome people are at it and I've met people who excel at both... but I feel its just too weighted in interviews.

Re: A CTO should be technical

#345
post #244

Earlier quoted context omitted.

Compulsive liars cannot change their habits.

And gasp you may have to reward your worker because they truly are that valuable instead of reaping all the benefit for the cto.

Thats mostly a CEO trait. Remember CTO,CFO,COO,CIO, ect are all just jobs. You ultimately report to the CEO, whom ultimately reports to the investors,stakeholders, capital partners, b2b relationships and so on.

For the record I gave 100% of bonuses I had awarded to my staff and 0% to myself the entire tenure.

Re: A CTO should be technical

#346
post #252

Earlier quoted context omitted.

Developers spend hundreds of hours practicing leetcode and hackerrank? Are they actually good coders? And that's required to pass an interview? I feel so out of touch. I haven't interviewed very many candidates, just a couple dozen maybe, but I've never heard anyone mentioning leetcode or hackerrank. If they'd admitted they'd admitted they spent that much time on there, I'd be seriously questioning why they didn't sp…

Larger and more well-known companies do leet-code style programming challenges. I recently interviewed for a job in a ride hailing app company and they directly recommended practicing leetcode problems, even sent me examples of leetcode problems to practice solving. My sample is not big (it's 2 companies I iterviewed with recently), but it definitely feels like the industry is converging on this practice of testing l…

Over a decade of experience shouldn't have to prove competence via leetcode, honestly. I fully believe it helps you become a better programmer... but its over-hyped. Shouldn't expect interviewing/preparing to interview to be a part-time job. Too busy in the day to day for that...

Re: A CTO should be technical

#347
post #335

Earlier quoted context omitted.

Apparently in every single case they played at least one instrument at a world-class level, and in at least one case they were said to play "most of the instruments that comprise an orchestra", though presumably not at a world-class level. Hanging out with musicians leads me to believe that probably nearly all these conductors could play most of the instruments in the orchestra at a basic level, because it's totally…

That does make me think now is it an actual pre-requisite to be a conductor at a high level or just the way things have been. We seem not have much/any counter examples?

It's hard to know, but surely some rich or politically powerful music fans have attempted founding an orchestra with themselves as the conductor. None of them seem to have become famous — but that could "just" be a matter of the musicians' prejudices.

Re: A CTO should be technical

#348
post #245
post #34

Is this what passes for management advice these days? > CTOs have to be very clear with everyone that if quality falls below a certain point then everything will be paused to focus on improving quality. This strikes me as almost Dilbertian. I think quality is hugely important, but I think don't think you can get it with dramatastic managerial showboating. I think it's something that you bake in with all sorts of prac…

I never worked at Dropbox, where Aditya was CTO, but companies like Databricks, Lyft, and Plaid all have code freezes for various quality-related reasons e.g. outages, post-mortems, severe bugs. Are all of these company's CTOs dramatastic showboaters, or is this a lever worth pulling when times call for it? These companies were all unicorns, decacorns at times as well.

I can't say for sure about those particular cases. I'd have to have a lot more detail. But as I mention elsewhere, one of the best ways to rise through the ranks, especially at companies excited to be unicorns, is to do dramatic things, even if they aren't particularly effective.

~20 years ago, when eBay was a company that mattered a great deal, I did a contract there. I was on some mailing list for the eng org where promotions were announced. Every single one of them talked about some incredible act of heroism, usually involving staying all night multiple times to get something out.

The reality was that their code base was pretty poor, and their bad development practices caused things to get worse over time. That required heroics just to do pretty mundane stuff. And in that rush to meet arbitrary deadlines with sufficient drama? Even more corners would be cut, making it even harder something to get done next time.

In contrast, they could have taken quality and productivity seriously and build their practices around that, ending up with a smooth-running process and reasonable hours for everybody. But that was in nobody's interest, because as far as I could tell nobody at eBay got promoted for quiet competence. Drama was what mattered, and so their development practices were tuned for creating opportunities for drama.

Re: A CTO should be technical

#349
post #245

Earlier quoted context omitted.

I never worked at Dropbox, where Aditya was CTO, but companies like Databricks, Lyft, and Plaid all have code freezes for various quality-related reasons e.g. outages, post-mortems, severe bugs. Are all of these company's CTOs dramatastic showboaters, or is this a lever worth pulling when times call for it? These companies were all unicorns, decacorns at times as well.

I've worked at decacorns that used code freezes... Usually they were last minute "oh fuck we took down the whole website 3 days in a row now and this has cost millions of dollars" kinda reactions. The reason they had to do code freezes is because all the other practices were such dog shit. (Mostly from a product and biz perspective) Eng was usually driven with a whip to meet insane deadlines - thus the instability an…

Indeed! Honestly, I'd expect a moderate inverse correlation between valuation and code/practice quality.

I suspect that's obviously true for large, successful companies. We've all heard stories about people at stable companies with terrible dev practices, because ultimately dev practices don't matter for companies with sufficiently strong market positions. Are some of them good even though they don't have to be? Sure. But plenty aren't.

But I'd also think it's true for the whatevercorns. For raising that kind of money, big public drama is vital. Look at WeWork or Theranos. Great at dramatics, great at raising money. Technical competence for them was at best irrelevant to getting the next valuation bump. If the execs favor dramatic announcements over slow-and-steady gains, I expect that will influence how promotions happen and gradually trickle down to dev practices in a lot of places.

Re: A CTO should be technical

#350
post #293

Earlier quoted context omitted.

Wouldn't any half-decent CTO put a stop to using leetcode exercises for interviewing job candidates?

If you can't code LC medium, then the odds of you being a good programmer are pretty low. That's the conventional wisdom. Everyone is playing safe and adhering to conventional wisdom.

> Everyone is playing safe and adhering to conventional wisdom.

That's not playing is safe, though, that's playing it wrong.

If the cost of interviewing candidates were zero and the was an infinite supply of actually good programmers, then it would be fine to err on the side of many false negatives for the sake of avoiding false positives, especially since the cost of false positives is high.

But that's not true. You pay a price for every interview, and pay a further price for every day without the qualified help you need. And you're probably in a competitive market -- a relatively small delta between you and your competitors' hiring efficiency might mean they get almost all the good candidates while you get almost none.

Anyway, like I said, any half-decent CTO should be able to fix such an obvious mistake. Hiring is a high-stakes move and it pays to be picky, but it really doesn't pay to be dumb about it.

Just based on my personal experience, I doubt very many people beyond junior or entry-level are going to study leetcode exercises, so you're walking away from almost everyone useful past that level.

Maybe you could give people a choice of problems only good programmers could solve, but of different types, and let them choose the one they want. Leetcode, sure. Or: here's a windows system and windbg, tell me what's wrong. You've doubled your chances. Spend some effort to come up with five or six or seven different ones and you might have something.

Post reply on HN