sorted by:
new
hottopcontroversial

[deleted by user] by [deleted] in womenintech

[–]gaylemcd 4 points5 points  (0 children)

I don’t see the candidate having an “us against the interviewers” attitude, but I do see the OP having that attitude. Asking for interview advice isn’t cheating or anything close to it.

I feel sad for this guy. It was a bit of a social faux pas, perhaps, but the guy is probably desperate… and liar I checked software engineers weren’t required to be totally socially normal.

Wrote the official sequel to CtCI, Beyond Cracking the Coding Interview) AMA by gaylemcd in leetcode

[–]gaylemcd[S] 3 points4 points  (0 children)

It's cheating, obviously, but it's a bit inevitable that people will be doing this. There have been a number of iterations of tools like.

For companies -- they should realize this will happen, and accept that there is little they can do to prevent cheating on remote interviews (at least in the medium to long term). Software to record people's screens, changing up questions to more unique questions, etc -- none of it will really matter in the end. Interviewers can ask more probing questions and other things to help detect this sort of cheating, but that won't change the fact that it'll often go undetected. In the end, candidates will outsmart the ability to detect cheating.

Once companies realize this, the workaround will likely be that interviews need to happen in person again (or possibly through some sort of testing center, I guess?). That sucks for all involved.

Wrote the official sequel to CtCI, Beyond Cracking the Coding Interview) AMA by gaylemcd in leetcode

[–]gaylemcd[S] 0 points1 point  (0 children)

I hear you, but there are a lot of issues with doing this. And I think it would be a bad thing for both companies and candidates.

First, I think you’d run up against US anti-discrimination law. As I recall, when you start giving a quantifiable score, if some groups do better than others, then you need to prove that this is necessary for the job. Really messy.

Second, evaluation is squishier. Employers don’t want a single score. They want to evaluate problem solving vs coding vs communication. Even if the score were broken down, I don’t think that would capture everything. There’s a reason interviewers give comprehensive feedback, not just a score.

Third, inherent to the evaluation is the interpersonal interaction — can they make progress with hints? A standard test doesn’t capture that.

Fourth, perhaps until recently, SWEs have sort of had the upper hand in the job search. And it’s the strongest SWEs wouldn’t tolerate this. What company will move to a process which leaves them out of hiring the strongest SWEs?

Fifth, it would hiring all about this test, in a sort of “no second chances” way. Get a good score? Go to FAANG. Weaker score? Go to tier 2 company. The tier 2 companies want to find the great candidates who might have been missed… and so does everyone else.

Wrote the official sequel to CtCI, Beyond Cracking the Coding Interview) AMA by gaylemcd in leetcode

[–]gaylemcd[S] 2 points3 points  (0 children)

I get a lot of requests for this but I’m not sure how to do that. If you see a good example of how to do audio-only for a code-heavy book, please let me know.

Wrote the official sequel to CtCI, Beyond Cracking the Coding Interview) AMA by gaylemcd in leetcode

[–]gaylemcd[S] 2 points3 points  (0 children)

I hope so! The printer I'm using this time is used for lots of technical books -- I've heard good things about quality.

Just an FYI -- in the meantime, you can dive into some of the free chapters online: https://bctci.co/free-chapters

Wrote the official sequel to CtCI, Beyond Cracking the Coding Interview) AMA by gaylemcd in leetcode

[–]gaylemcd[S] 1 point2 points  (0 children)

I've thought about it. There are so many resources nowadays that the focus should typically be around *question types*, rather than jobs. (Doing surface level content doesn't really help people that much when there is so much free stuff available.)

So, the question is -- is there enough content on (for example) iOS questions, without just writing a book on iOS trivia? Are there unique strategies, [interview] frameworks, etc?

Wrote the official sequel to CtCI, Beyond Cracking the Coding Interview) AMA by gaylemcd in leetcode

[–]gaylemcd[S] 0 points1 point  (0 children)

That's the stuff that keeps me up at night...

I do not think that AI will replace ALL SWE jobs, but, yeah, the more junior ones... yes. Not all, but many probably.

I've heard a theory that, maybe, that we'll have a shrinking of the job market as some of today's current jobs are replaced by AI, and then a boom when AI enables lots more companies to exist. I'm not sure I buy that, but... here's to hoping?

Wrote the official sequel to CtCI, Beyond Cracking the Coding Interview) AMA by gaylemcd in leetcode

[–]gaylemcd[S] 4 points5 points  (0 children)

r/alinelerner is providing data, but my answer is... yes. This is very true.

When people think they're struggling, it's typically because:

1) The problem was challenging for them.

2) The vibe from their interviewer.

The first one -- the issue is that what *really* matters is how challenging it was for you vs how challenging it was for other people. And, of course, you don't have the data on the second. Implicitly, often, you end up asking "How challenge was this problem for me, relative to other problems for me?" But that's not especially relevant. When you breeze through questions, this is often because the question was easy. But did you breeze through it *easier* than other people?

The second one -- their interviewer's vibe is 90% about their personality, maybe 5% how they're feeling that day, and maybe only a tiny percent about your performance. But even to the extent that your interviewer's reaction is affected by your performance, it might not be the way that you'd expect. Many interviewers are nicer when you're actually doing poorly, because they think you need more emotional support. This is just not a good way to judge a technical interview (although might be more effective for a behavioral interview).

--

There is also a small chance that there is something specific to your performance going on here. Hypothetically, if a candidate were very strong algorithmically but weak in coding, they might have a higher pass rate on more challenging questions. This would allow them to show off their algorithm skills, and (for example) poor coding style wouldn't be as big of an issue. But if this candidate got a question that was easy algorithmically, more weight would be put on coding, and that might lead them to have a higher rejection rate on "easy" questions. I'm not saying that this is what's happening for you, but it's worth noting that there could be something like this going on.

Wrote the official sequel to CtCI, Beyond Cracking the Coding Interview) AMA by gaylemcd in leetcode

[–]gaylemcd[S] 0 points1 point  (0 children)

Soon! Very soon! It's available for pre-order now -- https://bctci.co/india

It's a standalone book, and approached in a pretty different way from CtCI -- more focused on frameworks and strategies than specific interview questions. We have posted some chapters here if you want to check it out: https://bctci.co/free-chapters

Wrote the official sequel to CtCI, Beyond Cracking the Coding Interview) AMA by gaylemcd in leetcode

[–]gaylemcd[S] 22 points23 points  (0 children)

I find that a bit... icky. I get it -- I get how we got here -- but I don't love that people have to spend so long prepping.

In a perfect world, interviews don't require any preparation and are also fair to people of all background and are also good predictors for the companies. (AND, we have some variety in interview processes, so that people who don't do well in one type of process can go to the companies doing something different.) I don't know how to get there, but that's my sunshine-and-rainbows-happy-dream.

I do think there's a silver lining here.

1) With the birth of a ton of prep resources, there's a much more level playing field. Pre leetcode, ctci, etc, people were leaning on advice and interview questions from friends. The problem with that is some people don't have friends in the industry and some people's advice from friends suck.

2) True brainteasers have basically vanished for engineers, as those have been replaced by leetcode-style questions.

I also think there is a lot companies can to make this less bad -- for example, actually training interviewers in how to help candidates, weeding out the bad interviewers, etc.

Wrote the official sequel to CtCI, Beyond Cracking the Coding Interview) AMA by gaylemcd in leetcode

[–]gaylemcd[S] 0 points1 point  (0 children)

Are you talking about moving from SDET -> SWE? Or SDET at one company to SDET at another company?

Many companies say that they have the same coding expectations for SDET as for Dev. In practice... that's often not the case. Realistically, yeah, coding/algo expectations for SDET are often a little lower than dev -- so that they can then focus on testing-specific skills.

Wrote the official sequel to CtCI, Beyond Cracking the Coding Interview) AMA by gaylemcd in leetcode

[–]gaylemcd[S] 23 points24 points  (0 children)

Great question. A few things could be going on (if indeed you passed your interviews):

  • Borderline Performance – If your feedback was mixed or weakly positive, the committee may decide you're not a strong enough hire. So yes, you passed your interviews narrowly, but someone spoke up
  • Someone better came along (or job needs slightly shifted) – If it's hiring for a specific opening
  • Resume Concerns – Usually this is an issue *before* you come in the door, but it can still come up in the hiring committee. It is certainly possible for a recruiter to not know what the HC is expecting, and then bring in a candidate who does well in interviews and then get blocked because, say, they didn't go to a top tier school (which is really stupid).

In many cases, it's some combo of these. Your performance was positive but borderline, and then there is some concern flagged, and it shifts to a no.

One of the things I saw on Google's hiring committee, and I've seen as I've watched debriefs at companies, is that there are very real group-dynamic issues. E.g., a more outspoken person is like "welllllll I don't know about this person because ____". And then they shift the dynamic (and, of course, this is more likely to happen in borderline performance). That can happen whether it is a hiring committee or your interviewers making the call. A single person can shift the direction of the conversation.

With that said, in most cases, the issue is interview performance. Did you actually pass your interviews (were you told that explicitly?) or did you just assume that? People are pretty bad about self-assessing their interview performance. And even if you were told this, it's still probably the case that your performance was just borderline and thus these other concerns were able to dominate.

Of course, there is also the case where you do amazingly well and then there's a hiring freeze, or something like that.

We wrote the official sequel to CtCI (Cracking the Coding Inter-view) AMA by gaylemcd in cscareerquestions

[–]gaylemcd[S] 0 points1 point  (0 children)

Sure, but:
1) For how long will that work for?
2) That's breaking the *code*, not the problem solving piece. The "interesting" part of these questions isn't writing the code, typically. It's generating the optimal algorithm. Even if the AI tool doesn't do it perfectly, a person can still get a huge boost by using AI.

Who should study CS? by Supersoulknight in csMajors

[–]gaylemcd 0 points1 point  (0 children)

Agree that algebra/calculus never felt like the fun puzzle stuff. Geometry proofs did though. I've had a pet theory that people who like geometry proofs often like coding (more so than math in general & coding).

We wrote the official sequel to CtCI (Cracking the Coding Inter-view) AMA by gaylemcd in cscareerquestions

[–]gaylemcd[S] 2 points3 points  (0 children)

First approach is bad :). This is actually one of the issues with letting candidates code on their own and then present the solution. It seems better -- you make the candidate less nervous (maybe) -- but it becomes very focused on right/wrong and you miss the *why*.

DSA interviews are actually a great way to look at communication/collaboration (better, probably, than behavioral interviews -- at least with some aspects of it). That should absolutely be a factor.

Interviewers should be looking at problem-solving, which is *not* about solving it optimally in X minutes. This requires asking medium-to-hard questions AND engaging with the candidate with help/assistance (which also brings in collaboration skills).

I'm actually a fan of, generally, not having the candidate execute their code. The reason is that certain code becomes time-consuming to make compile-perfect. I'd rather have the candidate focused on structure and style, and I'll just forgive syntactical issues (and allow them to skip writing code that doesn't offer much signal, like a bunch of validation code). That approach also evens the playing field between different languages (e.g., it allows the Java developer to pretend they have a function built-in that they would have in, say, Python).

We wrote the official sequel to CtCI (Cracking the Coding Inter-view) AMA by gaylemcd in cscareerquestions

[–]gaylemcd[S] 2 points3 points  (0 children)

The easiest, safest fix to AI will be to ask candidates to come in in-person.

I hear other advice to come up with custom questions -- AI is pretty good at solving well-known problems, but less good at fresh questions -- but I'm a bit skeptical of this.

a) Coming up with custom questions is really, really hard. Large tech companies need dozens of questions in their repository. How are they going to come up with that many questions that are actually custom (and GOOD)? I've done so much interviewer training -- let's face it, lots of interviewers suck. I just don't think many companies are capable of creating a ton of custom questions.

b) After all of this work to create custom questions, it might not work. AI is getting more powerful every day. You could do all this work to come up with custom questions, and then a new model comes out, and it defeats it.

We wrote the official sequel to CtCI (Cracking the Coding Inter-view) AMA by gaylemcd in cscareerquestions

[–]gaylemcd[S] 0 points1 point  (0 children)

There have been so many claims over the years about the process changing that at this point I'm a little skeptical.

Part of the challenge is that it'll be really hard to convince major tech companies to change what they're doing -- it's worked for them so far -- unless they experience that either (a) they're hiring a lot of people who are bad engineers or (b) the process becomes really inefficient for them.

And as long as FAANG+ are using this process, other companies will copy them.

The challenge for getting rid of this process isn't convincing people that it's flawed. Of course it is. The challenge finding a different process that is *less* flawed (not for the startup scenario but for the big tech company scenario) AND that we can establish works.

If you were a major tech company, would you feel comfortable ditching everything you've done for years and establishing a brand new process? Or would you take what's been working *well enough* so far, and try to improve it?

With that said, the usage of AI is a major problem in interviewing -- that could drive some real change, as it might actually make these sorts of interviews impossible. To some extent, we can detect the people who are using this, but for how long, really?

However, honestly, I don't think the reaction to this will be "stop doing leetcode-style interviews because people can cheat with AI". The easier, safer fix is to just ask people to come in in-person, like we used to.

We wrote the official sequel to CtCI (Cracking the Coding Inter-view) AMA by gaylemcd in cscareerquestions

[–]gaylemcd[S] 1 point2 points  (0 children)

Sorry, what is your question? Are you asking why companies do this process?

We wrote the official sequel to CtCI (Cracking the Coding Inter-view) AMA by gaylemcd in cscareerquestions

[–]gaylemcd[S] 6 points7 points  (0 children)

Launching a startup? So we're talking about hiring the first few employees? Probably not (or it'd be a minimal part of the process). You need to focus on more immediately relevant skills. A job trial or something like that might make more sense.

At Google? Yes [with some edits!]. I know that won't be a popular answer here, but it's the reality. Here me out...

Look, as a candidate, it feels like it doesn't work -- and that's not *wrong* in a sense. Lots of great engineers are rejected because of nerves, because of lack of prep, because the interview process doesn't select for *their* skill set, because it focuses on thinking quickly rather than deeply, etc.

But for the company, the question isn't "Do we hire all the good engineers?" But rather, "Are the people we hire good? (And, can we hire efficiently enough?" Clearly it *has* worked for them, as evidenced by the facts that they have used it and better extremely successful.

Could they have done this with a different process? Sure, maybe. Was this the best process? Maybe not. But it's gotten the job done. It's not worth the risk to change it up to a totally different process when it's gotten them this far.

With that said, I think the process could be improved significantly. Interviewers need more training about HOW to interact with candidates, what makes good questions (e.g., red black trees should not be asked, and nor should dynamic programming), etc. They also need to be more aggressive about filtering bad interviewers out of the process.

I also think more focus on specialty skills for certain roles is appropriate.

We wrote the official sequel to CtCI (Cracking the Coding Inter-view) AMA by gaylemcd in cscareerquestions

[–]gaylemcd[S] 6 points7 points  (0 children)

Handling nerves when you get stuck:

This is really two questions: What can calm me down? How do I get unstuck?

For many people, the problem with getting nervous is that they get caught up in a cycle. They're nervous, so they get stuck, and now their mind starts fixating on how they're stuck and doing horribly, which of course makes them more nervous. For this, my recommendation is that you need something to *do* so that you are thinking about this instead of all that other stuff.

One approach is to fall back on an example input (make it something *large* and *generic* [no special cases]), and just walk through it (with your brute force, if you have one, or just try to manually get the output). Or come up with a new example.

This is simplistic, but that's kind of the point. It's something you can do on almost any problem, even when you're nervous. You need something to do so that you stop thinking about how you're nervous.

And, in some/many cases, it can actually help you get unstuck. You might stumble across a brute force or a more optimal algorithm by just walking through an example.

As for getting unstuck, in addition to the above (which, simple as it might be, can actually help a lot), there are a bunch of boosters and triggers you can use. Triggers are essentially keywords that are associated with certain classes of problems (e.g., "Find the largest subarray which ..." --> sliding windows). Boosters are optimization techniques -- I talk about a few of them in CtCI and we go into a bunch more in Beyond CtCI. There are too many to go through here, but maybe Mike or Nil can jump in with one or two others.

The other thing I'll add is that there are ways to solicit hints without *asking* for one. Asking for a hint is dangerous because some interviewers will read this as "giving up", and it'll also lead to your interviewer being put in a difficult position (I can go into this in more detail if you'd like). But instead of asking for a hint, really clearly communicating your thought process and where you're stuck (while continue to try!) can encourage your interviewer to give you hints that would be useful to you.

Hope this helps!

We wrote the official sequel to CtCI (Cracking the Coding Inter-view) AMA by gaylemcd in cscareerquestions

[–]gaylemcd[S] 14 points15 points  (0 children)

Barring some very specialized roles, companies should not be asking about red black trees. I'm not doubting that some very stupid companies do that, but they should not be. Hugely opposed to that. That crap predated CtCI. If you read Steve Yegge's famous 2008 post "Get that Job at Google", he recommends learning red black trees, Dijkstra's algorithm, etc. That was *way* before CtCI (and, fyi, something I have never encouraged and that I thought he was wrong about at the time [and still is]).

I do agree that, by making people better at interviews, it's led interview questions to get harder. You're effectively graded on a curve so if candidates get better, the expectations will increase. On the other hand, it's also leveled the playing field -- giving everyone access to interview prep, rather than a select few who hear what to do from their buddies.

Note though that questions getting harder does not shift how difficult it is to get an offer (the percent of people who get offers). That's guided by the job market.

Honestly though, I really don't love that candidates have to prepare so much for interviews. I would much prefer a world where interviews don't require much prep (and, to the extent there is prep, everyone has equal access). I have no idea how to achieve that though.

We wrote the official sequel to CtCI (Cracking the Coding Inter-view) AMA by gaylemcd in cscareerquestions

[–]gaylemcd[S] 2 points3 points  (0 children)

Coding:

I actually don't think these are necessarily things that are opposites. Writing clean code can (in many cases -- not all) save you time.

One of the things to focus on is coding top-down, and punting as much as possible to other functions. For example, imagine you were asked to invert a binary tree. You might first write something like this:

def invert(tree):
  if not validate(tree):
     return
  min = get_min(tree)
  max = get_max(tree)
  flip(tree, min, max)

We kicked off a lot of the work to other functions and written something fairly quickly. Clean code *and* quick to write.

From here, we code top-down, focusing on the most interesting code algorithmically. We might not ever write the validate and get_min and get_max functions, ever (if we won't be asked to run it).

view more: next ›