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

How to win the coding interview

blog.devmastery.com

Post reply on HN
Print view View original

271–280 of 305 posts

Re: How to win the coding interview

#271

Post by EpicEng »

enraged_camel wrote: post #119
richforrester wrote: post #104

Earlier quoted context omitted.

Thank you, this was almost exactly what I was going to respond with. My only addition: "Alternatively, we can write/review some code on a whiteboard."

It's well documented that whiteboard exercises are terrible for evaluating candidates. A lot of people, developers especially, don't perform well under pressure (stress reduces cognitive ability). Not only that, but you will also alienate a great many experienced candidates. If you are OK with all that, fine I guess. But I thought it was widely agreed upon that the software industry needs better hiring practices.

What do you mean by "well documented" exactly? Are you referring to the numerous blog posts where people in the industry complain about it? I wouldn't call that extremely convincing.

I understand that some people get stage fright, but I'm not expecting them to come up with a perfect solution; I'm only trying to get an idea of how they think (and whether or not they can actually write code). If they can't do this sort of thing in front of a small group then how are they going to perform in group meetings? Are they just going to sit quietly in the corner the entire time?

I can't have that either, and I need some sort of measuring stick. I'd rather lose a good candidate than take on a bad one.

Re: How to win the coding interview

#272

Post by EpicEng »

vonmoltke wrote: post #199
ori_b wrote: post #181

Earlier quoted context omitted.

> A lot of people, developers especially, don't perform well under pressure (stress reduces cognitive ability). A lot of places value people who work well under pressure. (A bad push taking down all the server's I'd stressful)

Meaning a lot of places have shitty processes and architecture and try to compensate by hiring people that fit their broken system. Case in point: having an architecture so fragile that a bad push is capable of taking down all your servers.

Oh please. Even the best systems will have issues, and there will always be high pressure situations, regardless of the competency of management. It shouldn't be a way of life, but it's simply not practical to expect easy sailing at all times.

Re: How to win the coding interview

#273

Post by EpicEng »

Clubber wrote: post #238
EpicEng wrote: post #66

Earlier quoted context omitted.

>Instead of a coding interview, I'll make a counter offer. Why not hire me on a 1 week contract to come and do some real world work. Work that is small enough to be done in 1 week and big enough to deliver some value. Except now I have to jump through hoops with HR (let's just assume they'd be OK with this, which they almost certainly won't), get the contract in place, work with IT to get your environment set up, and…

>Except now I have to jump through hoops with HR (let's just assume they'd be OK with this, which they almost certainly won't), get the contract in place, work with IT to get your environment set up, and bring you up to speed (so really I may get one full day of actual work)... just to realize that I don't want to hire you. There are two major reveals in that sentence. One, HR rules your hiring practice and therefore…

>Both are red flags

No they're not; they describe 98% (made up number) of the industry, and I don't think that "soul-suckingly bureaucracy" is an inevitable outcome of implementing reasonable processes.

We have IP that we have to protect. We have a company to protect (hence the HR involvement). Sure, you may be lucky enough to wing it in your little five man operation and get by, but you had better hope you don't run into a problem employee if you're not covering your ass. The sort of company you describe can be a ton of fun to work at, but you're also probably failing in a ton of areas and you don't even realize it yet. It's a mistake to think that your hipster SV perspective is the way that the world should work.

Re: How to win the coding interview

#274

Post by sklogic »

Clubber wrote: post #268
sklogic wrote: post #263

Earlier quoted context omitted.

I can only hope I will never have to work in a team with someone like you. That would definitely be a massive waste of time. A typical workflow based on a pseudocode is very simple and efficient: you solve your problem in a pseudocode - an informal language that does not yet exist but captures the essense of the problem. Then, while still on a whiteboard, you refine your pseudocode into something still "pseudo" (i.e.…

Ok, so I guess by your omission, you agree that pseudocode is not code and flow charts are also not pseudocode. I don't care about the rest, you can whiteboard all you want. We analyze the problem, then solve it in our heads, usually by the time we've finished talking about it. White boarding just seems way over the top, especially if it takes more than one person to solve a problem every day. Sounds like development…

> you agree that pseudocode is not code and flow charts are also not pseudocode

What?

I just demonstrated that pseudocode is an ultimate form of a code, flowcharts included (they're just a graphical pseudocode). Maybe you do not understand what does the word "code" mean?

> What's 2+2?

Is it an average complexity of the problems you're solving?

> stack do you use?

Even your choice of words betrays you. You're a web coder, aren't you?

Just today I spent somewhere around 3 hours writing pseudocode on a piece of paper, and about 30 minutes typing it on a keyboard, testing and debugging. And it's about a typical proportion.

Re: How to win the coding interview

#275

Post by judahmeek »

agentultra wrote: post #201
kayman wrote: post #36

I'm tired of companies asking me to code at their interviews. I have 10 years experience with references. I have code that I've built, deployed to production still running today. I have cultivated my own clients, gathered requirements and built something that delivers business value. Instead of a coding interview, I'll make a counter offer. Why not hire me on a 1 week contract to come and do some real world work. Wor…

> I'm tired of companies asking me to code at their interviews. I get that. I am too. I'm around 13+ years of experience. I have contributions to major open source projects, have given talks at a few conferences, write about my experiences on a blog... it doesn't matter. I've ran into a few interviewers who take a few minutes before the interview to skim my blog. Once I ran into someone who actually read a few posts…

Some really solid advice.

Re: How to win the coding interview

#276

Post by judahmeek »

kriro wrote: post #107

Sometimes you can also solve whiteboard blackout issues with humor. I once was stuck because I couldn't quite figure out how to implement something (I think it was a peculiar sort). I proceeded to give up after reasoning through it for a bit and mumbled...well I can't quite get it now but let's move on since I'd probably never implement this and if I do I'd spend a lot more time on it and proceeded to add this line a…

Nicely done. xD

Re: How to win the coding interview

#277

Post by judahmeek »

iSnow wrote: post #145
hvidgaard wrote: post #117

The author have a list of secret good questions, and that is not helping anyone. He expects the candidate to think loud and be explicit, but are himself very implicit in his requirements. What I consider production code is without a doubt different from what he things is production code. > Your code should be commented. Then put this requirement, because judging from the example, the authors expectations, is what I f…

But the author doesn't even advocate RegEx for testing if a string is a palindrome. He doesn't explain for which part he'd use it, but from the sound of it, removing whitespace and punctuation.

That's right. If you look at the code, the only use of regex is to remove all characters not matching [a-z0-9].

Re: How to win the coding interview

#278

Post by kayman »

ma2rten wrote: post #90
EpicEng wrote: post #66

Earlier quoted context omitted.

>Instead of a coding interview, I'll make a counter offer. Why not hire me on a 1 week contract to come and do some real world work. Work that is small enough to be done in 1 week and big enough to deliver some value. Except now I have to jump through hoops with HR (let's just assume they'd be OK with this, which they almost certainly won't), get the contract in place, work with IT to get your environment set up, and…

I think kayman talking about interviewing to work as an independent contractor because he said: "I have cultivated my own clients, ...".

Yes. I mean instead of asking me to do work for free. Why not I provide a small paid sample of my work. A risk both of us can take and live with.

If you don't like the work, we can part ways knowing we are not the right fit.

Re: How to win the coding interview

#279

Post by MustardTiger »

BinaryIdiot wrote: post #257
MustardTiger wrote: post #208

Earlier quoted context omitted.

>Sure but this really has nothing to do with the parent's post. The parent said they have references and the experience and code in production. All of this is verifiable short of, say, DoD contract work. It has everything to do with it. References are completely useless unless you happen to be lucky enough to know one of their references well. A random stranger saying "Bob knows X" is just as useless as Bob telling m…

References are all about verifiability otherwise it's just a random person saying something about another person; without context a reference is useless. You need to find a way to verify them which I'll admit is hard but without that they're completely useless. Open source is usually the best indicator here as they can literally point you to code they worked on. > Everyone has references, that is not something that i…

>You need to find a way to verify them

Such as?

>That's why, in my original text I caveated it with verifiable code running in a production environment.

Again, how do you verify that? Much less the quality of that code?

>It's not the greatest code but they made something, it worked and it's been scaled all over the place

The bar for hiring here is not that low. "I wrote some horrible buggy crap that is full of security holes and has cost millions of dollars" isn't a good sales pitch.

>Seems like they could have some solid people involved in it in my opinion.

The code says otherwise.

Re: How to win the coding interview

#280

Post by hvidgaard »

thedufer wrote: post #219
hvidgaard wrote: post #110

Earlier quoted context omitted.

Problem is that every framework have their own dialect of it, and many of them are not even regular expression, but something beyond that.

The most common dialect is PCRE. Most languages have an implementation of either that or a superset of it.

   The most common dialect is PCRE. Most languages have an implementation of either that or a superset of it.
PCRE isn't exactly simple to begin with. That languages may implement it, or a superset of it, is exactly the problem. I know regular expressions very well, or rather I know regular languages and can fairly easily identify if a problem is solvable as a regular expressions. But once you start to go beyond that, it's not simple anymore and the benefit of a regular expression is lost.
Post reply on HN