bearforcenine

It means that you have a friend or someone you pay solve the challenge and prep you very well on the solution. This isn't about creating the universe before you bake an apple pie, it's about preventing a mediocre software engineer who can understand a great solution, but has a hard time writing one from being assessed the same was as a great software engineer.

I doubt this is a sign of a decline in quality of higher ed, and more a sign of the popularity of CS as a major and software engineering as a career.

These kinds of courses and prep has existed in similarly popular fields for many yeas: law, medicine, finance, etc.

Any challenge that doesn't change across applicants at a company that has a large enough applicant pool, will eventually be solved and prepared for so well, that almost any question you can ask will be prepped for.

Beyond that, if you do use a single question, you're now playing a game of whack-a-mole: I used to ask this question about the challenge, now I can't because it is leaked and people prepped for it. How do you scale that across an engineering organization? Do you have weekly meeting with every interviewer informing them of the questions about the challenge that are now blacklisted? It's going to be infeasible for any reasonable sized organization.

The challenge with this idea as well is that the risk of false positives is much higher than the whiteboard interview. The current interview process is designed around minimizing false negatives.

False positives are really costly to an engineering organization. It's not good for morale when engineers are being hired and fired in the same month on a regular basis. It's takes time to onboard, and slows the team down. It's also not good for the company reputation - would you apply to a company who had a reputation of firing a good chunk of its new software engineers within the first month?

Yes, it is silly that you have to train for an interview for months to land a SWE position at a top company. However, until someone comes up with a less gameable system or a magic wand that stack ranks applicants, then I don't see a viable alternative :\

As someone who gives a lot of interviews, I'd love a better way to assess a candidates ability that is less gameable, but we haven't found one yet.

This kind of prep has been common place in other desirable fields for many years. Law, medicine, finance. They all have books, classes, etc. that you can take to prepare for interviewing, taking the bar, mcat, etc. Compared to college admissions, the CS interview process looks downright sane.

How do you prevent cheating? Someone can very easily have a friend complete the challenge and walk them through it in a lot of detail. They could prep well enough that you hire someone who is massively under-qualified.

Then if your company is large enough, your novel challenge gets leaked and everyone knows it ahead of time. Solutions start being sold or distributed. Then your interview is meaningless.

I'm all for a viable alternative to the whiteboard interview, but I haven't encountered one yet.

It's very tempting to say this. However, trying to find an alternative that is not equally or more gameable is very challenging.

Take home assignments are easy to cheat on and take a lot of time.

Asking questions about someone's experience is a great way to find someone who is a great conversationalist that can't code.

Asking someone to program at a computer in a limited amount of time falls victim to the same issues that the competitive programming, whiteboard interviews currently do.

No matter what system you use to interview people, if the position is desirable enough, and the number of positions is smaller than the applicant pool, isn't gaming the system the expected outcome?

If people at Google were interviewed by juggling raquetballs, there would be books, courses, etc. on how to juggle better. People are willing to pay for this prep because they want to work at Google. Eventually most everyone interviewing at Google would be very well prepared to juggle.

It's been my experience that any industry that

* Is attractive enough (compensation, lifestyle, etc.)

* and has a larger supply of qualified applicants than desirable positions

Will result in applicants preparing for however they are interviewed, tested, etc. This isn't unique to software engineering interviews. People prepare for interviews or exams in finance, law, medicine, etc. They all have a system that is gameable. It might be newer in software engineering interviews, but that is mostly because CS is now incredibly popular and top talent is compensated very well.

Lucidchart uses WebGL for the canvas in our editor. The menus around the canvas are Angular, but the actual editor is all WebGL. Full disclosure: I work at Lucid.

We did this lab at the University of Utah because the Systems class is taught out of the same textbook. I also loved this lab. If I remember correctly we had a leaderboard, and it was fun competing with everyone else.

Most of the labs for this textbook were great: writing a shell, implementing common math functions by bit twiddling, buffer overflows, disassembling the bomb with the debugger, etc. It was a great class. Definitely not easy, but a lot of fun.

Utah could be a great fit based on Amazon's preferences for a site if they build something along the I-15 corridor. It's within 30 miles of a population center, within 45 minutes to the airport, directly off a major highway, front runner rail stations run along I-15, and you might be able to find 100 acres of space - especially if they were to put it out where the prison is now (it's moving soon).

I am a bit concerned that between the Scala, Dotty, Typelevel, and now the Reasonable Scala Compiler, that the Scala community might become fragmented. Hopefully the rsc's claim of "making our findings available to the Scala community at large" holds true.

Edit: should have keep reading before commenting. In their related work document:

>we are definitely not declaring Lightbend Scala dead. To the contrary, we view ourselves as complementary to Lightbend Scala and hope that our results will create new opportunities for the official compiler. We are planning to keep in contact with Lightbend to discuss our findings and facilitate technology transfer.

Seems like you could make the same argument about modern C++ or other kitchen sink languages - lots of features, lots of ways to write unreadable code.

I've worked in Scala for the last 3 years and I've found implicits to be the biggest issue. They're hard to debug, it's not easy to tell which implicits are in scope. Things like that.

Being clever is a problem with the developer and not the language. Scala code is dense, sure, but that's not inherently a bad thing.

I wasn't directly involved in this decision and I've never worked on our mobile apps, but I do work at Lucid. Almost the entire engineering team can write Scala. About 3 people can write Kotlin. That was a big part of it. The lead engineer on our Android app is also a Scala wizard.

I began working in a large Scala codebase and the IDE support made quickly navigating the code very easy.

I still use vim or emacs whenever I need to do some serious text editing or I'm in a console.

I went through the entire game in 2014 - thoroughly enjoyed it. Taught me vim basics as well as more advanced concepts. After going through the game I used vim as my primary editor for almost a year. Despite the annoying $25/6 months of access I still recommend it to those looking to learn vim.

At Lucid Software we use the Closure Compiler with advanced optimizations to build both Lucidchart and Lucidpress. You can see some work we did with it in respect to Angular here: https://www.lucidchart.com/techblog/2016/09/26/improving-ang...

I don't have a direct comparison to Uglify, but as of last fall advanced optimizations does save us about 2.5 MB over simple optimizations.

We're also using Tsickle (https://github.com/angular/tsickle) and Clutz (https://github.com/angular/clutz) to be able to use TypeScript with our Closure Compiler compatible codebase. Closure Code can be depended upon in TypeScript code and vice versa. It's been awesome to use the type system of TypeScript in combination with the minification power of the Closure Compiler. The build process is definitely a bit crazy at the moment, though.

Disclaimer: I work at Lucid Software.

Tsickle by Angular does that: https://github.com/angular/tsickle

It wraps the TypeScript Compiler and outputs CC compatible type annotation comments.