Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A CTO should be technical

blog.southparkcommons.com

Post reply on HN
Print view View original

301–310 of 367 posts

Re: A CTO should be technical

#301

Post by Alex3917 »

deepGem wrote: post #297
jmull wrote: 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.

> the odds of you being a good programmer are pretty low

You're a good programmer if you've made something good. Most people who are good at leetcode have never made anything significant. When is the last time you saw someone who is well-known for some successful product linking to their leetcode account?

Re: A CTO should be technical

#302

Post by jongjong »

That makes sense. Coding is an excellent way to train problem solving skills.

Even if you consider intellectually demanding fields such as mathematics and physics; although they do train your critical thinking skills, they don't teach you how to be pragmatic. Software engineering can help you to develop a pragmatic 'most efficient path to meet the goal' mindset.

Re: A CTO should be technical

#303

Post by spaetzleesser »

jjav wrote: post #230
spaetzleesser wrote: post #5

Earlier quoted context omitted.

I personally believe it's easier for a technical person to become reasonably competent at process, cost and other management stuff vs a management person to become reasonably competent at technical things. When I was contractor I saw terrible decisions made by CTO and CIO in several companies because they didn't have any technical taste and ran everything by numbers and processes. I definitely believe a CTO should be…

> I saw terrible decisions made by CTO and CIO While a CTO needs to have grown up in the technical trenches to have credibility, a CTO should not be making any technical decisions anymore. If they are, that's a red flag for a CTO who can't let go and keeps micromanaging.

A CTO often will be the referee for making big technical decisions. If that CTO doesn’t have a good bullshit detector then bad decisions will be made.

Re: A CTO should be technical

#304

Post by deepGem »

Alex3917 wrote: post #301
deepGem wrote: post #297

Earlier quoted context omitted.

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.

> the odds of you being a good programmer are pretty low You're a good programmer if you've made something good. Most people who are good at leetcode have never made anything significant. When is the last time you saw someone who is well-known for some successful product linking to their leetcode account?

This is unconventional and in fact real wisdom.

Re: A CTO should be technical

#305

Post by jjice »

viridian wrote: post #284
tinco wrote: 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…

My current job, during the interview, didn't ask me to write a single line of code, but instead asked me to walk through (in great detail) how I'd go about building a GPS related feature for an application that they own. The application is well known and the problem space was well defined. This was a real (low priority) problem that they did eventually plan to tackle as a team. I also at the same time, interviewed wi…

System design problems are much better and more realistic than leetcode style IMO. Let's be real, most developers don't need to have leetcode T9 solutions memorized because it with either never come up, or they can do some research when it does.

Knowing more about an entire system and architecting it requires a lot of variety of experience and it's just a more fun interview for everyone involved.

When I interview people, I also hope I'm assigned to conduct our architecture one because it really makes you learn a lot about an engineer.

Re: A CTO should be technical

#306

Post by qudat »

arnvald wrote: post #249

> 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…

I think this just demonstrates a fundamental flaw with our interview process more than anything else. We are modeling interviews based on companies with insane hiring demands (FAANG). At our little 20 person company we have removed most of the BS leetcode style questions and have shifted towards a more discussion based interview process.

Effectively we have switched from quantitative to qualitative where the questions are similar to start but because of the fluid nature of conversation, drift further from other candidates.

Re: A CTO should be technical

#307

Post by bko »

viridian wrote: post #284
tinco wrote: 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…

My current job, during the interview, didn't ask me to write a single line of code, but instead asked me to walk through (in great detail) how I'd go about building a GPS related feature for an application that they own. The application is well known and the problem space was well defined. This was a real (low priority) problem that they did eventually plan to tackle as a team. I also at the same time, interviewed wi…

Could someone post a good answer (outline) about how you would build out a GPS related feature for an application?

Re: A CTO should be technical

#308

Post by giancarlostoro »

arnvald wrote: post #249

> 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…

You can program beautiful classes but can you actually architect or direct a team? Can you adapt with new information and find actionable solutions to roadblocks for your team and so on? Can you get along with your technical team and command the ship?

I dont care about your skill if nobody gets along with you. You will be the reason top tier talent leaves. A good engineering team is the one where everyone gets along. Everyone has memories of working with toxic people. Imagine if you replaced all those toxic people in former jobs with people you got along with. Would you have left at all? It makes a huge difference.

Re: A CTO should be technical

#309

Post by sudhirj »

The way I think about this that there’s three meta levels in organizations:

The team that builds the product (devs, senior devs, lead devs). Build here usually means code, design, ops.

The team that builds the team that builds the products (engineering managers, principals, staff, directors of X, maybe VP of X). Build here usually means building up people (hiring, firing and training) and making technical decisions with an intent to educate and influence.

Then there’s the team that builds the team that builds that builds the product. These are the CxOs, including CTO. The requisite skill here is engineering the organisation itself, not necessarily a fleet of services or APIs. This skill can benefit greatly from an engineering background (or just playing Factorio), but it’s broad enough that you also need to get into people management, psychology, marketing, selling (internally), consensus building etc. But it not directly related to code.

Re: A CTO should be technical

#310

Post by bluefirebrand »

jon-wood wrote: post #259
hef19898 wrote: post #254

Earlier quoted context omitted.

In defence of "because I say so", it sometimes necessary. And not a big deal in my book, if the person giving the order is also owning all the outcomes, good and bad. Fully agree on everything else. Additional caveat, I have a supply chain and logistics ops background, so a completely different environment to design and development.

"Because I say so" is a terrible way to communicate why a thing is being done. In senior positions it is definitely necessary now and again to pull rank and tell people something is being done despite their protests, but I don't think I've ever found a situation where I couldn't articulate why that decision had been made. People may disagree with that decision, hell, sometimes I've disagreed with the decision I'm com…

I had a situation recently where I had a report argue with me constantly over team agreement stuff like code standards and unit test coverage.

I explained every piece of rationale I could come up with for why the team chose to do things the way they did. I offered to schedule team discussions for her to try and convince the team to adopt other strategies, with the understanding that if the team didn't want to do things her way that would be the end of the discussion.

It wasn't the end of the discussion for her though, she kept complaining. Eventually I just had to say "that's the way we do things here so you have to get on board". It's awfully close to "because I said so", and I hated saying it, but I exhausted every other avenue I could think of.

She wound up giving her notice, so I guess we were on the same page because I was working with my manager on letting her go. But if she had been able to keep her head down and do the work we would have kept her for sure. She was a good coder, good systems knowledge, just really didn't like writing unit tests I guess.

Post reply on HN